>原創文章，歡迎轉載。轉載請註明：轉載自IT人故事會，謝謝！
>原文鏈接地址：『高級篇』docker之微服務間如何通訊（六）
從通信模式角度考慮
說到通信可能會想到：socket，http，tcp/ip，zookeeper等等，這麼多東西在一起可能會感覺比較亂，提供個思路來考慮微服務的問題，通信方式和通信協議來考慮。
通信方式
- 一對一（同步），特別常見請求相應模式，最常見的
- 一對一（異步），某個服務發送通知的時候， 不需要等待響應，不需要對方立刻響應，而是通過回調的方式得到對方的響應。
- 沒有一對多（同步）這種場景
- 一對多（異步），發佈訂閱的方式、發佈異步響應。例如：滴滴打車，叫一輛車的時候，系統會將我這個消息告訴所有能夠接受消息的車主，他們來搶單，發出一個響應回來，就知道那位師傅搶到了單子。
通信協議
- REST API
很多人把rest api等同於 http的接口設計，其實他們不能直接化等號的，rest 是很早提出的一個概念，rest是表現層的狀態轉移，其實這個沒幾個人可以聽的懂，其實rest是網絡中客戶端和服務端的一種交互形式，它本身就是一個抽象概念，主要是如何設計一個rest api，以http爲例，就是用http協議來實現rest形式的api，
在 Web 應用中處理來自客戶端的請求時，通常只考慮 GET 和 POST 這兩種 HTTP 請求方法。實際上，HTTP 還有 HEAD、PUT、DELETE 等請求方法。而在 REST 架構中，用不同的 HTTP 請求方法來處理對資源的 CRUD（創建、讀取、更新和刪除）操作：
若要在服務器上創建資源，應該使用 POST 方法。
若要檢索某個資源，應該使用 GET 方法。
若要更改資源狀態或對其進行更新，應該使用 PUT 方法。
若要刪除某個資源，應該使用 DELETE 方法。
-
RPC
- dubbo
- motan
- dubbox
- grpc
- thrift
- MQ
消息隊列，實際場景用的不太多，例如之前說的滴滴打車這種就是消息訂閱的模式。
如何選擇RPC框架
RPC是微服務方面最多的一種情況，也是選擇比較多的情況，可選的RPC框架也非常的多，選擇一個RPC框架是需要面臨的問題。
-
I/O，線程調度模型
長連接，短連接，單線程，多線程，線程調度算法的性能
-
序列化的方式
可讀的（XML，JSON），二進制（FASTJSON），爲什麼要考慮序列化呢，因爲序列的效率直接影響到我們通信的效率，擴大了序列化和反序列化的時間，RPC的效率，同一個對象如果序列化小的話大大提升效率。
-
多語言支持
根據團隊語言，如果是多語言就需要找支持多語言的RPC框架，如果單語言例如都是java，就直接dubbo只支持java。
- 服務治理
比如有沒有服務發現，服務監控，一個擁有服務治理的RPC框架，一般支持集羣的部署和服務高可用。
目前流程RPC框架有哪些
- Dubbo/DubboX
2014年10月份，dubbo就不在維護了，時隔3年dubbo又重新開始維護，一來用戶量確實很多，二來微服務比較火，對微服務更好的支持。DubboX是在阿里的dubbo基礎上開發的一套DubboX。只支持java語言。
- Motan
一套新浪微博的，2016年5月進行的開源，號稱每天支持新浪微博的千億級別的調用量，通過spring的調用方式不需要額外的代碼就具有分佈式的能力。只支持java語言。
- Thrift
2007年facebook開發的，08年進入了apche項目，它是一個跨語言的。畢竟那麼多年，你想到的它都支持。沒有服務治理相關的東西。
- GRPC
google開源的一個項目，跟Thrift相似，也支持跨語言。
對比
PS：微服務通信的根本就是RPC通信，比http效率高，穩定性好。