遠程過程調用（Remote Proredure Call, RPC）是一種非常傳統的技術，通過它，可以跨進程、跨機器（操作系統可以相同，也可以不同）進程過程調用
6.1 分佈式服務調用中間件簡介
- RPC的基礎是序列化（marshalling）和反序列化（unmarshalling），因爲一切RPC消息、參數、返回值和異常等都需要被序列化後才能跨節點傳遞。
- gRPC是谷歌公司根據自己的原有產品Protocol Buffers的基礎上，開發並開源的產品。
- Thrift是Facebook爲了解決不同語言（PHP、Python、C++等）寫的大量服務之間的通信問題而開發的
- 阿里巴巴在RPC基礎上，還需要對服務進行管理（即所謂的服務治理），開發Dubbo/DubboX和Motan
- 百度sofa-pbrpc，解決內網中大量的異步調用問題，採用epoll+Protocol Buffers
6.2 分佈式服務調用中間件的實現原理
Dubbo是阿里巴巴開源的、基於Java的著名“RPC+分佈式服務治理”框架。
6.2.1 Dubbo的架構
- Dubbo服務器：對外提供服務的組件，服務由Java語言的接口描述。
- Dubbo客戶端：Dubbo服務的消費者
- 服務註冊中心：所有的Dubbo服務必須先向服務註冊中心註冊
- 服務監控中心：服務端與客戶端每隔一定時間，就將一些監控信息（如某個方法的調用次數、調用時消耗的時長等）發給服務監控中心
6.2.2 Dubbo中各組件的交互
- 1.Dubbo服務器端啓動後向服務註冊中心它提供的服務列表
- 2.Dubbo客戶端向服務註冊中心查詢提供某個服務的服務端列表
- 3.服務註冊中心返回服務提供者的地址列表給Dubbo客戶端，如果有變更，服務註冊中心將採用長鏈接推送變更數據給消費者
- 4.Dubbo客戶端從服務提供者地址列表中，基於某種軟負載均衡算法，選一個提供者進行調用，如果調用失敗，就選另一個重試
- 5.Dubbo服務端將執行結果返回給Dubbo客戶端
- 6.Dubbo客戶端和服務端，在內存中累計調用次數和調用時長，每隔一段時間就發送一次統計數據給服務監控中心。
6.2.3 Dubbo的實現及特點
- Dubbo僅支持Java語言
- Dubbo與Spring的集成非常好
- Dubbo的服務註冊中心支持ZooKeeper、Redis和IP多播
- Dubbo支持多種負載均衡機制：隨機（random）、輪詢（round robin）、最少活躍調用數（least active）、一致性哈希（consistent hash）
6.2.4 Dubbox
Dubbox是噹噹網開源的基於Dubbo的升級版
- 支持REST風格的遠程調用（HTTP+JSON/XML）:
- 有了REST調用支持，Dubbo就可以支持REST風格的“微服務”
- 支持基於Kryo和FST的Java高效序列化實現，顯著提高了Dubbo RPC的性能
6.3 其他分佈式服務調用中間件
6.3.1 Protocol Buffers
谷歌的Protocol Buffers 是在RPC中常用的一種序列化和反序列化庫，與語言和平臺無關。
6.3.2 gRPC
- Protocol Buffers 只解決了數據的序列化和反序列化問題，要想使用RPC，還得有個框架，以解決消息的發送、解析、路由、線程管理等一系列問題。
- gRPC是谷歌開源的、基於Protocol Buffers的優秀的RPC調用中間件
- gRPC可以很好地解決企業內部服務間的通信問題。
- grpc-gateway可以解決外部客戶通過REST服務來調用內部的gRPC服務
6.3.3 Thrift
Facebook爲了解決不同語言之間的RPC問題。
6.3.4 Motan
是新浪微博開源的一個與Dubbo/Dubbox非常類似的RPC框架
6.3.5 sofa-pbrpc
百度採用“epoll+線程池”方式，因此對高吞吐、低延遲、高併發連接數的場景支持的非常好
6.4 分佈式服務調用中間件的應用
- 下半部分使用gRPC實現的各個核心業務，每個都是獨立的微服務，擁有自己的緩存、自己的存儲和自己的開發團隊。
- 上半部分運行在Web服務器中：gRPC服務的REST代理是一些微服務的REST包裝，使用grpc-gateway實現，對外部客戶提供REST風格的服務。這樣，外部客戶也可以使用該電商的一些核心服務（如快遞服務）