概述#

Integrability（可整合性）是指將一組元件整合到系統中時，所需的成本與風險。當我們需要將新的元件 {Ci} 整合到既有系統 S 中時，S 與 Ci 的建立者所需做的額外工作——例如提供轉接器、適配器，或使元件在不同環境下表現一致——都會影響整合的成本與風險。

評估架構的可整合性#

整合難度——即成本與技術風險——可視為 {Ci} 與 S 之間介面的規模與距離的函數：

• Size（規模）：{Ci} 與 S 之間潛在相依性的數量
• Distance（距離）：解決每個相依性差異的難度

相依性通常以語法方式衡量。例如，我們說模組 A 依賴元件 B，如果 A 呼叫 B、A 繼承 B 或 A 使用 B。但語法相依性雖然重要，卻不是相依性的全部形式。

相依性不僅限於語法層面（如 A 呼叫 B、A 繼承 B）。元件之間也可能存在時間耦合（temporal coupling）與語義耦合（semantic coupling），而這類隱性相依性往往未被明確記錄，是大型長期專案中整合風險的主要來源。遺漏或隱含的知識永遠是風險，會不可避免地增加整合與整合測試的成本。

距離的五個維度#

理解元件間的「距離」是評估整合難度的核心。當元件互動時，它們在合作完成交互方面的對齊程度如何？

• 語法距離（Syntactic distance）：合作元素必須就共享資料的數量與型別達成一致。例如一端傳送整數、另一端期望浮點數，或位元欄位的解讀方式不同。型別不匹配通常可由編譯器捕捉，但位元遮罩差異則較難偵測，可能需依賴文件或程式碼檢查才能識別。
• 資料語義距離（Data semantic distance）：即使資料型別相同，其值的解讀可能不同。例如一方以公尺表示高度、另一方以英尺表示。這類不匹配通常難以觀察與預測，但若元素採用 metadata 則可改善分析。可透過比較介面文件或 metadata 描述來發現。
• 行為語義距離（Behavioral semantic distance）：元件必須就行為達成一致，特別是系統的狀態與模式。例如在啟動、關機、復原模式下，同一資料元素可能有不同解讀。某些情況下，狀態與模式可在協定中明確捕捉。另一個例子是 Ci 和 Cj 對控制有不同假設，例如雙方都期望由對方發起互動。
• 時間距離（Temporal distance）：關於時間假設的差異。例如一方以 10 Hz 發送、另一方期望 60 Hz，或對事件先後順序及延遲有不同預期（如期望事件 A 在事件 B 之後 50 ms 內發生）。雖然可視為行為語義的子類別，但其重要性與微妙性值得單獨列出。
• 資源距離（Resource distance）：對共享資源假設的差異。涉及裝置（一方要求獨佔存取、另一方期望共享）或計算資源（如記憶體需求超過實體限制、通訊頻寬不足以支撐多元件同時傳輸）。同樣應被有意識地分析。

程式語言介面描述通常不涵蓋這些細節。在組織層面，這些隱含的、未明確記錄的介面往往大幅增加整合任務的時間與複雜度。這也是介面被視為架構層級關注點的原因（詳見 Chapter 15）。

服務與微服務的趨勢本質上是透過解耦元件來減少相依性的數量與距離。服務之間僅透過已發布的介面互相「認識」，若該介面是適當的抽象，則對一個服務的變更較不會波及其他服務。然而，服務導向本身僅解決語法層面的相依性，並未處理時間與語義層面。表面上解耦但彼此有詳細隱含知識與假設的元件，實際上仍是緊密耦合的，未來變更可能代價高昂。

對於 integrability 而言，「介面」必須被理解為遠不止 API——它必須刻劃元素之間所有相關的相依性。整合性的本質在於辨識並彌合每個潛在相依性的距離，這是一種為可修改性進行預先規劃的形式。

General Scenario#

Table 7.1 描述了 integrability 的通用情境，涵蓋六個組成部分：

上圖呈現一個具體情境範例：元件市場中出現新的資料過濾元件（data filtering component），在開發環境中進行整合與部署，目標是在 1 個月內以不超過 1 人月的工作量完成。

建構具體情境時，應盡可能明確每個部分的值。明確的 response measure（如時間、人力、受影響元件數）使情境可被驗證，也讓架構決策有據可循。

Integrability Tactics#

整合性策略的目標是降低新增元件、重新整合變更元件、以及將一組元件整合在一起以滿足演進需求時的成本與風險。

策略透過兩種方式達成目標：減少元件間潛在相依性的數量，或縮短元件間的預期距離。策略分為三大群組：Limit Dependencies、Adapt、Coordinate。

Limit Dependencies（限制相依性）#

• Encapsulate（封裝）：所有整合性策略的基礎，因此很少單獨出現，但其使用隱含於其他策略之中。封裝引入明確介面並確保所有存取都通過此介面，消除對元素內部的相依性。封裝也可隱藏與特定整合任務無關的介面，例如某個服務使用的程式庫可完全對消費者隱藏。封裝可減少相依性數量以及語法、資料語義與行為語義距離。
• Use an Intermediary（使用中介）：用於打斷一組元件 {Ci} 之間或 {Ci} 與系統 S 之間的相依性。不同類型的中介解決不同類型的相依：publish-subscribe bus、shared data repository、dynamic service discovery 移除資料生產者與消費者之間的身份識別需求；data transformer 與 protocol translator 解決語法與資料語義距離。中介可在整合時為解決特定相依性而引入，也可在架構中預先包含以促進未來的整合性。
• Restrict Communication Paths（限制通訊路徑）：限制元素可溝通的對象範圍。實務上透過可見性限制（開發者看不到的介面就無法使用）與授權機制（僅允許授權元素存取）實現。在 SOA 中，不鼓勵 point-to-point 請求，而是強制所有請求通過 enterprise service bus 以統一處理路由與前置處理。
• Adhere to Standards（遵循標準）：標準化是跨平台與跨供應商的 integrability 與 interoperability 的關鍵促成因素。標準的範圍各異——有些僅定義語法與資料語義，有些則包含協定、行為與時間語義。廣泛認可組織（如 IEEE、ISO、OMG）發布的標準較可能被廣泛採用。組織內部慣例若有良好記錄與執行，也能作為「本地標準」提供類似效益。採用標準的效果取決於標準涵蓋的維度以及未來元件供應商遵循標準的可能性。
• Abstract Common Services（抽象共同服務）：當兩個元素提供相似但不完全相同的服務時，將兩者隱藏在共同抽象介面之後。此抽象可實現為兩者共同實作的介面，或涉及一個中介將抽象服務請求轉換為具體請求。結合中介（如 wrapper 或 adapter），還可標準化語法與語義差異。例如：系統使用多家製造商的感測器，各有不同驅動程式、精度與時序特性，但架構提供統一介面。另一例是瀏覽器支援各種廣告攔截 plug-in，但因 plug-in 介面的存在，瀏覽器本身無需知道使用者的選擇。

Adapt（適應）#

• Discover（發現）：Discovery service 是相關位址的目錄，當需要位址轉換、目標位址可能動態綁定、或有多個目標時特別有用。它是應用程式與服務互相定位的機制。目錄中的條目是因為被註冊才存在——註冊可以是靜態的（如 DNS 伺服器），也可以是服務實例化時的動態註冊。不再相關的條目應被 de-register，可由 discovery service 自行透過 health check 處理，或由知道條目何時不再相關的外部軟體執行。Discovery service 的條目本身可以是其他 discovery service，且條目可有額外屬性供查詢參考。此策略使服務在不需彼此知識的情況下合作，實現綁定的彈性。
• Tailor Interface（裁剪介面）：在不改變 API 或實作的情況下，對既有介面新增或隱藏功能。可添加的功能包括翻譯、緩衝、資料平滑化；隱藏功能的例子是對不受信任的使用者隱藏特定函式或參數。常見的動態應用是 intercepting filter，可添加資料驗證（如防止 SQL injection）或在資料格式間轉換。另一例是使用 aspect-oriented programming 在編譯期織入前處理與後處理功能。此策略允許許多服務所需的功能根據上下文添加或隱藏，也使具有語法差異的服務無需修改即可互通。
• Configure Behavior（配置行為）：元件被實作為可在預定方式下配置，以便更容易與各種元件互動。配置可發生在建置階段（以不同旗標重新編譯）、系統初始化（讀取組態檔或從資料庫取得資料）、或執行期（在請求中指定協定版本）。一個簡單的例子是配置元件在其介面上支援不同版本的標準。確保多個選項可用可增加 S 與未來 C 的假設匹配的機會。此策略可處理語法、資料語義、行為語義與時間距離。

Coordinate（協調）#

• Orchestrate（編排）：使用控制機制協調與管理特定服務的呼叫，使服務之間無需相互感知。Orchestration 有助於整合一組鬆散耦合的可重用服務以創建滿足新需求的系統。Workflow engine 是常見應用——workflow 是一組組織化活動，排序與協調軟體元件以完成業務流程，可包含其他 workflow，各自由聚合的服務組成。複雜的 orchestration 可以 BPEL（Business Process Execution Language）等語言規範。此策略減少 S 與新元件 {Ci} 之間的相依性，並透過在 orchestration 機制集中化，完全消除 {Ci} 之間的明確相依。若與標準遵循等策略結合使用，還可減少語法與資料語義距離。
• Manage Resources（管理資源）：Resource manager 是管控計算資源存取的特定中介形式，類似於限制通訊路徑策略。軟體元件不被允許直接存取某些計算資源（如 thread 或記憶體區塊），而是向 resource manager 請求。Resource manager 通常負責在多個元件之間分配資源存取，以保持某些不變量（如避免資源耗盡或並行使用）、強制公平存取策略、或兩者兼顧。範例包括作業系統、資料庫交易機制、企業系統的 thread pool、以及安全關鍵系統的 ARINC 653 時空分割標準。此策略透過明確揭露資源需求並管理共同使用來縮短資源距離。

Tactics-Based Questionnaire#

Table 7.2 提供了基於策略的整合性問卷。分析師針對每個問題記錄答案，作為進一步調查（文件檢視、程式碼分析、逆向工程等）的焦點：

問卷的每個問題都應記錄：是否支援（Y/N）、風險程度、設計決策與位置、以及背後的理由與假設。這些答案可用來引導文件調查、程式碼分析或逆向工程等後續活動。

Patterns#

Wrapper、Bridge 與 Mediator#

這三個模式都以 tailor interface 策略為核心，作為一組進行介紹：

• Wrapper（包裝器）：將某個元件封裝在替代抽象之中，是唯一被允許使用該元件的元素；所有其他軟體必須通過 wrapper 使用該元件的服務。Wrapper 可以：
  • 將元件介面的某個元素轉換為替代元素
  • 隱藏元件介面的某個元素
  • 原封不動地保留元件的基礎介面
  • 例如：元件預期使用英制單位的輸入，但系統中所有其他元件產出公制單位
• Bridge（橋接器）：將一個任意元件的 “requires” 假設轉換為另一個元件的 “provides” 假設。與 Wrapper 的關鍵差異在於 Bridge 獨立於任何特定元件，且必須由外部代理明確呼叫（可能但不一定是 Bridge 所跨越的元件之一）。Bridge 通常是暫時性的，轉換邏輯在建構時定義。Bridge 傾向專注於比 Wrapper 更窄的介面轉換範圍，因為嘗試處理越多假設，適用的元件就越少。
• Mediator（中介器）：兼具 Bridge 與 Wrapper 的特性。與 Bridge 的主要區別是 Mediator 包含規劃功能（planning function），能在執行期動態決定轉換方式，而 Bridge 在建構時即確定轉換。Mediator 也類似 Wrapper，成為系統架構中的明確元件——語義上簡單且常為暫時性的 Bridge 可視為附帶的修復機制，角色可保持隱含；而 Mediator 具有足夠的語義複雜度與執行期自主性（持久性），在軟體架構中扮演第一級角色。

這三個模式都允許在不強制變更元素或其介面的情況下存取元素。代價是需要前期開發工作，且存取時會引入少量效能開銷（通常很小）。

Service-Oriented Architecture（SOA）Pattern#

SOA 模式描述一組分散式元件提供及/或消費服務。服務提供者與消費者可使用不同實作語言和平台，服務大體上是獨立的實體——通常獨立部署，且經常屬於不同系統甚至不同組織。元件有描述其請求與提供的服務的介面，服務品質可透過 SLA（Service Level Agreement）規範與保證，有時甚至具有法律約束力。通訊通常使用 WSDL（Web Services Description Language）與 SOAP（Simple Object Access Protocol）等 web services 標準。

• 優點：服務設計為可被多種客戶端使用，使其更具通用性（許多商業組織會以廣泛採用為目標推廣其服務）；服務獨立（唯一的存取方式是介面與網路訊息）；可使用最合適的語言和技術異質化實作
• 權衡：SOA 因異質性與分散擁有權而需要大量互通特性如 WSDL 和 SOAP，增加複雜度與開銷

SOA 與 microservice architecture 的差異：微服務假設組成單一系統且由單一組織管理，而 SOA 提供可重用元件，假設為異質且由不同組織管理。詳見 Chapter 5。

Dynamic Discovery Pattern#

動態發現模式將 discover 策略應用於執行期，使服務消費者與具體服務之間可進行 runtime binding。使用動態發現能力意味著系統會明確公告可供整合的服務及每個服務的最低資訊。具體可用的資訊因系統而異，但通常包含可在發現與執行期整合過程中被機械搜尋的資料（例如透過字串匹配識別特定版本的介面標準）。

• 優點：允許在啟動或執行期根據價格或可用性彈性選擇並綁定服務
• 權衡：動態發現的註冊與 de-registration 必須自動化，需要取得或開發相關工具

所有 integrability 模式都涉及權衡。Wrapper、Bridge、Mediator 需要前期開發投入；SOA 增加互通機制的複雜度；Dynamic Discovery 需要自動化註冊工具。架構師應根據專案的整合頻率與預期元件多樣性來選擇最合適的模式。

延伸閱讀#

• [Kazman 20a] 提供了本章大部分材料的靈感與來源
• [Hentonnen 07] 深入討論了 integrability 品質屬性
• [MacCormack 06] 和 [Mo 16] 定義並提供了架構層級耦合度量（coupling metrics）的經驗證據，可用於衡量設計的可整合性
• 《Design Patterns: Elements of Reusable Object-Oriented Software》[Gamma 94] 定義並區分了 bridge、wrapper 與 adapter 模式

小結#

Integrability 的核心在於辨識並彌合元件間每個潛在相依性的距離。這本質上是一種為可修改性進行預先規劃的形式（將在 Chapter 8 進一步討論）。

透過三大策略群組，架構師可以有效降低整合的成本與風險：

• Limit Dependencies：透過封裝、中介、通訊路徑限制、標準遵循與共同服務抽象來減少相依性數量
• Adapt：透過發現服務、介面裁剪與行為配置來適應元件差異
• Coordinate：透過編排與資源管理來協調元件互動

在實務中，理解介面不僅僅是 API，而是涵蓋語法、語義、行為、時間與資源等多維度的相依關係，是成功整合的關鍵。隨著軟體系統日益由來自不同來源的元件組成，integrability 作為品質屬性的重要性將持續增長。