rpc协议,如何实现一个分布式RPC框架？
1.定义:
明确下RPC是什么?PRC全称是Remote Procedure Call,是进程间的一种通信方式rpc协议。
2.解决的问题
进程间调用就像本地调用函数一样简单，而业务层不需要去关心通信的细。
3.组成
在Nelson的论文Implementing Remote Procedurr Calls有论述，见图1
User 调用方
User-Stub 消息拼装，编解码
RPCRuntime 发送，接受消息
Service-Stub 消息拼装，编解码
Server 服务方
4.核心实现
从图中可以看出我们需要实现Stub和RPCRuntime的功能。
Stub:主要功能是消息格式怎么定义和编解码。
消息格式:一般需要设计消息头和消息体，当然越简洁越好，提高传输效率
编解码:二进制最高效,可以使用Protocol Buffers,Thrift。当然也可以使用可读性比较好的JSON,XML。
RPCRuntime主要负责通信，这里涉及到选择什么IO模型，BIO,NIO还是AIO,可以使用netty来实现NIO功能。
5.开源实现
了解开源实现，更能促进自研的成熟稳定。当然看需求是否需要自研，一般开源就可以满足需求了。
比较好的开源实现有Dubbo,brpc,grpc,Thrift,Hessian等
6.小结
虽然RPC说起来只是进程间的通信，但是RPC服务怎么注册，发现，路由这些都还是需要考虑的。再者毕竟是网络传输，就有可能出现延迟，丢包的情况，容错性也需要多考虑考虑。这里再把RPC调用描述的全一点，见图2。图中的clinet,sever只和agent交互，agent就包含了Stub和RPCRuntime的功能，一般这里的agent实现为一个jar包，和应用程序部署在一起。
现在Service Mesh也越来越成熟了，Service Mesh把agent独立为一个进程部署（必须和业务同一机器），这样降低了耦合性，同时业务和平台独立，开发迭代速度也更快。提到Service Mesh的开源实现必提Istio。图3是Istio官网的架构图。
希望回答对你有帮助，记得点个赞哦，谢谢。也可以关注我，后面会分享一些架构的知识。
dubbo请求流程及原理？
dubbo
1) 远程通讯协议基本原理
a) 网络通信:将二进制流从一台计算机传输到另外一台计算机，基于传输协议和网络IO来实现
b) 传输协议有 、 udp, 都是在基于 Socket 概念扩展而来
c) 网络IO，主要有 bio 、 nio 、 aio, 所有的分布式应用通讯都基于这个原理而实现
过程：
狭义RPC过程
a) 假设两台服务器A，B,一个应用部署在A服务器上,想要调用B服务器上应用提供的函数/方法,由于不在一个内存空间,不能直接调用,需要通过网络来表达调用的语义和传达调用的数据
b) 首先A和B建立TCP链接,并且确定好RPC框架的网路端口,能够进行网络通信
c) 然后A服务器将需要调用B服务器的方法和参数进行序列化（Serialize）
d) 通过第一步建立的链接,将序列化后的二进制流发送给B
e) B服务器收到请求后,需要对参数进行反序列化,恢复为内存中的表达方式
f) 然后B服务器找到对应的方法（寻址的一部分）进行本地调用,然后得到返回值
g) B服务器对返回值再次进行序列化,并且通过相同的途径发送给A
h) A对B服务器返回的信息再进行反序列化,得到返回结果
i) 三个关键点
Call ID映射: 要调用的方法名, 必须是唯一的
序列化和反序列化: 二进制流
网络传输: 通过rpc协议
分布式RPC过程
a) 传输协议: thrift,hession等
b) client代理，服务引用方调用方法通过代理发送远程调用
c) 协议编解码压缩,如序列化和反序列化 netty
d) 注册中心，服务注册和服务发现,存放服务信息 zookeeper
e) 负载均衡，服务容错策略其他：服务降级，服务隔离，服务治理
4) dubbo是一个分布式RPC框架
a) 包含四个角色服务提供者(provider),消费者(consumer),服务注册配置中心(registry),监控(monitor)
b) 服务注册中心包含configServer+zookeeper,也支持redis
c) 服务提供者provider
启动时主动与ConfigServer建立Scoket长连接
同时将自己的IP,提供的服务名称，端口等信息直接发送给ConfigServer
configserver将provider提供的服务信息发送到zookeeper
zookeeper通过watcher机制推送提供者信息给消费者(此时可能没有服务消费者)
d) 服务消费者consumer
启动时主动与ConfigServer建立Socket长连接
同时将自己的IP等相应信息发送给ConfigServer
configserver将consumer提供的信息发送到zookeeper
zookeeper信息(Znode本身的增加，删除，修改，以及子Znode的变化)发生变更后通过watcher机制通知consumer, 也即推送服务提供者的信息
拿到服务提供者信息后，与它们都建立连接，后面就可以直接调用服务
当有多个服务提供者的时候，Client根据一定的规则来进行负载均衡，如轮询，随机，按权重等
消费者自己宕机了, 没法自己通知configserver和zookeeper, 只能通过心跳机制
e) 服务注册配置中心: configServer+zookeeper
configserver跟所有服务提供者和消费者作心跳检测
当某个Server不可用,就触发修改zookeeper中服务提供者的请求
zookeeper信息发生变更后,通过watcher机制通知消费者,即推送最新的服务提供者信息
消费者重新连接服务提供者
