服务注册与发现上

Posted 2021-05-01 点融黑帮

导读

随着业务的发展，用户量日益上升，单一的系统越来越复杂，越来越庞大，单纯的提升服务器性能始终有顶天的一天，我们可以通过分布式技术，例如：服务器集群，水平业务划分，应用分解，系统分流，微服务架构等方式来解决系统性能问题和复杂业务问题。 

第一篇：架构演进

在分布式体系下服务注册与发现将会以核心组件而存在，也将是接下来讨论的话题。

Lazy服务注册与发现(一）

由于应用的分解，微服务的引入，服务越来越多，业务系统与服务系统之间的调用，都需要有效管理。 

在服务化的早期，服务不是很多，服务的注册与发现并不是什么新鲜的名词，nginx+内部域名服务器方式，甚至Nginx+host文件配置方式也能完成服务的注册与发现。

架构图如下：

（架构一）

各组件角色如下： 

1. Nginx通过多域名配置实现生产者服务路由，通过upstream对生产者提供负载均衡，通过checkhealth对生产者提供健康检查。 

   
   

2. 在内部域名服务器/本地host文件配置服务域名的方式，实现域名与服务的绑定。 

   
   

3. 生产者提供服务给消费者访问，并通过Nginx来进行请求分发。在服务化的早期，服务较少，访问量较小，解决了服务的注册与发现与负载均衡等问题。随着业务的发展，用户量日益上升，服务也越来越多，该架构的问题暴露出来：

   1）最明显的问题是所有的请求都需要nginx来转发，同时随着访问量的提升，会成为一个性能瓶颈。

   2）随着内部服务的越来越多，服务上线nginx的配置，内部域名的配置也越来越多，不利于快速部署。

   3）一旦内部网络调整，nginx upstream也需要做对应的配置调整。 

Lazy服务注册与发现（二）

由于所有的请求都需要nginx来转发，同时随着访问量的提升，会成为一个性能瓶颈，为了解决这个瓶颈，引入下面这个架构。 

（架构二）

1. 这个架构在nginx的上层加入了LVS，LVS基于第四层的IP转发，一定限度提高了并发能力,但是所有请求都通过LVS来转发。 

   
   

2. 同时nginx分组，服务分组，虽然nginx不再是瓶颈的所在，但是这样带来的代价太高，配置越来越多，工作量越来越大，对系统压力需要有预见性，有效nginx分组，服务分组部署。 

Lazy服务注册与发现（三）

由于所有的请求都需要LVS来转发，同时随着访问量的提升，会成为一个性能瓶颈，为了解决这个瓶颈，引入下面这个架构。 

（架构三）

在这个架构基础上需要做两件事情：

1. 对系统压力需要有预见性，有效nginx分组，服务分组部署。 

2. 消费端需要编程实现分组选择，可以是轮训，random等实现，我们每一个消费者同时承担了的负载均衡的职责。 

ZK服务注册与发现 （一）

通过架构三解决了nginx的瓶紧，但是服务上下线需要在nginx，域名服务器做相应的配置，一旦服务的IP端口发生变化，都需要在nginx上做相应的配置，为了解决这个问题引入下面这个架构。 

（架构四）

1. 服务在启动的时候就将endpoint注册到Zookeeper对服务进行统一管理。 

2. 服务节点增加Endpoint不需要做任何配置，ZK将以Watch机制通知消费者。 
   

3. 消费者本地缓存了提供者服务列表，不需要转发，直接发起服务调用。

 

缺点： 

需要通过zookeeper API来实现服务注册与发现，负载均衡，以及容错，为了解决nginx的瓶紧架构三也是需要通过编程的方式实现负载均衡。

ZK服务注册与发现 （二）

Zookeeper数据模型结构是一个树状层次结构。每个节点叫做Znode，节点可以拥有子节点，同时允许将少量数据存储在该节点下，客户端可以通过NodeCacheListener监听节点的数据变更，PathChildrenCacheListener监听子节点变更来实时获取Znode的变更(Wather机制)。 

以下是点融成都服务注册结构，见下图，接下来的讲解也将以这个结构为基础：

ZK服务注册与发现 （三）

1./com/dianrong/cfg/1.0.0/rpcservice: 命名空间，用来跟其他用途区分。 

2./com/dianrong/cfg/1.0.0/rpcservice下的所有子目录由两部分组成， 

“应用名称” + “-” +  “分组名称”例如：ProductService-SG1,ProductService-SG2, 对应Nginx注册中心Nginx-SG1, Nginx-SG2

3. 服务分组下的所有子节点为临时节点，key为“PROVIDER”+ IP(去符号.)  + “-” + 端口,Value为endpoint信息。 

例如：PROVIDER1921681010-8080   = http://192.168.10.10：8080

第二篇：代码分析

项目说明

有了上面的理论我们接下来针对基于ZK的服务与发现的代码分析，代码已经提交到git 

https://code.dianrong.com/projects/PLAT/repos/platform/compare/commits?sourceBranch=refs%2Fheads%2FEVER-81-zk&targetBranch=refs%2Fheads%2Fmaster

说明:

1. 该组件建立在Curator基础之上，Curator是Netflix开源的一套ZooKeeper客户端框架封装ZooKeeper client与ZooKeeper server之间的连接处理。 

2. Curator提供如下机制，保证我们不需要关注网络通信，而把主要精力放在业务逻辑的处理。 

• 重试机制:提供可插拔的重试机制, 它将给捕获所有可恢复的异常配置一个重试策略, 并且内部也提供了几种标准的重试策略

• 连接状态监控: Curator初始化之后会一直的对zk连接进行监听, 一旦发现连接状态发生变化, 将作出相应的处理

• ZK客户端实例管理:Curator对zk客户端到server集群连接进行管理. 并在需要的情况, 透明重建zk实例, 保证与zk集群的可靠连接  

基于ZK的服务与发现UML类图： 

（点击查看大图）

目标

1. 统一配置中心

数据实时性，一旦zk节点发生变化，实时通知本地hash同步刷新。 

2. 服务注册

服务启动完成，服务IP,端口以临时节点的形式注册到zk，在网络正常的情况下，一直存在。 

3. 服务发现 

服务启动完成，将服务注册信息刷新到本地hash。

4. 服务上下线 

服务注册到zk将实时通知服务发现方，更新本地hash，服务下线也将实时通知服务发现方，更新本地hash。

5. 负载均衡 

服务发现方获取服务缓存在本地hash,通过random，robin等负载均衡算法完成服务选择性调用。

6. 网络中断容灾 

针对注册方网络中断，服务下线，网络恢复，服务上线，并通知服务发现方更新本地Hash； 

针对发现方网络中断，通过本地hash负载均衡，网络恢复重刷hash，负载均衡重新分配。 

7. Zookeeper宕机容灾 

针对注册方Zookeeper宕机，服务下线，尝试重连， Zookeeper 启动重连成功，服务上线，并通知服务发现方更新本地hash，针对发现方Zookeeper宕机，通过本地hash负载均衡，尝试重连，  Zookeeper 启动重连成功，重刷hash，负载均衡重新分配。

基本配置

PathConfig.java

包含服务注册的命名空间和统一配置的命名空间的配置。 

SgConfig.java

包含服务名和分组名的配置 

ZookeeperConfig.java

ZK操作框架

IzookeeperManager.java 

定义了一套zookeeper操作规范（类似JDBC操作数据数据库规范），有待继续完善。 

ZookeeperManager.java

针对IzookeeperManager接口规范的实现（类似mysql驱动对Mysql操作的实现） 

ZookeeperManagerPool.java

针对ZookeeperManager实例的缓存，不同配置缓存不同ZookeeperManager实例，避免zookeeper连接创建的开销，同时可以根据zookeeper水平分组扩展zookeeper

实例。 

统一配置，服务注册与发现

AbstractZookeeperFeature.java

内部两个接口定义： 

IConfigService 提供针对统一配置接口的定义， IManagementService提供服务注册与发现接口的定义。 

ConfigService.java 

统一配置的实现。 

ManagementService.java

服务注册与发现的实现。 

负载均衡

LbStrategy.java

负载均衡策略接口定义，目前实现了两种负载均衡算法，Random负载均衡和Robin负载均衡。

RandomStrategy.java

基于随机负载均衡的实现。

RobinStrategy.java

基于轮循负载均衡的实现。 

统一配置Listener

ConfigPathChildrenCacheListener.java

统一配置结点监听， 针对CHILD_REMOVED，CHILD_ADDED，CHILD_UPDATED事件对本地hash实时更新。 

服务注册与发现Listener 

ZookeeperStateListener.java

Zookeeper状态监听接口定义，定义需要关心的三种事件： 

LOST-断开连接达到一定时间 

CONNECTED-第一次连接成功 

RECONNECTED-重连成功触发事件。

ServiceRegistStateListener.java

服务注册状态监听实现:

1.一旦网络丢包严重/ zk宕机/ zk重启,客户端将会与zk断开，服务下线，网络恢复将触发reconnected连接，服务重新注册。 

2.一旦zk断开服务下线，长时间连接不上触发Lost事件，ServiceRegistStateListener将会尝试不断连接直到连上为止，服务重新注册。

ServiceDiscoverStateListener.java

服务发现状态监听实现： 

1.一旦网络丢包严重/ zk宕机/ zk重启,客户端将会与zk断开，网络恢复将触发reconnected连接，重新获取服务列表，刷新本地hash。

2.一旦zk断开服务下线，长时间连接不上触发Lost事件，ServiceDiscoverStateListener将会尝试不断连接直到连上为止,以便刷新本地hash。

ServicePathChildrenCacheListener.java

服务发现结点监听， 针对CHILD_REMOVED，CHILD_ADDED，CHILD_UPDATED事件消费者对本地hash实时更新，以便及时刷新服务上下线。 

未

完

待

续

---

---