簡介
在一個monolithic應用程式中，元件彼此調用是通過語言級别的方法或函數調用完成的。相反地，一個基于微服務的應用程式是運作在多台機器上的分布式系統。每個服務執行個體通常是一個獨立的程序。
是以，如圖3-1所示，服務之間需要使用一種 IPC 機制來進行互動。
在我們讨論具體的 IPC 技術之前，讓我們先來看看各種互動設計思路。
Interaction Styles
當為一個服務選擇 IPC 機制時，首先應該思考服務之間是如何進行互動的。存在很多用戶端-伺服器互動方式。可以從兩個次元來劃分互動方式。第一個次元，互動是一對一還是一對多的：
- One-to-one：每個用戶端請求隻被一個服務執行個體處理
- One-to-many：每個用戶端請求被多個服務執行個體處理
第二個考慮次元，互動是異步的還是同步的：
• Synchronous–Theclientexpectsatimelyresponsefromtheserviceandmighteven block while it waits
• Asynchronous – The client doesn’t block while waiting for a response, and the response, if any, isn’t necessarily sent immediately.
- 同步：用戶端希望得到服務的及時響應，在得到響應以前甚至可能會一直阻塞
- 異步：用戶端在等待響應時不會阻塞，服務端也不必立即響應結果
下表總結了各種互動方式。
有以下幾種 one-to-one 的互動方式，既有同步的也有異步的：
- Request/response：用戶端向服務發起請求，用戶端希望響應結果能立即到達。在一個基于多線程的應用程式中，處理請求的線程可能會因為等待響應而阻塞住
- Notification：也被稱作 one-way request，用戶端向服務發起請求，但不需要響應
- Request/async response：A client sends a request to a service, which replies asynchronously The client does not block while waiting and is designed with the assumption that the response might not arrive for a while.
有以下兩種一對多互動方式，都是異步的：
- Publish/subscribe：用戶端發出通知消息，該消息将被0個或多個感興趣的服務消費
- Publish/async responses：A client publishes a request message, and then waits a certain amount of time for responses from interested services
每個服務通常會是使用以上這些互動方式的一種組合。對某些服務來說，使用一種IPC 機制就可以了，而其他服務可能會需要使用一種組合方案。
圖3-2顯示了，當打車軟體中的使用者發起一個行程時，軟體中的所有服務可能是如何互動的。
圖示叫車服務使用了notifications、request/response和 publish/subscribe 三種互動方式的組合。例如，乘客的智能手機發送了一個notification到 行程管理服務請求搭載。行程管理服務采用request/response 方式調用乘客管理服務來驗證乘客賬戶是否線上。然後行程管理服務建立行程，并采用 Publish/subscribe 方式去通知其他服務，包括配置設定司機服務，該服務職責是定位一個有效的司機。
在已經了解了互動方式後，讓我們看看如何來定義 API。