来源：mikechen的互联网架构
做过分布式服务端的程师，随着对技术底层的认知的加深，都会或多或少的会去想: 一个RPC框架（Dubbo典型代表）需要考虑的问题有哪些，如何来解决？下面我们围绕RPC通信框架，从如何实现这个角度做一个剖析
01
RPC 框架简介
单体应用时代只有内外网通信，并没有服务间通信的诉求，随着单机服务性能下降，进入多服务分布式的时代后Rpc 框架才应运而生。
通信Rpc犹如生活中电网基建一样，是分布式服务的基础组成部分，一个传输电能，一个传输数据。
RPC ，Remote Procedure Call ，字面意思是远程过程调用，主要是解决服务间连接及数据交互，但除了通信和数据交互，为适应分布式架构/微服务架构的设计。
一个好的系统设计，通常是完整、系统、可扩展、可容错、高性能、支持高并发、可跟踪、有良好的设计模式等等，RPC框架的设计需要解决@mikechen
02
通信方式设计
通信的底层是TCP/IP，在Java中网络传输通常使用Netty 或 Mina 的多路复用模型作为网络通信的底层。
1.多传输协议支持
为什么要支持多种传输协议呢？在业务中，通常会遇到各种问题，比如:
使用Http协议，虽然灵活便于管理、可以跨语言，但是明文、性能很差。使用Dubbo 传输协议，性能高、长连接，但单条大文件/数据传输可能会形成网络瓶颈。Rmi ，性能较差，短连接，但对于单次大数据量传输却比较好，其他的还有Websocket 、Https、Thrift TTransport等，传输协议各有优缺点，所以支持多传输协议是有必要的。这个其实跟传输协议是搭配的，比如RMI 通常都是使用了标准的二进制序列化目前有Protobuff、Dubbo 序列化、Hessian 、Java原生、Soap文本序列化、Http的表单序列化、Json、Thrift的TCompactProtocol等，同样各有优缺点，需要设计成可扩展的方式。03
如何找到服务(寻址)并且实现资源合理
消费者如何知道提供者，并且知道当前是否存活，是设计RPC 框架需要考虑的第二大问题。不同的业务系统，对于服务间一致性要求并不同，这里有一个CAP权衡问题。另外还要考虑是否推送提供者的变动、注册中心自身的安全问题、跨语言平台等因素。
- zookeeper，支持强一致并能通过Wacher机制主动进行通知，但可用性并不能完全保证
- Consul ，通过Http方式满足服务发现，没有语言限制，但通知实时性比ZK Wacher略差
负载均衡目的是为了最优使用同一服务间的资源使用，具体到设计中，需要考虑机器情况、服务的负载情况等。算法主要有:随机、轮询、活跃情况、一致性Hash等。
在生产环境中能通过界面化的方式提供动态的更改权重、路由等规则，实现服务动态权重、熔断、限流、灰度、多版本等功能。考虑容错机制是系统完整性的一部分，failover、failfast、failback、failsafe 、forking、Broadcast ...等，通常和负载均衡搭配。04
让业务更方便的使用
支持普通配置的同时，支持集成到Spring等主流框架使用。配置的方式也有很多种，比如支持XML、注解、YAML、Properties、Json配置等。05
可跟踪
可以进行依赖分析，数据的调用统计，并能图形、数据化将其显示出来。
实现上可以兼容现有成型的APM链路跟踪，也是设计的考虑因素之一06
其他
从架构的角度要考虑到设计模式的使用，比如常用的责任链、代理模式等。
07
最后
正如前面说的，Rpc 框架相当于电网基建，是分布式系统的基础，如果不具备可靠、高性能、高并发、使用简易等特点，就很难满足日益增长的服务治理的需要。实现RPC调用可能比较简单，但实现Rpc框架不仅需要深厚技术功底，也需要提供接地气、灵活的使用方式。