什么是RPC框架？
首先解释什么是RPC
什么是RPC
RPC是指远程过程调用,是Remote Procedure Call三个单词的缩写，功能就是本地的函数一样去调远程函数，远程一般是指通过网络从远程计算机程序上请求服务，也可以在在宿主机下通过网络进行不同架构下的互相请求服务。
RPC在分布式或者微服务架构上非常常用，RPC让不同服务之间的服务调用像本地调用一样简单高效。
为什么我们需要RPC
如果开发的是简单的单一应用，逻辑简单、用户不多、流量不大，那我们并不需要RPC。
当我们的系统访问量增大、业务增多时，我们会发现一台单机运行此系统已经无法承受。此时，我们可以将业务拆分成几个互不关联的应用，分别部署在各自机器上，以划清逻辑并减小压力。此时，我们也可以不需要RPC，因为应用之间是互不关联的。
当我们的业务越来越多、应用也越来越多时，自然的，我们会发现有些功能已经不能简单划分开来或者划分不出来。此时，可以将公共业务逻辑抽离出来，将之组成独立的服务Service应用 。而原有的、新增的应用都可以与那些独立的Service应用 交互，以此来完成完整的业务功能。
所以此时，我们急需一种高效的应用程序之间的通讯手段来完成这种需求，服务之间的调用需要各种场景和因素的考虑，内部原理非常复杂和繁琐，同时在集群情况下，服务的负载均衡，熔断，限流等都是需要去考虑的，这时候就需要一个集服务注册发现、负载均衡、序列化协议、RPC通信协议、Socket通信、异步调用、熔断降级等技术为一体的技术去完成这些公共功能，于是RPC大显身手的时候来了！
框架组成
RPC框架需要的最基本的三个要素：
- ServiceProvider: 服务提供方，提供相关服务接口。
- ServiceConsumer: 服务消费方，消费服务提供方的接口。
- Registry: 注册中心，用于进行服务的注册、发现、治理、高可用。
注册中心是RPC框架中的管理者和协调者角色，虽然在远程过程调用中服务消费者会不经过注册中心，会直接向服务提供者发送请求，但是随着我们的服务方越来越多，每个服务的实例也不断变化的，且每个服务的地址，端口等信息是需要通知到消费方的，所以我们需要一个类似“管家”的角色，来负责管理服务注册和发现的工作，这个“管家”我们称之为注册中心。
一个合格的注册中心需要具备包括缓存和持久化服务提供方数据，动态更新服务提供者信息，动态监听服务提供方节点变化，推送节点变化到消费方，查询服务提供方数据等功能。
其需要对外提供服务接口，一个服务方需要包括启动连接注册中心，注册相关信息到注册中心，提供服务下线和更新机制，维护服务名和服务的映射，序列化和反序列化，启动通信等。
服务消费方需要具备可以从注册中心拉取服务列表，缓存服务列表，动态监听和更新服务列表的功能，还需要具备针对于服务的负载均衡策略，序列化和反序列化，根据约定的通信协议进行调用等。
Go开发中的RPC框架推荐
kitex
字节跳动内部的 Golang 微服务 RPC 框架，具有高性能、强可扩展的特点，在字节内部已广泛使用。如果对微服务性能有要求，又希望定制扩展融入自己的治理体系，Kitex 会是一个不错的选择。
Kitex 官方文档: Kitex | CloudWeGo
go-zero
go-zero 是一个集成了各种工程实践的 web 和 rpc 框架。通过弹性设计保障了大并发服务端的稳定性，经受了充分的实战检验。
go-zero官方文档： go-zero 缩短从需求到上线的距离
