在大型项目中，系统间经常需要交互，一般就同步与异步两种，同步的话一般被称为RPC调用，网上有关RPC的开源框架有很多，当然也有很多公司没有使用网上的开源框架，而是公司自研。
设计
因为RPC用途广泛，明白其原理很重要，最好是自己实现一个简单的，结合我平时使用RPC的经验，来说说设计RPC的时候需要考虑的点。
服务注册与发现
系统很多的话，不可能让每个系统都知道其他系统的地址，服务啊什么的，肯定要找一个便捷的方式能够发现其他的服务。一般服务都会有自己的名字，这点和域名很像，纯碎记忆IP地址很难，人们队字符比较敏感，所以字符更容易记忆一些。
系统A如果想要调用B的话，肯定要知道B的地址，在系统很少的时候，我们还可以手工配置，但是想想系统成千上万的时候，手工将会非常的麻烦。
- 系统增多，需要有专门的服务中心来管理所有的服务信息，现在系统A想要调用B的时候，首次会先去服务注册中心拿服务信息，然后再调用B
注册中心只需要能存储服务信息即可，并且一定要保证高可用，不要服务中心挂掉了，所有的服务都用不了，常用的软件：
- Zookeeper
- Etcd
- Consul
- Nacos
像Zookeeper只提供存储，具体的如何发现，如何注册，还需要编码实现。服务注册与发现是RPC框架中一个很基础的部分，首先我们应该想到的就是它。
一般服务名称为：
- 项目名.模块名.功能名.版本号
服务入口
在Java中，远程调用，我们不可能把每个服务接口都暴露在外面，而是一个入口接受参数，再由这个入口分发到系统内部的某个服务，调用后返回结果。
序列化
因为涉及到网络传输，序列化反序列化也是必不可少的，组件，一般常用的序列化工具有
- grpc
- hession
- java自带的序列化
- json/xml
扩展点
一般服务器在部署的时候都是集群部署的，在发现服务的时候可能有多台机器，这个时候需要特定的负载均衡算法选择具体的服务器。常见的负载均衡算法
- 轮询
- 随机
- 权重
- 最少连接
- ip_hash
也有可能在调用服务的时候发现某些服务不可用，那么要能保证自动的重试，可配置重试次数。在经过多次尝试之后，达到了最大的尝试次数还是不行，那么可进行服务降级，熔断处理。
最后
原本以为自己想的挺多的，梳理一下，发现暂时就这样了，如果等后面我看完了某个流行的开源RPC框架源码，再去设计这个框架，想必会比现在更详细
