『高級篇』docker之微服務(wù)間如何通訊（六）

原創(chuàng)文章，歡迎轉(zhuǎn)載。轉(zhuǎn)載請注明：轉(zhuǎn)載自IT人故事會，謝謝！
原文鏈接地址：『高級篇』docker之微服務(wù)間如何通訊（六）

從通信模式角度考慮

說到通信可能會想到：socket，http，tcp/ip，zookeeper等等，這么多東西在一起可能會感覺比較亂，提供個思路來考慮微服務(wù)的問題，通信方式和通信協(xié)議來考慮。

通信方式

• 一對一（同步），特別常見請求相應(yīng)模式，最常見的
• 一對一（異步），某個服務(wù)發(fā)送通知的時候， 不需要等待響應(yīng)，不需要對方立刻響應(yīng)，而是通過回調(diào)的方式得到對方的響應(yīng)。
• 沒有一對多（同步）這種場景
• 一對多（異步），發(fā)布訂閱的方式、發(fā)布異步響應(yīng)。例如：滴滴打車，叫一輛車的時候，系統(tǒng)會將我這個消息告訴所有能夠接受消息的車主，他們來搶單，發(fā)出一個響應(yīng)回來，就知道那位師傅搶到了單子。

通信協(xié)議

• REST API

  很多人把rest api等同于 http的接口設(shè)計，其實他們不能直接化等號的，rest 是很早提出的一個概念，rest是表現(xiàn)層的狀態(tài)轉(zhuǎn)移，其實這個沒幾個人可以聽的懂，其實rest是網(wǎng)絡(luò)中客戶端和服務(wù)端的一種交互形式，它本身就是一個抽象概念，主要是如何設(shè)計一個rest api，以http為例，就是用http協(xié)議來實現(xiàn)rest形式的api，

在 Web 應(yīng)用中處理來自客戶端的請求時，通常只考慮 GET 和 POST 這兩種 HTTP 請求方法。實際上，HTTP 還有 HEAD、PUT、DELETE 等請求方法。而在 REST 架構(gòu)中，用不同的 HTTP 請求方法來處理對資源的 CRUD（創(chuàng)建、讀取、更新和刪除）操作：
若要在服務(wù)器上創(chuàng)建資源，應(yīng)該使用 POST 方法。
若要檢索某個資源，應(yīng)該使用 GET 方法。
若要更改資源狀態(tài)或?qū)ζ溥M行更新，應(yīng)該使用 PUT 方法。
若要刪除某個資源，應(yīng)該使用 DELETE 方法。

• RPC

  1. dubbo
  2. motan
  3. dubbox
  4. grpc
  5. thrift
• MQ

  消息隊列，實際場景用的不太多，例如之前說的滴滴打車這種就是消息訂閱的模式。

如何選擇RPC框架

RPC是微服務(wù)方面最多的一種情況，也是選擇比較多的情況，可選的RPC框架也非常的多，選擇一個RPC框架是需要面臨的問題。

• I/O，線程調(diào)度模型

  長連接，短連接，單線程，多線程，線程調(diào)度算法的性能

• 序列化的方式

  可讀的（XML，JSON），二進制（FASTJSON），為什么要考慮序列化呢，因為序列的效率直接影響到我們通信的效率，擴大了序列化和反序列化的時間，RPC的效率，同一個對象如果序列化小的話大大提升效率。

• 多語言支持

  根據(jù)團隊語言，如果是多語言就需要找支持多語言的RPC框架，如果單語言例如都是java，就直接dubbo只支持java。

• 服務(wù)治理

  比如有沒有服務(wù)發(fā)現(xiàn)，服務(wù)監(jiān)控，一個擁有服務(wù)治理的RPC框架，一般支持集群的部署和服務(wù)高可用。

目前流程RPC框架有哪些

• Dubbo/DubboX

  2014年10月份，dubbo就不在維護了，時隔3年dubbo又重新開始維護，一來用戶量確實很多，二來微服務(wù)比較火，對微服務(wù)更好的支持。DubboX是在阿里的dubbo基礎(chǔ)上開發(fā)的一套DubboX。只支持java語言。

• Motan

  一套新浪微博的，2016年5月進行的開源，號稱每天支持新浪微博的千億級別的調(diào)用量，通過spring的調(diào)用方式不需要額外的代碼就具有分布式的能力。只支持java語言。

• Thrift

  2007年facebook開發(fā)的，08年進入了apche項目，它是一個跨語言的。畢竟那么多年，你想到的它都支持。沒有服務(wù)治理相關(guān)的東西。

• GRPC

  google開源的一個項目，跟Thrift相似，也支持跨語言。

對比

PS：微服務(wù)通信的根本就是RPC通信，比http效率高，穩(wěn)定性好。