RPCX的產生
rpcx是一個類似阿里巴巴 Dubbo 和微博 Motan 的分布式的RPC服務框架，基於Golang net/rpc實現。
談起分布式的RPC框架，比較出名的是阿里巴巴的dubbo,包括由當當網維護的dubbox。
不知道dubbo在阿里的內部競爭中敗給了HSF，還是阿里有意將其閉源了，官方的代碼使用的spring還停留在2.5.6.SEC03的版本，dubbox的spring也只升級到3.2.9.RELEASE。
不管怎樣，dubbo還是在電商企業得到廣泛的應用，京東也有部分在使用dubbo開發。
DUBBO是一個分布式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，是阿里巴巴SOA服務化治理方案的核心框架，每天為2,000+個服務提供3,000,000,000+次訪問量支持，並被廣泛應用於阿里巴巴集團的各成員站點。微博的RPC框架 Motan 也正式開源了，如張雷所說：
2013 年微博 RPC 框架 Motan 在前輩大師們（福林、fishermen、小麥、王喆等）的精心設計和辛勤工作中誕生，向各位大師們致敬，也得到了微博各個技術團隊的鼎力支持及不斷完善，如今 Motan 在微博平台中已經廣泛應用，每天為數百個服務完成近千億次的調用。
這兩個個優秀的框架都是使用Java開發的，國外的互聯網企業也有非常出名的的RPC框架如 thrift 、 finagle 。
本項目 rpcx 的目標就是實現一個Go生態圈的Dubbo，為Go生態圈提供一個分布式的、多插件的、帶有服務治理功能的產品級的RPC框架。
Go生態圈已經有一些RPC庫，如官方的 net/rpc 、 grpc-go 、 gorilla-rpc 等，為什么還要開發 rpcx 呢？
原因在於盡管這些框架都是為Go實現的RPC庫，但是它們的功能比較單一，只是實現了點對點(End-to-End)的通訊框架。缺乏服務治理的功能，比如服務注冊和發現、負載均衡、容災、服務監控等功能。因此我基於Go net/rpc框架實現了一個類似Dubbo的分布式框架。
和rpcx比較類似的Go RPC框架是 go-micro ，但是rpcx提供了更豐富的功能，基於TCP的通訊協議性能更好。
那么rpcx 和 grpc 出來的定位是什么？ rpcx支持protobuf3嗎？
grpc 不會在企業大規模使用，或者說不會直接在企業中規模很大的服務中的推廣。因為本身它的服務治理很弱。rpcx支持protobuf3, 而且默認提供了protobuf3的編碼器實現。
RPC是什么
遠程過程調用（英語：Remote Procedure Call，縮寫為 RPC）是一個計算機通信協議。該協議允許運行於一台計算機的程序調用另一台計算機的子程序，而程序員無需額外地為這個交互作用編程。如果涉及的軟件采用面向對象編程，那么遠程過程調用亦可稱作遠程調用或遠程方法調用，例：Java RMI。簡單地說就是能使應用像調用本地方法一樣的調用遠程的過程或服務。很顯然，這是一種client-server的交互形式，調用者(caller)是client,執行者(executor)是server。典型的實現方式就是request–response通訊機制。
RPC 是進程之間的通訊方式(inter-process communication, IPC), 不同的進程有不同的地址空間。
如果client和server在同一台機器上，盡管物理地址空間是相同的，但是虛擬地址空間不同。
如果它們在不同的主機上，物理地址空間也不同。
RPC的實現的技術各不相同，也不一定兼容。
一個正常的RPC過程可以分成下面幾步：
- client調用client stub，這是一次本地過程調用
- client stub將參數打包成一個消息，然后發送這個消息。打包過程也叫做 marshalling
- client所在的系統將消息發送給server
- server的的系統將收到的包傳給server stub
- server stub解包得到參數。 解包也被稱作 unmarshalling
- 最后server stub調用服務過程. 返回結果按照相反的步驟傳給client
RPC只是描繪了 Client 與 Server 之間的點對點調用流程，包括 stub、通信、RPC 消息解析等部分，在實際應用中，還需要考慮服務的高可用、負載均衡等問題，所以產品級的 RPC 框架除了點對點的 RPC 協議的具體實現外，還應包括服務的發現與注銷、提供服務的多台 Server 的負載均衡、服務的高可用等更多的功能。目前的 RPC 框架大致有兩種不同的側重方向，一種偏重於服務治理，另一種偏重於跨語言調用。
服務治理型的 RPC 框架有 Dubbo、DubboX、Motan 等，這類的 RPC 框架的特點是功能豐富，提供高性能的遠程調用以及服務發現及治理功能，適用於大型服務的微服務化拆分以及管理，對於特定語言（Java）的項目可以十分友好的透明化接入。但缺點是語言耦合度較高，跨語言支持難度較大。
跨語言調用型的 RPC 框架有 Thrift、gRPC、Hessian、Hprose 等，這一類的 RPC 框架重點關注於服務的跨語言調用，能夠支持大部分的語言進行語言無關的調用，非常適合於為不同語言提供通用遠程服務的場景。但這類框架沒有服務發現相關機制，實際使用時一般需要代理層進行請求轉發和負載均衡策略控制。
本項目 rpcx 屬於服務治理類型，是一個基於 Go 開發的高性能的輕量級 RPC 框架，Motan 提供了實用的服務治理功能和基於插件的擴展能力。
RPCX的特點
rpcx使用Go實現，適合使用Go語言實現RPC的功能。
- 基於net/rpc,可以將net/rpc實現的RPC項目輕松的轉換為分布式的RPC
- 插件式設計，可以配置所需的插件，比如服務發現、日志、統計分析等
- 基於TCP長連接,只需很小的額外的消息頭，當然也支持Http
- 支持多種編解碼協議，如Gob、Json、MessagePack、gencode、ProtoBuf等
- 服務發現：服務發布、訂閱、通知等，支持多種發現方式如ZooKeeper、Etcd等
- 高可用策略：失敗重試（Failover）、快速失敗（Failfast）
- 負載均衡：支持隨機請求、輪詢、低並發優先、一致性 Hash等
- 規模可擴展，可以根據性能的需求增減服務器
- 雙向調用：支持客戶端與服務端雙向通信
- 跨語言調用：支持Java、Python、C#、Node.js、Php、C\C++、Rust等等來調用 rpcx 服務，通過Gateway 和 Agent
- 安全：支持白名單，限流、消息大小、身份認證等
- 調用機制：支持超時與熔斷機制
- 其他：調用統計、訪問日志、ui管理界面等
- 支持壓縮
- 支持擴展信息傳遞（元數據）
rpcx目標是輕量級的，小而簡單，但是期望所有的功能都可以通過插件的方式搭積木的方式完成。
RPCX架構
rpcx中有服務提供者 RPC Server，服務調用者 RPC Client 和服務注冊中心 Registry 三個角色。
- Server 向 Registry 注冊服務，並向注冊中心發送心跳匯報狀態(基於不同的registry有不同的實現)。
- Client 需要向注冊中心查詢 RPC 服務者列表，Client 根據 Registry 返回的服務者列表，選取其中一個 Sever 進行 RPC 調用。
- 當 Server 發生宕機時，Registry 會監測到服務者不可用(zookeeper session機制或者手工心跳)，Client 感知后會對本地的服務列表作相應調整。client可能被動感知(zookeeper)或者主動定時拉取。
- 可選地，Server可以定期向Registry匯報調用統計信息，Client可以根據調用次數選擇壓力最小的Server
當前rpcx支持zookeeper, etcd、Consul等注冊中心。
rpcx基於Go net/rpc的底層實現， Client和Server之間通訊是通過TCP進行通訊的，它們之間通過Client發送Request，Server返回Response實現。
Request和Response消息的格式都是 Header+Body 的格式。Header和Body具體的格式根據編碼方式的不同而不同，可以是二進制，也可以是結構化數據如JSON。
grpc中文文檔：https://books.studygolang.com/go-rpc-programming-guide/
refer：
https://blog.csdn.net/RA681t58CJxsgCkJ31/article/details/82455716