微服務指南走北(二):微服務架構的進程間通訊(IPC)

先拋出幾個問題

  1. 微服務架構的交互模式有哪些?編程

  2. 微服務經常使用的進程間通訊技術有哪些?緩存

  3. 如何處理部分請求失敗?服務器

  4. API的定義須要注意的事項有哪些網絡

  5. 微服務的通訊機制與SOA的通訊機制之間的關係與區別架構

微服務架構的交互模式

一對一仍是一對多?

  1. 一對一:每一個客戶端請求有一個服務實例來響應框架

  2. 一對多:每一個客戶端請求有多個服務實例來響應異步

同步仍是異步?

  1. 同步模式:客戶端請求須要服務端即時響應,甚至可能因爲等待而阻塞編程語言

  2. 異步模式:客戶端請求不會阻塞進程,服務端的響應能夠是非即時的分佈式

一對一的交互模式有如下幾種方式:

  1. 請求/響應:一個客戶端向服務器端發起請求,等待響應,客戶端指望此響應即時到達。在一個基於線程的應用中,等待過程可能形成線程阻塞。函數

  2. 通知(也就是常說的單向請求):一個客戶端請求發送到服務端,可是並不指望服務端響應。

  3. 請求/異步響應:客戶端發送請求到服務端,服務端異步響應請求。客戶端不會阻塞,並且被設計成默認響應不會馬上到達。

一對多的交互模式有如下幾種方式:

  1. 發佈/ 訂閱模式:客戶端發佈通知消息,被零個或者多個感興趣的服務消費。

  2. 發佈/異步響應模式:客戶端發佈請求消息,而後等待從感興趣服務發回的響應。

微服務經常使用的進程間通訊技術

  1. REST:REST即表述性狀態傳遞(英文:Representational State Transfer,簡稱REST)是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。它是一種針對網絡應用的設計和開發方式,能夠下降開發的複雜性,提升系統的可伸縮性。

  2. 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流行的一個重要因素。對於微服務架構而言,必需要有一個簡單且輕量級的消息機制。

參考文章:


by 劉迎光@螢火蟲工做室
OpenBI交流羣:495266201
MicroService 微服務交流羣:217722918
mail: liuyg#liuyingguang.cn
博主首頁(==防止爬蟲==):http://blog.liuyingguang.cn
OpenBI問答社區:http://www.openbi.tk

相關文章
相關標籤/搜索