深度剖析RPC框架的核心设计
做過分布式服務端的Java工程師，隨著對技術底層的認知的加深，都會或多或少的會去想: 一個RPC框架需要考慮的問題有哪些，如何來解決？
下面我們圍繞RPC通信框架，從如何實現這個角度做一個剖析，以及每個環節能做什么？
RPC框架簡介
單體應用時代只有內外網通信，并沒有服務間通信的訴求，隨著單機服務性能下降，進入多服務分布式的時代后Rpc 框架才應運而生。
通信Rpc猶如生活中電網基建一樣，是分布式服務的基礎組成部分，一個傳輸電能，一個傳輸數據。
RPC ，Remote Procedure Call ，字面意思是遠程過程調用，主要是解決服務間連接及數據交互，但除了通信和數據交互，為適應分布式架構/微服務架構的設計，通常還需要實現增值、增強的附加功能，下面展開來做一個介紹。
一個好的系統設計，通常是完整、系統、可擴展、可容錯、高性能、支持高并發、可跟蹤、有良好的設計模式等等，Rpc 框架的設計需要解決什么問題？
RPC通信方式設計
通信的底層是TCP/IP，在Java中網絡傳輸通常使用Netty 或 Mina 的多路復用模型作為網絡通信的底層。
通信底層當然還有一些優化方式，具體在Java架構師系列課程里面會涉及。
1.多傳輸協議支持
為什么要支持多種傳輸協議呢？在業務中，通常會遇到各種問題，比如:
- 跨網絡、機房問題
- 跨語言問題
- 長連接還是短連接
- 傳輸安全
- 傳輸性能
使用Http協議，雖然靈活便于管理、可以跨語言，但是明文、性能很差。通常適用于較低并發、異構系統對接、對外網關等。
使用Dubbo 傳輸協議，性能高、長連接，但目前跨語言做的還不夠，單條大文件/數據傳輸可能會形成網絡瓶頸。
Rmi ，性能較差，短連接，但對于單次大數據量傳輸卻比較好，其他的還有Websocket 、Https、Thrift TTransport等，傳輸協議各有優缺點，所以支持多傳輸協議是有必要的。
2.多數據壓縮/序列化支持
為什么要支持多序列化支持，主要考慮兩個方面
- 跨語言/異構平臺間交互
- 性能方面考慮
這個其實跟傳輸協議是搭配的，比如RMI 通常都是使用了標準的二進制序列化
目前有Protobuff、Dubbo 序列化、Hessian 、Java原生、Soap文本序列化、Http的表單序列化、Json、Thrift的TCompactProtocol等，同樣各有優缺點，需要設計成可擴展的方式。
如何找到服務（尋址）并且實現資源合理
消費者如何知道提供者，并且知道當前是否存活，是設計RPC 框架需要考慮的第二大問題
1.多樣的注冊中心支持
不同的業務系統，對于服務間一致性要求并不同，這里有一個CAP權衡問題。
另外還要考慮是否推送提供者的變動、注冊中心自身的安全問題、跨語言平臺等因素。
比如：
- Zookeeper，支持強一致并能通過Wacher機制主動進行通知，但可用性并不能完全保證
- Consul ，通過Http方式滿足服務發現，沒有語言限制，但通知實時性比ZK Wacher略差
所以注冊中心也需要做成插件化的可擴展方式。
2.多算法負載均衡、路由和多維度流量控制
負載均衡目的是為了最優使用同一服務間的資源使用，具體到設計中，需要考慮機器情況、服務的負載情況等
算法主要有隨機、輪詢、活躍情況、一致性Hash等。
在生產環境中能通過界面化的方式提供動態的更改權重、路由等規則，實現服務動態權重、熔斷、限流、灰度、多版本等功能。
3.容錯機制
考慮容錯機制是系統完整性的一部分，failover、failfast、failback、failsafe 、forking、Broadcast …等，通常和負載均衡搭配。
讓業務更方便的使用
支持普通配置的同時，支持集成到Spring等主流框架使用。配置的方式也有很多種，比如支持XML、注解、YAML、Properties、Json配置等。
?可跟蹤
可以進行依賴分析，數據的調用統計，并能圖形、數據化將其顯示出來
可跟蹤需要解決這幾個問題：
實現上可以兼容現有成型的APM鏈路跟蹤，也是設計的考慮因素之一。
RPC其他
從架構的角度要考慮到設計模式的使用，比如常用的責任鏈、代理模式等。
容器化，Kubernetes 支持等。
RPC總結
正如前面說的，Rpc 框架相當于電網基建，是分布式系統的基礎，如果不具備可靠、高性能、高并發、使用簡易等特點，就很難滿足日益增長的服務治理的需要。
實現RPC調用可能比較簡單，但實現Rpc框架不僅需要深厚技術功底，也需要提供接地氣、靈活的使用方式。
你可能也喜歡:
總結
以上是生活随笔為你收集整理的深度剖析RPC框架的核心设计的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 深度剖析开源分布式监控CAT
- 下一篇： 降低软件复杂性一般原则和方法