原創文章，歡迎轉載。轉載請註明：轉載自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效率高，穩定性好。