先拋出幾個問題

• 微服務架構的交互模式有哪些？
• 微服務常用的進程間通信技術有哪些？
• 如何處理部分請求失敗?
• API的定義需要注意的事項有哪些
• 微服務的通信機制與SOA的通信機制之間的關係與區別

微服務架構的交互模式

一對一還是一對多？

• 一對一：每個客戶端請求有一個服務實例來響應
• 一對多：每個客戶端請求有多個服務實例來響應

同步還是異步？

• 同步模式：客戶端請求需要服務端即時響應，甚至可能由於等待而阻塞
• 異步模式：客戶端請求不會阻塞進程，服務端的響應可以是非即時的

一對一的交互模式有以下幾種方式：

• 請求/響應：一個客戶端向服務器端發起請求，等待響應，客戶端期望此響應即時到達。在一個基於線程的應用中，等待過程可能造成線程阻塞。
• 通知（也就是常說的單向請求）：一個客戶端請求發送到服務端，但是並不期望服務端響應。
• 請求/異步響應：客戶端發送請求到服務端，服務端異步響應請求。客戶端不會阻塞，而且被設計成默認響應不會立刻到達。

一對多的交互模式有以下幾種方式：

• 發佈/ 訂閱模式：客戶端發佈通知消息，被零個或者多個感興趣的服務消費。
• 發佈/異步響應模式：客戶端發佈請求消息，然後等待從感興趣服務發回的響應。

微服務常用的進程間通信技術

• REST：REST即表述性狀態傳遞（英文：Representational State Transfer，簡稱REST）是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。它是一種針對網絡應用的設計和開發方式，可以降低開發的複雜性，提高系統的可伸縮性。
• Thrift：thrift是一個軟件框架，用來進行可擴展且跨語言的服務的開發。它結合了功能強大的軟件堆棧和代碼生成引擎，以構建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些編程語言間無縫結合的、高效的服務

API的定義需要注意的事項

• IPC通信方式的選擇：API的定義取決於選擇的IPC通信方式,如果是消息機制（如 AMQP 或者 STOMP），API則由消息頻道（channel）和消息類型；如果是使用HTTP機制，則是基於請求/響應（調用http的url）。
• API的版本升級：服務的API往往隨著時間的推移而不斷變化。在單體應用中，往往會直接修改API的消費者。但是在微服務中，通常不能讓所有的API消費者保持與API同步更新，可能新版本和舊版本的API同時運行。
• 消息格式的選擇：為微服務來決定最適合的消息格式是另一個關鍵要素。傳統的單體的軟件使用複雜的二進制的格式，SOA/Web services的應用使用基於複雜消息格式（SOAP）和schema（xsd）的文本消息。在大多數的微服務裡面，它們使用簡單的基於文本的消息格式，例如基於HTTP資源API風格之上的JSON/XML等。在某些情況下它們需要二進制的格式時（文本消息在某些場景下顯得囉嗦），可以使用二進制的協議例如二進制的Thrift、Protobuf、Arvo。（摘自《微服務實戰：從架構到部署》）

處理部分請求失敗

對於分佈式的微服務，必須要面對的一大問題就是局部請求失敗的處理。

Netfilix 提供了一個比較好的解決方案，具體的應對措施包括(摘自“Chris Richardson 微服務系列”)：

• 網絡超時：在等待響應時，不設置無限期阻塞，而是採用超時策略。使用超時策略可以確保資源不被無限期佔用。
• 限制請求的次數：可以為客戶端對某特定服務的請求設置一個訪問上限。如果請求已達上限，就要立刻終止請求服務。
• 斷路器模式（CircuitBreakerPattern）：記錄成功和失敗請求的數量。如果失效率超過一個閾值，觸發斷路器使得後續的請求立刻失敗。如果大量的請求失敗，就可能是這個服務不可用，再發請求也無意義。在一個失效期後，客戶端可以再試，如果成功，關閉此斷路器。
• 提供回滾：當一個請求失敗後可以進行回滾邏輯。例如，返回緩存數據或者一個系統默認值。

微服務的通信機制與SOA的通信機制之間的關係與區別

在單體應用裡面，不同組件的業務功能通過函數調用或者語言級別的方法調用來實現。在SOA中，這轉變為更加松耦合的Web Service級別的消息，主要是基於HTTP、JMS等不同協議的SOAP。Webservice 包含的幾十種操作以及複雜的消息機制是阻礙Web Services流行的一個重要因素。對於微服務架構而言，必須要有一個簡單且輕量級的消息機制。

轉發自：https://segmentfault.com/a/1190000008700797