分布式技术原理与算法解析01-注册中心原理

注册中心原理

• 服务提供者注册流程
• 服务提供者反注册流程
• 服务消费者查询流程
• 服务消费者订阅变更流程
  
• 第一步检查节点列表是否存在
• 第二步查看注册的Cluster（服务的接口名）是否存在？不存在抛出异常
• 第三步查看分组是否存在？不存在抛出异常

节点反注册

• 第一步查看服务的分组是否存在不存在抛出异常
• 第二步查看服务名称是否存在不存在抛出异常
• 第三步查看节点是否存在，存在删除节点，不存在抛出异常
• 第四步更新接口的Sign

查询节点信息

服务消费者查看节点信息

• 第一步从local cache 本地缓存中查找 （服务消费者把服务信息存在本机内存）主要是因为服务节点信息并不是总是时刻变化的，并不需要每一次服务都要调服务注册中心获取最新的节点信息，只需要本机保存最新的服务提供者的节点列表

• 第二步snapshot（本地快照）中查找，（为什么服务消费者要在本地磁盘存储一份服务提供者的节点列表信息）

• 主要是因为服务消费者和注册中心之间的联系不一定可靠，服务消费者重启时，本机内存还不存在服务提供者的节点信息，如果此时调用注册中心失败，那么服务消费者就拿不到服务节点的信息，也就没有办法调用了，本地快照就是为了防止这样的情况发生，即使服务消费者重启后请求注册注册中心
  失败，依然可以读取本地快照，获取节点服务信息。

订阅服务变更

• 服务消费者从注册中心获取服务信息之后，就订阅了服务的变化，会在本地保留Cluster的sign值。
  服务消费者每隔一段时间调用getSign()函数，从注册中心获取服务端该Cluster的sign值，并与本地保留的sign值作对比如果不一致就从服务端拉取新的节点信息，并更新localcache和snapshot

多注册中心

• 理论上对于一个服务消费者来说，同一个注册中心交互最简单，但是一定会存在于服务消费者同时订阅了多个服务，多个服务可能是由多个部门提供的，而且不同部门都有自己的注册中心，提供的服务只在自己的注册中心里面有记录，这样的话就要求多个注册中心订阅服务的能力。

• 对于服务消费者来说，要能够同时从多个注册中心订阅服务；对于服务提供者来说，要同时向多个注册中心注册服务。

并行订阅服务

• 每订阅一个服务就单独用一个线程来处理，这样即使遇到个别服务节点连接超时，其他服务节点也不会受影响，最慢的这个服务就是节点初始化连接所耗费的时间。

批量反注册服务

• 通常一个服务提供者节点服务提供不止一个服务，所以注册和反注册都需要多次调用注册中心，在与注册中心的多次交互中可能由于网络的抖动，注册中心集群异常等原因导致个别调用失败，对于注册中心来说，偶发的注册调用失败对服务调用基本没有影响，其结果顶多就是某一个服务少了一个可用的节点，但偶发的发注册调用失败会导致不可用的节点残留在注册中心，变成僵尸节点。

• 通过优化反注册逻辑，对于下线机器，节点销毁的场景，通过调用注册中心的反注册接口，一次调用就可以把该节点上提供的所有服务反注册掉，从而避免了“僵尸节点‘的出现

服务变更信息增量更新

• 服务消费者端启动时，除了会查询订阅服务的可用节点列列表做初始化连接还会订阅服务的变更，每隔一段时间从注册中心虎丘最新的服务节点信息标记sign,并与本地保持的sign值作对比，如果不一样则调用注册中心获取最新的服务节点信息。

• 一般情况下按照这个过程是没有问题的，但是在网络频繁抖动的时候，服务提供者上报给注册中心的心跳可能会一会失败一会成功，这时候注册中心就会频繁更新服务的可用节点信息，导致服务消费者从注册中心拉取最新的服务可用节点信息，严重时可能产生网络风暴，导致注册中心的带宽被拉满
  为了减少服务消费者从注册中心拉去的屈服可用节点信息的数据量，这个时候可以通过增量更新的方式，注册中心只返回变化的那部分节点信息，尤其在只有少数节点信息变更的时。