? ??在微服務集成——《微服務設計》讀書筆記文章中，我們說過服務間的消息傳遞有幾種方式，一種是請求/響應技術，另一種是基于事件的機制。

RPC（遠程過程調用）

? ? ? RPC是Remote Procedure Call的簡稱。

? ? ??這是請求/響應技術的一種，它使用本地調用的方式和遠程進行交互，如SOAP、Thrift等，比如我們常使用的WebService和Java RMI，就是這種類型。它先在本地生成樁代碼，然后通過樁代碼進行遠程調用。

? ? ? RPC會帶來一些問題，如Java RMI，其耦合性較緊，同時RPC會對調用進行大量的封裝和解封裝，同時修改接口時會造成服務的提供方和調用方都要修改。

?

REST

? ? ? REST是受Web啟發而產生的一種架構風格，REST風格包含的內容很多，Richardson的成熟度模型（http://martinfowler.com/articles/richardsonMaturityModel.html），其中有對REST不同風格的比較。

? ? ? REST本身并沒有提到底層應該使用什么協議，最常用的是HTTP，HTTP本身提供了很多功能，這些功能對于實現REST風格非常有用，比如HTTP的動詞（GET、POST、PUT等）就能很好地和資源一起使用。

? ? ? 在使用REST時，傳輸的數據格式是XML還是JSON，這個沒有一個定論。

? ? ? 基于HTTP的REST也有缺點：1.它無法幫你生成樁代碼，2.在要求低延遲的場景下，每個HTTP請求的封裝開銷可能是個問題，使用TCP、UDP可能更合適。

?

基于事件的異步協作

? ? ?? 這種方式主要有兩個部分需要考慮：微服務發布事件消費者接收事件機制。

? ? ? 消息隊列（如RabbitMQ）可以同進處理上述兩方法的問題。生產者使用API向代理發布事件，代理可以向消費者提供訂閱服務，并且在事件發生時通知消費者。這種代理甚至可以跟蹤消費者的狀態，如標記哪些消息是該消費者已經消費過的。這種系統通常具有較好的可伸縮性和彈性，但這么做會增加開發流程的復雜度，因為你需要一個額外的系統（即消息代理）才能開發及測試服務。

? ? ? 另一種方式是使用HTTP來傳播事件，ATOM是一個符合REST規范的協議，可以通過它提供資源聚合的發布服務，當服務提供方發生改變時，只需要簡單地向該聚合發布一個事件即可，消費者會輪詢該聚合以查看變化。它的缺點是：HTTP不擅長處理低延遲的場景，而且使用ATOM的話，用戶還需要自己追蹤消息是否送達及管理輪詢等工作。

? ? ? 異步架構有其復雜性，比如，消息丟失了怎么辦？消息重試失敗了怎么辦？消息重發了怎么辦？消息請求崩潰了怎么辦？我們可以通過設置最大重試、黑名單、白名單等措施來解決這些問題。但這也意味著復雜性的增加。

?

參考

? ? ? 《微服務設計》（Sam Newman 著 / 崔力強 張駿 譯）

相關文章：?

• 微服務的概念——《微服務設計》讀書筆記

• 微服務架構師的職責——《微服務設計讀書筆記》

• 建模:確定服務的邊界——《微服務設計》讀書筆記

• 微服務集成——《微服務設計》讀書筆記
  

原文地址：http://www.cnblogs.com/gudi/p/6624917.html

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的服务的协作：服务间的消息传递——《微服务设计》读书笔记的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。