RPC架构设计方法论.docx

? ? RPC架构设计方法论 ? ? 读完本文你会收获： 通过一种宏观的视角设计一种灵活的可扩展的RPC架构 分块介绍服务发现、健康监测、路由策略、负载均衡、异常重试的解决方案 如何优雅的启动和关闭RPC服务，以及如何通过熔断限流及业务分组来增强架构的鲁棒能力 文章目录 1 可扩展RPC框架设计图 2 分模块解析 2.1 服务发现 2.1.1 基于DNS的服务发现 2.1.2 基于VIP的服务发现 2.1.3 基于 ZooKeeper 的服务发现 2.1.4 基于消息总线的最终一致性的注册中心 2.2 健康监测 2.2.1 健康检测的逻辑 2.2.2 可用率 2.2.3 分布式部署 2.3 路由策略 2.3.1 路由策略的意义 2.3.2 路由策略的实现 2.3.3 参数路由 2.4 负载均衡 2.4.1 RPC中的负载均衡 2.4.2 自适应负载均衡实现 3 增强架构鲁棒性的手段 3.1 重试机制 3.1.1 RPC 框架的重试机制 3.2 优雅启动 3.2.1 程序启动可能带来的问题 3.2.2 启动预热 3.2.3 延迟暴露 3.3 优雅关闭 3.3.1 硬关闭的问题 3.3.2 关闭流程 3.3.3 优雅关闭 3.4 熔断限流 3.4.1 服务端自我保护 3.4.2 调用端的自我保护 1 可扩展RPC框架设计图 ??RPC 本质上是一个远程调用，那肯定就需要通过网络来传输数据，所以采用TCP协议和HTTP协议，这两个模块共同构成了传输层。 ??请求是调用了远程方法，方法出入参数都是对象数据，我们需要提前把对象转成可传输的二进制，即序列化过程。我们还需要在二进制数据里适当位置增加分隔符号来分隔出不同的请求，所以我们可以把这两个处理过程放在架构中的同一个模块，统称为协议模块。 ??除此之外，还要在协议模块中加入压缩功能，因为在实际的网络传输过程中，请求数据包在数据链路层可能会因为太大而被拆分成多个数据包进行传输，为了减少被拆分的次数，从而导致整个传输过程时间太长的问题。 ??RPC架构的目的是让开发人员像调用本地方法一样来调用，所以需要我们在 RPC 里面把这些细节对研发人员进行屏蔽，让他们感觉不到本地调用和远程调用的区别，整体对应上面图里的入口层。 ??我们还要让架构支持集群功能，在 RPC 里面我们需要在 RPC 里面维护好接口跟服务提供者地址的关系，这样调用方在发起请求的时候才能快速地找到对应的接收地址，即服务发现。 ??此外 TCP 是有状态协议，所以我们的 RPC框架里面要有连接管理器去维护 TCP 连接的状态。 ??有了集群之后，提供方需要管理好这些服务了， RPC 就需要内置一些服务治理的功能，比如服务提供方权重的设置、调用授权等一些治理手段。 ??为了使RPC架构更灵活，便于以后功能扩展，我们需要考虑插件化架构，我们可以将每个功能点抽象成一个接口，将这个接口作为插件的契约，然后把这个功能的接口与功能的实现分离，并提供接口的默认实现。 这样一来，我们的设计实现了开闭原则，用户可以非常方便地通过插件扩展实现自己的功能，而且不需要修改核心功能的本身；其次就是保持了核心包的精简，依赖外部包少，这样可以有效减少开发人员引入 RPC 导致的包版本冲突问题。 2 分模块解析 2.1 服务发现 ??为了高可用，服务提供方都是以集群的方式对外提供服务，集群里面的这些 IP 随时可能变化，我们也需要用一本通讯录及时获取到对应的服务节点。 ??对于服务调用方和服务提供方来说，其契约就是接口，相当于“通信录”中的姓名，服务 IP 集合作为通讯录中的地址，从而可以通过接口获取服务 IP 的集合来完成服务的发现。 服务注册：在服务提供方启动的时候，将对外暴露的接口注册到注册中心之中，注册中心将这个服务节点的 IP 和接口保存下来。 服务订阅：在服务调用方启动的时候，去注册中心查找并订阅服务提供方的 IP，然后缓存到本地，并用于后续的远程调用。 2.1.1 基于DNS的服务发现 ??如果基于 DNS 来做服务发现，所有的服务提供者都配置在了同一个域名下，调用方的确可以通过 DNS 拿到随机的一个服务提供者的 IP并与之建立长连接，但由于以下两个原因，导致其并不适用于RPC架构： 如果某个 IP 端口下线了，服务调用者不能及时剔除掉服务节点； 如果对某个服务进行节点的扩容，新上线的服务节点无法及时接收到流量。 ??因为为了提升性能和减少 DNS 服务的压力，DNS采取了多级缓存机制，一般配置的缓存时间较长，特别是 JVM 的默认缓存是永久有效的，所以服务调用者不能及时感知到服务节点的变化。 2.1.2 基于VIP的服务发现 ??我们还可以在上面的加一个负载均衡设备，通过 DNS 拿到负载均衡的 IP。这样服务调用的时候，服务调用