RPC实战与核心原理笔记＜三＞

RPC实战与核心原理笔记＜三＞

1、服务的发现

1.1、为什么需要服务发现

在RPC调用中，consumer端需要知道provider的ip和端口分别是多少，只有这样才可以建立TCP连接，才能发送数据。那么如何告诉consumer关于provider的这些信息呢？另外，这些信息可能会随时发生变化，例如provider扩容了，缩容了，重启端口变化了…

因此这个如果写死，或者类似的方式肯定是不行的，因为这个信息是随时变化的，那么如何解决呢？这里便引入了服务发现。提供服务发现的是注册中心。

之所以和注册中心之间的是双向箭头，是因为注册中心还可以完成配置下发的功能，例如下发权重，负载均衡算法等这些配置。

在服务提供者启动的时候，将该服务对应的ip和端口信息通过网络发送给注册中心，注册中心缓存起来，然后，服务调用方启动的时候，去注册中心拉取服务对应的provider列表，然后缓存到本地，为了容灾使用，也可以写一份本地文件，另外，如果provider列表有什么变化，注册中心会将变化推送到服务调用方，服务调用方也可以定时轮训去注册中心拉取proivder列表，这样推拉结合的方式，可以更高的保证可靠性。

1.2、注册中心选择CP还是AP

CP就是当网络发生分区的时候，整个集群不对外提供服务，直至网络恢复，数据同步完毕。
AP就是当发送网络分区的时候，整个集群继续对外提供服务，虽然此时多个节点的数据可能是不一致的。

注册中心的选型自然是AP，因为只要满足最终一致性，可用性对注册中心是很重要的，不能因为发生了网络分区，整个集群不能对外使用了。

1.3、注册中心面临的一些问题

• 注册中心本身如何服务发现：什么意思呢？因为provider / consumer都要连接注册中心，其实这也是一次RPC，那么consuemr / provider如何知道注册中心列表呢？注册中心地址发生变化了，又如何动态感知呢？解决这个问题需要引入一个HTTP服务，服务方通过这个HTTP服务，获取注册中心地址，并且定时拉取更新本地注册中心地址列表。另外这个HTTP服务需要提供一些能力，比如，高可用，不能随便宕机了，下发ip的时候，要进行负载均衡，因为provider / consumer与注册中心建立的都是长连接，这个负载均衡就尤为重要，所以这个HTTP服务要根据注册中心集群的CPU，内存等指标下发一些负载小的注册中心ip供连接使用。还有一个非常重要的点，就是下发的ip列表要打乱，为什么呢？如果所有的provider都获取的是同顺序的ip列表，都同时与第一个建立长连接，第一台注册中心节点必然压力山大，因此打乱也是一个细节。

• 集群中的数据如何快速实现同步 — 基于事件总线（或者将这些更新操作，写到一个公共的地方，然后，每个注册中心节点去消费）

• 增量推送 （依赖RPC的callBack机制）

2、健康检测

provider端是集群部署的，每次调用前都通过负载均衡算法选出一个来进行调用，为了保证成功率，选出来的这个节点必须是可用的。

2.1 单纯的依赖注册中心

因为节点下线后，注册中心会动态通知consumer，表明这个节点已经下线了，这个下线其实是指的和注册中心之间的连接。假设这么一种情况，provider和注册中心的连接没有问题，也就是对注册中心而言这个provider还是存活的，但是与consumer的连接断开了，这样consumer其实是发送不了数据的。如果单纯的依赖注册中心的话，则认为这个节点还是存活的，会造成业务受损。因此需要引入健康检测机制。

2.2 实现

consumer定期向所有的provider发送心跳数据，provider收到心跳报文后，向consumer回应，代表这个provider是存活的，如果在固定时间且超过一定次数都没有回应心跳信息，则代表这个provider可能有问题了，因此将这个provider从可用列表中删除，转移到非健康列表中，然后可用定期重试，等到心跳又可以通了，再转移到可用列表中。这样便完成了健康检测逻辑。当然心跳正常也不能完全保证节点正常，最健康的应该是业务无损，因此需要定期收集分析业务处理的性能，进行综合判断。

3、节点的负载均衡

RPC的负责均衡与传统的web服务的负载均衡有些区别，虽然都是负载均衡，但是RPC的负载均衡应该更加灵活，可配置，因为不同的服务不同服务的方法的负载均衡可能是不一样的。因此RPC框架的负载均衡完全由程序自身实现。常见的负载均衡算法有 权重轮询，权重随机，一致性hash，最少活跃数等。

这种负载均衡算法实现比较简单，也基本满足业务需求了，另外为了提高扩展性，可以使用SPI的方式将该接口暴露出去，供用户扩展。
但是在一些业务场景中，如某台权重大的机器发生了FullGC，这样如果不能及时更改权重，则会造成业务受损，因此需要程序可以动态的感知下游机器处理能力，进而调整其权重，所以需要引入一个自适应的负载均衡机制。根据下游机器的CPU，内存，负载，动态调整权重。类似Rocketmq中的故障规避策略，那个是一个非常简单的实现，根据发送数据的耗时时间，推断broker可用时间。