如何实现一个RPC

首先RPC(远程服务调用)的概念相信大家都不陌生，无论是SpringCloud、Dubbo还是ZRPC，这些RPC框架大家都多多少少用过或者有过接触，就我自身而言，最早使用过SpringCloud，对于Dubbo并没有真正在生产环境使用过，自从Dubbo3.0发布之后，我最近有段时间也一直在了解并有深入了解Dubbo的框架原理，后续等自己认识深入之后，会陆续把自己的使用认识整理一下也贴出来。目前自己所在的公司有着一套基于Thrift自研的RPC框架，就我了解来看，由于基础架构部门现在都转向业务，公司这套RPC框架使用有较多的问题，配置过于繁重，很多问题没有解决，对于负载均衡、注册中心、集群策略等都是比较简单的一种实现。自己想更深入的了解RPC的框架原理，并且以后更好的使用，排查问题，所以自己最近一直在想怎么才能更全方面、更深入的了解RPC，熟悉了解一个事物，最好的方法莫过于亲手去实践，实现一个Demo版本的RPC，用输出的方式来创造更多的输入！

那么该如何设计一个RPC呢，从Dubbo官网上我们可以看到一张很经典的RPC的架构图
如下图

• 初始化时，服务端向注册中心注册
• 客户端从注册中心获取服务端的列表，注册需要的服务
• 当服务端有变化时，注册中心通知客户端
• 客户端通过动态代理的方式反射调用服务端
• 实现了像调用本地服务一样调用远程服务

https://blog.csdn.net/qq_39545674/article/details/114379523?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-7.control&depth_1-utm_source=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromBaidu%7Edefault-7.control

设计一个RPC框架需要包括哪些方面呢

• 注册中心：注册中心负责服务的注册和发现，相当于目录服务。服务端启动的时候将服务名称及其对应的地址（IP和端口）注册到注册中心，消费端根据服务名称找到对应的服务地址。有了服务地址，就可以通过网络请求到服务端了。选型Zookeeper or Redis。
• 网络传输：网络通信的话，肯定是采用号称性能之王的Netty
• 序列化：涉及网络通信的话，肯定就涉及到序列化
• 动态代理：使用动态代理可以屏蔽远程方法调用的细节，比如网络传输
• 负载均衡：随机、轮询、Hash、加权轮询

负载均衡：随机、轮询、Hash、加权轮询