在微服務集成——《微服務設計》讀書筆記文章中，我們說過服務間的消息傳遞有幾種方式，一種是請求/響應技術，另一種是基於事件的機制。
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 著 / 崔力強 張駿 譯）