这是我参与「第三届青训营 -后端场」笔记创作活动的第5篇笔记
什么是RPC
RPC（Remote Procedure Call Protocol）远程过程调用协议。一个通俗的描述是：客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。
为什么要用RPC
当我们的业务越来越多、应用也越来越多时，自然的，我们会发现有些功能已经不能简单划分开来或者划分不出来。此时，可以将公共业务逻辑抽离出来，将之组成独立的服务Service应用 。而原有的、新增的应用都可以与那些独立的Service应用 交互，以此来完成完整的业务功能。
框架组成
- APP ：应用端，调用服务
- Server 服务容器，对外提供服务
- Service Registry 服务注册表
RPC和restful api对比
REST 接口相比 RPC 更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然 REST 接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST 方式的服务依赖要比 RPC 方式的依赖更为灵活，但是当服务调用过于密集与复杂，RPC 就比较适用。
RPC的问题
- 服务宕机，对方应该如何处理
- 在调用过程中发生网络异常，如何保证消息的可达性？
- 请求量突增导致服务无法及时处理，有哪些应对措施？
稳定性保障
- 熔断:保护调用方，防止被调用的服务出现问题而影响到整个链路
- 限流:保护被调用方，防止大流量把服务压垮（降级处理/返回限流异常）
- 超时控制:避免浪费资源在不可用节点上（超时主动停掉不太重要的业务）
