在微服務架構（Microservices Architecture）中，服務之間並不是孤立存在的。雖然我們強調「邊界清晰、獨立部署」，但一個業務流程往往需要多個服務協同運作。例如，當使用者在電商平台下單時，訂單服務需要與商品庫存服務、支付服務、通知服務等互動，最終才能完成一次完整的交易。

因此，「服務之間該如何通訊」是微服務設計的一個核心問題。在《Microservice Architecture Pattern》之中，常見的通訊模式包含以下四種：

1. Remote Procedure Invocation (RPI)
2. Messaging
3. Domain-specific protocol
4. Idempotent Consumer

本篇將逐一介紹這些模式，並搭配案例來說明其優缺點與適用場景。

Remote Procedure Invocation (RPI)

RPI 的技術定義

RPI 模式指的是一種基於「請求/回應」的同步通訊方式。當一個服務需要另一個服務的資料或邏輯時，它會發送一個請求並等待回應，整個過程與呼叫函式非常類似，只不過跨越了服務邊界。

RPI 的技術實現

基本上，RPI 屬於我們最常見的一種服務互動模式，常見的技術實踐可以分成下列幾項：

• REST API（最普遍，基於 HTTP 協議）
• gRPC（高效能的二進位協議，適合內網高速通訊）
• Apache Thrift（跨語言 RPC 框架）
• Web Services (早期以 SOAP/XML 格式的網路服務)

【範例】
假設一個「會員註冊」的業務流程，會需要完成下列兩項動作：

• UserService 負責基本資料的建立
• EMailService 負責發送註冊驗證信

在 RPI 模式下，UserService 會呼叫 EmailService 的 API 來觸發驗證信件發送。如果 EmailService 沒有回應，則 UserService 整個操作會失敗。

使用 Remote Procedure Invocation (RPI)的模式，好處是：

• 簡單、直觀且開發人員原本就收息這種同步的呼叫模式
• 適合同步的業務邏輯，例如：即時查詢的資料

但是，在這個模式像如同我們在耦合那篇講的，這個屬於耦合性高的設計，呼叫端與被呼叫端必須同時可用。在這個情況下，跨多個服務的請求極有可能形成「雪崩效應」，服務之間互相影響逐一的崩潰。所以搭配 Service Discovery 與 Circuit Breaker 來提高其可用性可能是必備的設計。

Messaging

Messaging 的定義

Messaging 模式是一種 非同步通訊 的方式。服務透過訊息中介（Message Broker，如 Kafka、RabbitMQ）傳遞訊息，發送端只需把訊息交給中介即可，接收端在可用時再處理訊息。

常見實作方式

• Request/response：發送請求並期待回覆
• Notification：只通知，不期待回覆
• Publish/subscribe：發佈一則訊息，讓多個訂閱者接收
• Request/async response：發送請求，等待稍後的回應

【範例】

回到訂單管理系統的案例：

• OrderService 在建立新訂單後，會發送 OrderCreated 事件到 Kafka
• InventoryService 訂閱該事件，檢查庫存並更新數量
• NotificationService 也訂閱該事件，向用戶發送通知信

這樣的設計下，OrderService 並不需要知道有多少個服務會處理事件，降低了耦合度。

這個模式主要可以得到的好處「鬆散耦合」，訊息可先存放在 broker 中，即使消費者暫時不可用也不影響流程，支援多樣化的互動模式（pub/sub、async response 等）。

而缺點則是，系統複雜度上升，通常伴隨著中介軟體的維護作業，且為了確保訊息有送達，大多數會有「重送」的情況，所以在實作上還需要考慮去重。除此之外，因為低耦合的模式將造成問題追蹤困難，所以在設計上必須考量分散式追蹤的模式來進行錯誤盤查才可以滿足維運上的需求。

Domain-specific protocol

有時候，一般的 RPC 或 Messaging 並不足以滿足需求，特定領域會設計 專屬協議 來進行服務間通訊。例如：

• SMTP/IMAP：電子郵件傳輸
• RTMP/HLS/HDS：影音串流傳輸
• HL7/FHIR：醫療資訊交換標準
• FTP/SFTP：檔案傳輸協議

【範例】

在醫療系統中，不同的醫院系統可能需要交換病歷資料。這時候，使用通用的 REST API 不一定能有效處理，反而會透過 FHIR（Fast Healthcare Interoperability Resources） 這類標準化協議進行交換。

這種是針對特定領域應用的最佳化，但通常都需要額外的學習成本。

Idempotent Consumer

Idempotent Consumer 的定義

在 Messaging 模式中，訊息傳遞往往採用 at-least-once delivery，這意味著某些訊息可能會被重送多次。如果消費者在處理訊息時不是冪等的，則可能產生錯誤。

所謂 Idempotent Consumer，就是確保同一筆訊息處理多次，結果仍然一致。

【範例】

假設有一個 AccountService 負責處理「扣款」訊息：

• 若沒有 Idempotent Consumer 設計，重送一筆 AccountDebited 訊息會造成餘額被扣兩次。
• 若採用 Idempotent Consumer 設計，則會先檢查訊息 ID 是否已處理過，若是重複，則忽略。

實務作法

• 在資料庫中建立 ProcessedMessages 表，記錄已處理的訊息 ID
• 或者，將訊息 ID 與業務資料綁定，例如「訂單號 + 狀態」

增加這個機制主要是為了確保資料正確性，減少重送帶來的副作用，但是也為設計帶來了複雜度，更需要考量各種資料的「一致性」。

四種模式綜合比較

結語

微服務架構的本質是「分散式系統」，因此通訊模式的選擇會直接影響到整體系統的可用性、效能與維護性。

• RPI 適合同步即時查詢，但要搭配 Service Discovery 與 Circuit Breaker。
• Messaging 適合事件驅動的業務，需額外處理 訊息冪等性。
• Domain-specific protocol 適合特定產業，但要注意與通用 API 的整合。
• Idempotent Consumer 幾乎是必備能力，尤其在 Kafka、RabbitMQ 這類訊息系統下。

最終的設計應該根據 業務需求、團隊能力、基礎設施成熟度 來決定，沒有一種模式可以解決所有問題。