第三種耦合是執行期耦合(runtime coupling)。與設計期耦合、建置期耦合影響開發體驗不同,執行期耦合直接影響分散式應用在執行期的行為。

在分散式架構中,一個請求(operation)往往跨越多個元件。

元件 A 對元件 B 是執行期耦合的,當 A 必須等到 B 回覆才能回應請求——也就是 B 故障會導致 A 故障。

如此一來,該請求的可用性會等於兩個元件的可用性的乘積。

Leslie Lamport 的名言:「分散式系統就是當一台你根本不知道存在的電腦故障時,讓你自己的電腦也無法使用的系統。」

設計分散式架構(尤其是微服務)時,若不留意執行期耦合,很容易做出脆弱不堪的應用。

緊執行期耦合的範例#

範例:Order Service 處理 POST /orders 時,呼叫 Customer Service 的 PUT /customers/{id} 來驗證顧客並預扣信用額度。

Figure 4.12: Order Service cannot respond to POST /orders until Customer Service responds — availability is the product

  • 可用性下降:Order Service 必須等 Customer Service 回應才能完成請求。
    • 假設 Customer Service 可用率 99.9%,Order Service 可用率 99.9%。
    • 整體 POST /orders 的可用率 = 99.9% × 99.9% ≈ 99.8%。
  • 延遲增加:回應時間 = Order Service 回應時間 + Customer Service 回應時間。

兩個服務串接已讓可用性下降,長串連續呼叫就是反模式中的「Christmas tree light architecture(聖誕燈架構)」——任何一處故障,整串都垮。

組織筒倉造成的緊執行期耦合#

緊執行期耦合常出現在「沒人關心端到端流程」的組織。Chris Richardson 分享的真實案例:

  • 替客戶做架構審查,某關鍵請求由兩個團隊共同實作。
  • 從 Team A 的視角來看,只是「我呼叫了 Team B 的服務」。
  • 進一步問 Team B 才發現,他們把該服務拆成了一群微服務。
  • 結果:該請求實際依賴多個服務的可用性。
  • 最終風險:客戶有可能無法滿足對外的 SLA。

沒有人從端到端視角去看請求,就是緊執行期耦合最常見的成因。設計分散式架構時,務必標出每個關鍵請求的依賴鏈。

三種降低執行期耦合的策略#

策略一:把操作的子領域合併到單一服務#

  • 若操作完全在單一元件內,就沒有執行期耦合。
  • 範例:把 createOrder() 涉及的 Order Management、Customer Management 合併進單一 Order Service,讓 POST /orders 完全本地處理。

Figure 4.13: Implement createOrder() as a local operation by merging Order Service and Customer Service

  • 缺點:服務會變大,過度擴張就會變成巨石。
  • 適用場景:呼叫頻繁、必須高可用 + 低延遲的關鍵操作。

策略二:在服務之間搬移責任#

不直接合併,而是把某項責任從一個服務搬到另一個。

  • 範例:把「管理可用信用額度」從 Customer Service 移到 Order Service。createOrder() 就能在 Order Service 內部完成驗證,不必跨服務呼叫。

Figure 4.14: Implement createOrder() locally by extracting Available Credit Management to Order Service

  • 副作用:建立顧客現在會涉及兩個服務,但這是低關鍵的操作,通常是可接受的取捨。
  • 限制:被搬移的子領域必須只被一個服務使用;若被多個服務共用,只有其中一個能享受本地化的好處。

第 20 章介紹的「架構重構(architectural refactoring)」會詳述這類設計演進手法。

策略三:用非同步訊息#

用 message broker 取代同步呼叫——讓 Order Service 不必等 Customer Service 回應就先回應 client。

範例設計:

  • Order Service 收到 POST /orders 後,送一則訊息給 Customer Service,並立刻回傳 HTTP 回應。
  • Customer Service 處理完之後,送回覆訊息給 Order Service。
  • Order Service 收到回覆後,最終確認或拒絕 Order。

Figure 4.15: Order Service handles POST /orders by sending an asynchronous message to Customer Service for credit reservation

優點:createOrder() 的可用性大幅上升——Order Service 不再等 Customer Service。

缺點:第一次的 HTTP 回應只代表部分結果,client 需透過下列方式知道最終結果:

  • 定期 polling Order Service。
  • 或訂閱 Order Service 發布的事件(approved / rejected)。

雖然非同步訊息讓 client 端體驗變複雜,但它是降低執行期耦合最強的工具之一。第 10、11 章會介紹基於非同步訊息的多種模式(saga、CQRS 等)。

Backward 建置期耦合 基礎建設耦合 Forward