实现自己的RPC框架的细节思考

对于RPC的原理与解决问题无需多言，在构建了一个初步的思路以后，

1.RPC的核心流程

服务的发布

能够实现动态服务的发布的几种常见模式：

• 1)zookeeper，zookeeper简单易用，服务名使用使用持久化节点，提供服务的机器采用临时节点注册到服务名节点分支下即可实现。可靠行与一致性均超过其他方案，最通用的注册中心，可跨机房部署，存储能力有限。

• 2)cache，memcached与redis的cas-API均可以简单实现服务的注册，提供服务的机器将自己添加到服务名key对应的列表内，再使用主机名作为key添加一个较短生命周期的值作为心跳，定期维护心跳的key不被销毁，订阅机定期取心跳以确认其状态。性能较高但可靠性较差，一主多备模式无法保证强一致性，但是其较高的QPS能力可适用于需要为上下游业务提供较多即时个性化信息的场景。

• 3)db，服务注册数据表来提供服务注册，至少包含以下几个列：主机名、服务名、心跳。此方案适用于微型系统，正常情况下所有系统都依赖了数据库服务，所以此方案不需要额外部署其他服务。

• 4)配置推送，使用配置推送中间件来完成服务的动态发布，定期推送新的服务。个人感觉没有什么特别的优势。

个人想法，在选择使用ZK提供了服务注册以外，可以额外使用cache来提供数据存储，如路由规则、流量数据等，暴露一些信息给下游调用方。

何时注册服务

• 项目在启动以后，可能依赖的上游接口并未准备好，又或是某些需求场景

。。。待整理

服务的订阅

通讯方式

• 通讯协议
  长链接与短链接

• 序列化协议

线程池优化
超时

路由规则与负载均衡
用户性，单用户定向发送
机房性，机房优先性 1.完全的回馈系统

调用链记录

集群的限流

模型抽象，处理管线的引入

其他需要注意的地方