这是我参与「第三届青训营 -后端场」笔记创作活动的第5篇笔记。
硬核文，学习就完事了，因为之前没有接触过，不太熟练，还有因为时间原因，没有得到实践，就浅浅记录一下了解的概念。
引入
基于之前对于架构的学习了解，有单体架构、垂直应用架构还有微服务架构。随着公司规模的扩大，以及业务量的激增，单体应用逐步演化为服务/微服务的架构模式， 服务之间的调用大多采用rpc的方式调用，或者消息队列的方式进行解耦。PRC框架主要为了两个目标：
- 支持服务治理，主要的精力放在服务发现、路由、容错处理等方面。
- 支持跨语言，服务端可以用不同的语言实现，客户端也可以用不同的语言实现，不同的语言实现的客户端和服务器端可以互相调用。
对于RPC框架的理解
RPC（Remote Procedure Call Protocol）远程过程调用协议。比较正式的描述是：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
下面是我从一篇文章中看到的，觉得比较容易理解的关于RPC框架的一些定义。
服务提供端 Server 向注册中心注册服务，服务消费者 Client 通过注册中心拿到服务相关信息，然后再通过网络请求服务提供端 Server。 总的来说就是，客户端在不知道调用细节的情况下，调用存在于远程计算机上的某个对象，就像调用本地应用程序中的对象一样。当然合格的RPC框架不只那么简单，不仅要提供服务发现功能，还要提供负载均衡、容错等功能。
使用RPC框架的关注点
稳定性
采用熔断、限流、超时控制等方式，防止被调用的服务出现问题而拖垮整个链路，避免因等待调用而浪费资源。
易用性
拥有合理的默认参数选项、丰富的文档以及简单易用的命令行工具。
扩展性
一次请求会经过多个层面，拥有高拓展性。
观测性
除了Log、Metric、Tracing,还内置观测服务例如环境变量、配置、缓存信息等。
高性能
能够适应多种请求
使用RPC框架的好处
- 单一职责，开发(采用不同的语言)、部署以及运维都是独立的。
- 可扩展性强，例如压力过大的时候可以独立扩充资源，底层基础服务可以复用，节省资源。
- 某个模块发生故障，不会影响整体的可靠性。
