做过分布式服务端的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框架不仅需要深厚技术功底，也需要提供接地气、灵活的使用方式。
