一个RPC系统应该是怎样的？

1.理解好RPC

RPC全称是远程过程调用，在面向对象模型下可称为远程方法调用。在企业级微服务系统中，服务众多，拓扑复杂，服务之间有大量的网络通讯需求。而RPC是服务间通讯的关键手段之一（MQ是另一种常见的手段），是微服务系统的重要基础设施。而作为基础设施，RPC系统需要封装好跨服务方法调用的网络细节，提供简洁的SDK(一般是接口定义+动态代理)，使得业务RD做业务开发进行RPC调用时与调用本地方法没有差异，进而提升业务迭代速度。

rpc真这么简单吗？

2.一个RPC系统要考虑什么问题？

RPC系统远远没有上面说的这么简单，实现跨服务方法调用只是需要解决的问题的冰山一角。一个企业级的RPC系统需要解决如下问题：

1. 需要定义合适的应用层协议以及对象序列化方式

首先明确，HTTP协议也可以用来实现RPC，但它的主要功能是外部用户对系统的请求，而并不用于系统内部的服务通讯。

主要原因是HTTP协议编码不够高效，在拓扑复杂的微服务系统中，rpc调用量是巨大的，rpc的请求/响应的传输数据量会极大影响到系统整体性能，所以一般而言会选择专门定制协议使得传输的数据尽量精简，去除冗余；

另一方面，RPC系统一般又会配套各种监控系统(例如链路追踪)，而在数据采集上，往往也需要网络协议予以支持，自研的协议往往能据此进行定制，更好的适配。

对象序列化上需要综合考虑安全性，通用性，序列化后的数据体量。

2. 需要选择合适的网络IO模型

一般会选择IO多路复用模型，例如Netty框架，来满足海量并发

3. 如何标识服务？

一个RPC系统需要对一个服务做唯一标识(appKey)，服务与服务间通过appKey相认。

4. 需要配有服务发现与注册中心，并且其本身必须集群部署，保证高可用，另外也要考虑一致性问题(一般会引入zookeeper)。

真实生产环境中，一个服务绝不可能只有一个实例，往往是集群部署。大型互联网公司还会跨机房跨地域部署来保证服务的高可用性。那么当服务A要调用服务B时，A如何知道要调用B的哪个实例呢？显然，这时需要去一个第三方机构查询。这个第三方机构就是单独部署的服务发现与注册中心。服务发现与注册中心会提供如下服务：

• 注册

新上线的服务或老服务新添加的实例，会拿自己的appKey到服务发现与发现中进行注册。之后服务发现与注册中心会不断对其进行健康检查(网络心跳包)，并及时更新状态，下掉异常服务

• 发现

需要发起RPC时，调用方会拿目标appKey去服务注册与发现中心查询，会得到一个目标服务当前的可用实例级，之后会通过某种策略选择一个实例进行调用(一种客户端负载均衡)

5. 安全机制：负载均衡，限流熔断

RPC客户端发起调用时，需要均匀的打到目标服务的所有实例，防止某个实例负载过大。

某实例QPS过大时，一般需要限流，防止其崩溃。

在一次长链路调用中，下游一个服务出现异常半天不返回，或变为不可用。此时上游各服务的请求会出现堆积，逐渐消耗完机器资源，最终可能会发生级联崩溃，拖垮系统。所以当一个服务出现异常时，需要将其熔断，快速返回一个协商好的可处理兜底结果。

负载均衡，限流，熔断有许多策略，一般也会单独部署一个系统，其提供面板供RD配置，代码层面提供SDK，可能会与RPC的SDK集成

6. RPC监控

监控建设很重要，很重要，很重要！自己写项目可能没有感受，但是在企业中会发现，问题的排查强依赖于监控建设。企业级微服务系统服务个数绝不是自己练手时三四个那么简单，往往是拓扑复杂，链路很长，并且期间还可能会频繁的与其他中间件交互（MQ，DB，缓存等）。所以没有健全的监控建设，很难快速定位问题。

各类监控建设中最重要的就是链路追踪系统。链路追踪系统负则追溯一次调用的完整路径以及各个步骤的调用耗时（有些还会记录每一环节的入参/出参）。一般会用一个全局唯一id(traceId)来唯一标识一次调用。一般也会有单独部署的第三方系统，在每一环节的入口出口通过SDK向其上报数据。

另外一般还会记录各个RPC接口的QPS，调用量等基础监控数据，形成数据大盘，并配置相应告警，为需求后续的维护优化提供第一手材料。

3.总结，再理解RPC

RPC字面意思简单纯粹：远程过程调用。但为了在生产环境下实现这一目标，要考虑方方面面，到头来我们发现，实现RPC字面表述的功能真的只是实现整个RPC系统的冰山一角。除此之外我们需要服务注册与发现中心，需要监控建设，需要安全保护，而其中任何一个都需要单独部署服务，并提供SDK，建设投入都是巨大的。

再来看一次RPC调用：