CN110233886A - 一种面向海量微服务的高可用服务治理系统及实现方法 - Google Patents

Abstract

本发明公开了一种面向海量微服务的高可用服务治理系统及实现方法，该系统包括服务端，客户端和地址管理端，该方法的步骤包括：服务提供者进行服务注册；服务端进行服务同步；服务提供者进行服务续租与过期；服务调用者进行服务调用；服务端地址发生变动时，在客户端和服务端中进行服务端地址同步。本发明确保了海量微服务场景下，服务注册中心的高可用性，使用一致性哈希算法确定客户端与服务端的对应关系，从而在服务端数量变动时，尽量少影响已存在的对应关系；服务提供者与服务端维持固定的心跳包，及时进行服务续租与过期；将分布式一致性协议应用到地址管理端，确保服务端地址列表的一致性。

Description

一种面向海量微服务的高可用服务治理系统及实现方法

技术领域

本发明涉及云计算技术领域，特别涉及一种面向海量微服务的高可用服务治理系统及实现方法。

背景技术

随着互联网的普及，现代互联网系统的架构变得越来越复杂。对于一个大型的互联网系统，一般会包含多个应用，而且应用之间往往还存在共同的业务，并且应用之间还存在调用关系。因此，为了使复杂的系统更容易拓展和维护，通常会采用微服务架构，也就是把业务和应用分离，某个业务不再属于一个应用，而是作为一个独立的服务单独进行维护。大型的互联网系统必然是由海量的微服务组成的，而且这些服务本身就是进行分布式部署的。因此某些服务的上线下线或者服务地址变化都时有发生。所以需要一个高可用的服务治理方法来管理这海量的微服务的地址。具体而言，服务注册中心需要具备高可用性，也就是在海量微服务地址变化或者应用海量服务消费者调用各个微服务时都确保能提供服务。

然而现在主流的服务注册中心都采用zab协议或者raft协议。这两种协议均是分布式一致性协议，目的是在分布式的环境下各节点达成一致。根据著名的CAP原则，分布式场景下系统只能确保Consistency(一致性)、Availability(可用性)和Partitiontolerance(分区容错性)中的两种，三者不可兼得。服务治理场景中，分区容错性是必然需要满足的，而采用zab或者raft便是选择了一致性，从而放弃了可用性。具体表现就是zab和raft都需要一个主节点，而这个主节点需要选举产生。选举过程中整个系统都是不可用的，从而影响了整个系统的可用性。

发明内容

为了克服现有技术存在的缺点与不足，本发明提供一种面向海量微服务的高可用服务治理系统及实现方法，对服务端进行分布式部署，各节点平等，不存在主节点，客户端可访问任意一个服务端，从而实现服务注册中心的高可用性，并且通过独立的地址管理端可以很轻易地增加服务注册中心的服务端数量，从而提高服务注册中心的并发量。

为了达到上述目的，本发明采用以下技术方案：

本发明提供一种面向海量微服务的高可用服务治理系统，包括：服务端、客户端和地址管理端；

所述服务端用于存储微服务的地址与端口；

所述客户端用于从服务端获取特定的微服务地址与端口，以及将微服务地址与端口注册到服务端；

所述地址管理端用于存储管理服务端的可用地址；

所述服务端和所述客户端定期将地址管理端存储的服务端地址同步到本地。

作为优选的技术方案，还包括服务端部署模块，所述服务端部署模块用于将服务端进行分布式部署，分布在各个平等的节点。

本发明还提供一种面向海量微服务的高可用服务治理系统实现方法，包括下述步骤：

服务注册：应用提供服务时，通过客户端将服务名称、服务地址和端口信息注册到一个选定的服务端，服务端将注册信息进行存储后转发到所有服务端，并返回注册成功信息；

服务调用：应用调用服务时，通过客户端从选定的服务端中获取服务的地址和端口信息；

服务续租：服务注册成功后，服务提供者通过客户端向服务端发送定期的心跳包，心跳包停止发送超过设定的次数后，服务端判定服务提供者停止提供服务，移除服务提供者的地址与端口；

服务端地址同步：客户端和服务端均发送请求到地址管理端，请求获取所有的服务端地址，服务端地址返回后，客户端和服务端将返回的服务端地址形成列表缓存在本地，服务端地址先从本地获取；

服务同步：服务端中存储微服务的地址和端口，通过服务注册和服务续租进行服务同步，服务注册时，服务端会将当前服务注册的请求转发给所有服务端，所有服务端进行服务注册；服务续租时，服务端将续租请求转发到所有服务端进行服务续租，若服务续租时本地没有服务注册信息，则进行服务注册；

服务端数量变动：服务端数量根据微服务数量进行变动调节，在地址管理端中修改，并进行服务端地址同步，将服务端和客户端的服务端地址缓存进行更新。

作为优选的技术方案，还包括对服务端进行异地多机房部署步骤，将服务端部署在不同地理位置的机房中，同时对客户端提供服务，通过地址管理端配置服务端地址，客户端可访问任意一个服务端。

作为优选的技术方案，所述服务调用的步骤中，客户端采用一致性哈希算法进行服务端的选择，具体步骤为：将本地IP地址进行HASH操作后，映射到由服务端地址进行HASH操作后的数值圆环上，选择HASH值在数值圆环上沿顺时针方向遇到的第一个服务端。

作为优选的技术方案，所述服务端地址同步的步骤中，具体步骤为：地址管理端将服务端地址存储到分布式部署的ZooKeeper中，ZooKeeper各节点会根据Zab协议进行选举，产生一个主节点，当存储的服务端地址发生改变时，将通过主节点向所有ZooKeeper节点进行确认，一半以上的ZooKeeper节点确认后再执行服务端地址修改。

作为优选的技术方案，所述服务端地址同步的步骤中，服务端的地址列表发生改变时，地址管理端通知服务端和客户端，服务端和客户端定期将地址管理端的服务端地址同步到本地。

本发明与现有技术相比，具有如下优点和有益效果：

(1)本发明对服务端采用了异地多机房部署的方案，各节点平等，不存在主节点，客户端可访问任意一个服务端，解决了主流服务注册中心一半以上节点不可用时整个系统不可用的技术问题，达到了服务注册中心高可用的技术效果。

(2)本发明通过独立的地址管理端可以简易进行服务端的扩充与减少，解决了主流服务注册中心扩充服务端繁琐的技术问题，达到了当微服务随业务发展而增加或者某个服务端宕机时，可以通过地址管理端轻易修改服务端的技术效果。

(3)本发明的服务端保存有各个服务的地址与端口，并且通过异地多机房部署确保高可用性，客户端通过服务端获取服务的地址与端口，地址管理端负责管理服务端的所有地址。地址管理端通过ZooKeeper确保分布式场景下服务端地址存储的一致性。

(4)服务端和客户端会定期将地址管理端的服务端地址同步到本地，从而确保服务地址最终一致。

(5)本发明考虑了服务端数量变动时的负载均衡，采用了一致性哈希的技术方案，从而达到了在服务端数量变动时让大部分客户端对于服务端的选择保持不变的技术效果。

附图说明

图1为本实施例面向海量微服务的高可用服务治理系统实现方法的流程图；

图2为本实施例服务注册和服务同步的流程图；

图3为本实施例服务调用的流程图；

图4为本实施例服务续租与过期的流程图；

图5为本实施例服务端地址同步的流程图。

具体实施方式

为了使本发明的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不用于限定本发明。

实施例

在本实施例中，提供一种面向海量微服务的高可用服务治理系统，包括：服务端、客户端和地址管理端；

在本实施例中，所述服务端用于存储微服务的地址与端口，也就是当一个微服务需要向外提供服务时，会先将自身的服务地址和端口注册到服务端中；所述客户端用于从服务端获取特定的微服务地址与端口，以及将选定的微服务地址与端口注册到服务端；所述地址管理端用于存储管理服务端的所有可用地址；所述服务端和所述客户端定期将地址管理端存储的服务端地址同步到本地。

在本实施例中，采用Java语言设计客户端和服务端，客户端和服务端之间的访问采用Netty，地址管理端采用ZooKeeper进行管理，因为ZooKeeper本身就满足分布式一致性。

如图1所示，本实施例还提供一种面向海量微服务的高可用服务治理系统的实现方法，包括下述步骤：

以下所述的服务地址为微服务对外提供服务的地址，服务端地址为本实施例面向海量微服务的高可用服务治理系统服务端的地址；

部署服务端及地址管理端，并将服务端地址配入地址管理端中。本实施例对服务端进行分布式部署，将服务端部署至地理位置不同的机房中，各节点平等，不存在主节点，同时对客户端提供服务，通过地址管理端配置服务端地址，客户端可访问任意一个服务端，从而实现服务注册中心的高可用性，并且通过独立的地址管理端可以很轻易地增加服务注册中心的节点，从而提高服务注册中心的并发量；

服务注册：某个应用需要向外提供服务时，它需要将服务名称、本地地址和端口注册到服务端。它会通过客户端将这些信息注册到某个服务端，然后该服务端会将该信息转发至所有服务端。此时服务端的选择是根据一致性哈希算法得到的，即将本地IP地址HASH后映射到由服务端地址HASH后的[0，2^32)的圆环上，并选择顺时针遇到的第一个服务端。首先，对服务端IP进行HASH操作，结果范围为[0,2^32)，并将其映射到0-2^32的圆环上。然后，采用相同的HASH方法求出本机IP的HASH值，并将其映射到同一个圆环上。最后，选择本机的HASH值在圆环上顺时针遇到的第一个服务端。目的是在服务端数量变动时尽量不影响客户端已经选择的服务端；

服务调用：某个应用需要调用某项服务时，它需要该服务的服务地址和端口。它会通过客户端根据服务名称从任意一个服务端中获取该项服务的服务地址和端口；

服务过期与续租：服务提供者需要与服务端维持定期的心跳，也就是服务续租。一旦心跳包停止发送超过一定次数后，服务端就会认为该服务提供者停止提供该服务，从而从该服务中移除该服务提供者的地址与端口，也就是该服务过期了；

服务端地址同步：当服务端的地址列表发生改变时，地址管理端会通知服务端和客户端。此外，客户端和服务端都会定期从地址管理端中同步服务端的地址，从而确保服务端地址最终一致。每次客户端需要获取服务端列表，以及服务端需要同步微服务信息时都是首先从本地获取所有服务端的地址，从而确保服务注册中心的高可用性；本实施例中，地址管理端通过ZooKeeper确保服务端地址信息的一致性，即将服务端地址存储到分布式部署的ZooKeeper中。当服务端的地址列表发生改变时，地址管理端会通知服务端和客户端。

本实施例的服务端地址同步具体步骤为：地址管理端将服务端地址存储到分布式部署的ZooKeeper中，ZooKeeper各节点会根据Zab协议进行选举，产生一个主节点，之后每当存储的服务端地址发生改变时都将通过主节点向所有ZooKeeper节点进行确认，当一半以上的ZooKeeper节点确认后服务端地址修改才能执行，从而保证了分布式场景下服务端地址表的一致性。

服务同步：为了确保服务注册中心的高可用性，需要在分布式部署的服务端中都存储微服务的服务地址和端口。而服务端之间的服务同步就是通过服务注册与续租来实现的。服务注册时，服务端会将本次服务注册的请求转发给所有服务端，所有服务端都会进行此次服务注册。即便某些服务端的服务注册失败也没有关系，因为服务提供者会与某个服务端维持一个心跳连接，也就是每次服务续租时，该服务端也会转发至所有服务端进行续租，而续租时若是本地没有该注册信息，则会进行注册。

服务端数量变动：当微服务数量大增时，可能会对服务端造成压力，此时需要增加服务端数量。当某个服务端出现问题时，也许要减去该服务端。也就是服务端数量可能会时常变动，当服务端数量变动时，只需要在地址管理端中进行修改即可。在服务端地址同步后，服务端和客户端的服务端地址就会更新。

如图2所示，在服务提供者进行服务注册的时候，服务注册中心进行服务注册和服务同步，其中①和②表示服务提供者会通过客户端将其提供的服务名称，服务地址和端口存储到服务端中。其中，客户端会根据上述的一致性哈希算法选择到其中一个服务端，并且以后均与该服务端进行交互，除非该服务端不再提供服务。采用一致性哈希算法进行选择，以确保在服务端数量发生变动时，尽量不影响已经选取服务端的客户端。

如图2所示，③表示服务端收到客户端发到的注册信息时，会将其信息进行存储，并将该注册信息转发到所有服务端。服务端只对服务注册请求进行转发，而不管其他服务端是否成功存储该服务。只要自身存储成功，便返回注册成功；④表示客户端收到服务端的返回后，会将注册结果返回给服务提供者；⑤表示服务成功注册后，服务提供者会通过客户端与选定的服务端维持固定的心跳包传输，以确保服务依旧正常提供。

如图3所示，服务注册之后，服务调用端进行服务调用，①和②表示服务调用者通过客户端从服务端中根据服务名称获得服务地址和端口；③和④表示服务端根据服务名称返回服务提供者的服务地址和端口给服务调用者；⑤表示服务调用者根据服务地址和端口可以直接跟服务提供者进行交互。

如图4所示，在服务注册之后，进行服务续租，一项服务注册之后，由于各种原因可能出现不再提供服务或者服务地址或端口变化的情况，对于这种情况，服务端需要及时更新信息。实现如下：

其中①表示服务注册后，服务提供者定时发送心跳包给其选定的服务端。心跳包的内容其实就是对本服务进行续租，也就是再注册；

其中②表示服务端收到服务续租后，会将续租请求同步到所有的服务端，若有服务端之前并未注册该服务，也会进行注册。

如图5所示，在服务端数量或地址发生变动时，服务端和客户端进行服务端地址列表同步的步骤，

其中①表示在服务注册中心初始化时，客户端和服务端都会发送请求到地址管理端，要求获取所有的服务端地址；

其中②表示地址管理端收到客户端和服务端请求后，会将自己存有的服务端地址返回。服务端和客户端会将收到的服务端地址列表缓存到本地，之后需要用到服务端地址列表时都会先从本地获取；

其中③表示服务端地址发生变化时(新增或减少服务端)，地址管理端会马上通知服务端和客户端；

其中④和⑤表示服务端和客户端都会定期向地址管理端发送请求，获取并更新自身的服务端地址列表。

上述实施例为本发明较佳的实施方式，但本发明的实施方式并不受上述实施例的限制，其他的任何未背离本发明的精神实质与原理下所作的改变、修饰、替代、组合、简化，均应为等效的置换方式，都包含在本发明的保护范围之内。

Claims (7)

1.一种面向海量微服务的高可用服务治理系统，其特征在于，包括：服务端、客户端和地址管理端；

所述服务端用于存储微服务的地址与端口；

所述客户端用于从服务端获取特定的微服务地址与端口，以及将微服务地址与端口注册到服务端；

所述地址管理端用于存储管理服务端的可用地址；

所述服务端和所述客户端定期将地址管理端存储的服务端地址同步到本地。

2.根据权利要求1所述的面向海量微服务的高可用服务治理系统，其特征在于，还包括服务端部署模块，所述服务端部署模块用于将服务端进行分布式部署，分布在各个平等的节点。

3.一种面向海量微服务的高可用服务治理系统实现方法，其特征在于，包括下述步骤：

服务注册：应用提供服务时，通过客户端将服务名称、服务地址和端口信息注册到一个选定的服务端，服务端将注册信息进行存储后转发到所有服务端，并返回注册成功信息；

服务调用：应用调用服务时，通过客户端从选定的服务端中获取服务的地址和端口信息；

服务续租：服务注册成功后，服务提供者通过客户端向服务端发送定期的心跳包，心跳包停止发送超过设定的次数后，服务端判定服务提供者停止提供服务，移除服务提供者的地址与端口；

服务端地址同步：客户端和服务端均发送请求到地址管理端，请求获取所有的服务端地址，服务端地址返回后，客户端和服务端将返回的服务端地址形成列表缓存在本地，服务端地址先从本地获取；

服务同步：服务端中存储微服务的地址和端口，通过服务注册和服务续租进行服务同步，服务注册时，服务端会将当前服务注册的请求转发给所有服务端，所有服务端进行服务注册；服务续租时，服务端将续租请求转发到所有服务端进行服务续租，若服务续租时本地没有服务注册信息，则进行服务注册；

服务端数量变动：服务端数量根据微服务数量进行变动调节，在地址管理端中修改，并进行服务端地址同步，将服务端和客户端的服务端地址缓存进行更新。

4.根据权利要求3所述的一种面向海量微服务的高可用服务治理系统实现方法，其特征在于，还包括对服务端进行异地多机房部署步骤，将服务端部署在不同地理位置的机房中，同时对客户端提供服务，通过地址管理端配置服务端地址，客户端可访问任意一个服务端。

5.根据权利要求3所述的一种面向海量微服务的高可用服务治理系统实现方法，其特征在于，所述服务调用的步骤中，客户端采用一致性哈希算法进行服务端的选择，具体步骤为：将本地IP地址进行HASH操作后，映射到由服务端地址进行HASH操作后的数值圆环上，选择HASH值在数值圆环上沿顺时针方向遇到的第一个服务端。

6.根据权利要求3所述的一种面向海量微服务的高可用服务治理系统实现方法，其特征在于，所述服务端地址同步的步骤中，具体步骤为：地址管理端将服务端地址存储到分布式部署的ZooKeeper中，ZooKeeper各节点会根据Zab协议进行选举，产生一个主节点，当存储的服务端地址发生改变时，将通过主节点向所有ZooKeeper节点进行确认，一半以上的ZooKeeper节点确认后再执行服务端地址修改。

7.根据权利要求3或6所述的一种面向海量微服务的高可用服务治理系统实现方法，其特征在于，所述服务端地址同步的步骤中，服务端的地址列表发生改变时，地址管理端通知服务端和客户端，服务端和客户端定期将地址管理端的服务端地址同步到本地。