服务平滑升级的方法及装置与流程

本发明涉及服务升级技术领域，具体涉及一种服务平滑升级的方法及装置。

背景技术：

服务发现(Service Discovery)组件记录了大规模分布式系统中所有服务的信息，人们或者其它服务可以据此找到这些服务。DNS就是一个简单的例子。当然，复杂系统的服务发现组件要提供更多的功能，例如，服务元数据存储、健康监控、多种查询和实时更新等。服务发现提供了一种协调机制，方便服务的发布和查找。服务发现的主要好处是零配置：不用使用硬编码的网络地址，只需服务的名字就能使用服务。

业界提供了很多种服务发现解决方案：

人们已经使用DNS很长时间了，DNS可能是现有的最大的服务发现系统。小规模系统可以先使用DNS作为服务发现手段。一旦服务节点的启动和销毁变得更加动态，DNS就有问题了，因为DNS记录传播的速度可能跟不上服务节点变化的速度。

ZooKeeper大概是最成熟的配置存储方案，它的历史比较长，提供了包括配置管理、领导人选举和分布式锁在内的完整解决方案。因此，ZooKeeper是非常有竞争力的通用的服务发现解决方案，当然，它也显得过于复杂。

Etcd和doozerd是新近出现的服务发现解决方案，它们与ZooKeeper具有相似的架构和功能，因此可与ZooKeeper互换使用。

图1是现有技术的一种服务发现原理示意图，如图1所示，在服务启动的时候将其服务的IP和端口注册到一个分布式存储集群etcd(一个开源的、高可用的键值存储系统/键值存储仓库，主要用于共享配置和服务发现，etcd是专门为集群环境的服务发现和注册而设计，它提供了数据改变监视、目录监听、分布式锁原子操作等功能，可以方便地跟踪并管理集群节点的状态)中，有另外一个监听服务变化的模块负责实时监听代理服务列表的变化，如果发生变化则会更新代理服务的列表，当其中一个服务停止服务时，会从etcd存储中删除掉，监听服务也会对应地更新代理服务列表。Nginx是一个代理服务中间件。

图2是现有技术的服务停止时摘除该服务的示意图，如图2所示，当节点服务节点1停止服务时，将从etcd中删除描述信息，监听服务立即会从代理服务上将节点1的服务摘除掉。

在实现本发明过程中，发明人发现现有技术中至少存在如下问题：

现有的技术实现原理如上面介绍的可以实现服务的注册发现，并且当某个服务停止服务时也可以实时地将其摘除掉，在大部分情况下是没有问题的，但是如果要升级某个服务或者灰度测试某个服务时，服务节点会频繁变更，一般都是先将新服务节点启动，然后将旧的服务节点关闭掉，这样对于服务发现内部会发生两次服务列表变更，意味着代理服务将需要有2次变更配置，代理服务在进行配置变更时会发生服务抖动的情况。

技术实现要素：

本发明实施例提供一种服务平滑升级的方法及装置，以克服代理服务在进行配置变更时会发生服务抖动的情况。

一方面，本发明实施例提供了一种服务平滑升级的方法，其包括：

将多个新版服务节点注册到第一服务组，并将所述第一服务组注册到服务发现应用程序中；

从所述服务发现应用程序中对待下线的包括多个旧版服务节点的第二服务组执行模拟下线，并将新的请求事务全部连接到所述多个新版服务节点上，使所述多个旧版服务节点停止接收新的请求事务，仅处理在模拟下线之前接收到的待处理的请求事务；

当所述第二服务组中的旧版服务节点将待处理的请求事务处理完成后，将所述旧版服务节点停止服务。

另一方面，本发明实施例提供了一种服务平滑升级的装置，其包括：

服务组管理模块，用于将多个新版服务节点注册到第一服务组，并将所述第一服务组注册到服务发现应用程序中；

模拟下线管理模块，用于从所述服务发现应用程序中对待下线的包括多个旧版服务节点的第二服务组执行模拟下线，并将新的请求事务全部连接到所述多个新版服务节点上，使所述多个旧版服务节点停止接收新的请求事务，仅处理在模拟下线之前接收到的待处理的请求事务；

监听服务模块，用于当所述第二服务组中的旧版服务节点将待处理的请求事务处理完成后，将所述旧版服务节点停止服务。

上述技术方案具有如下有益效果：

本发明采用分组的方式划分服务节点，在升级时直接将所有要对外服务的节点注册到新分配的组，并注册到服务发现中，然后从服务发现中批量模拟下线掉要下线的服务组，使其不再接收新的请求事务，当这些旧的服务将要处理的事务请求都处理完成后才真正彻底地停止服务。这样可以确保在升级的过程中没有未完成的请求事务，尽可能地避免服务的抖动，降低了服务在升级中因多个节点频繁变更导致的服务频繁抖动的情况，实现了平滑升级，有利于管理服务升级版本迭代。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是现有技术的服务发现原理示意图；

图2是现有技术的服务停止时摘除该服务的示意图；

图3是本发明的实施例的服务平滑升级的示意图；

图4是本发明的实施例的服务平滑升级装置及其原理示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

为了避免升级多个节点频繁变更导致服务抖动，在本发明的实施例中采用分组的方式划分服务节点，如果是升级或者灰度测试时直接将所有要对外服务的节点注册到新分配的组中，并注册到服务发现应用程序中，然后从服务发现应用程序中批量模拟下线掉要下线的服务组。注意其实此时还没有真正的下线掉服务，只是通过模拟下线的方式将旧版本的服务列表从代理服务列表中摘除导致其从代理服务器上下线掉，不再接收新的请求事务。当这些旧的服务将要处理的事务请求都处理完成后可以真正的停止服务。这样可以确保在升级的过程中没有未完成的请求事务，尽可能地避免服务的抖动，实现了平滑升级。

实施例1

本实施例提供一种服务平滑升级的方法。如图3所示，其包括如下步骤：

步骤110：将多个新版服务节点注册到第一服务组，并将该第一服务组注册到服务发现应用程序中。

本步骤按组注册的优点在于，在版本更新的时候，所有的操作都是按一个组别来操作，而不是一台机器、一台机器的操作，因为服务发现列表(其是服务发现应用程序中的列表)每次变更都会引发代理服务重载配置，这样可以尽可能地可以减少代理服务重载配置的次数。

步骤120：从该服务发现应用程序中对待下线的包括多个旧版服务节点的第二服务组执行模拟下线，并将新的请求事务全部连接到上述多个新版服务节点上，使多个旧版服务节点停止接收新的请求事务，仅处理在模拟下线之前接收到的待处理的请求事务。这里的请求事务可以理解成客户端和服务端的一次数据交互。具体地，请求事务是客户端对服务端发起的请求，例如客户端发送了一个http请求到服务端，但是这里不仅仅是http请求，可以是任何协议的请求。

步骤130：当第二服务组中的旧版服务节点将待处理的请求事务处理完成后，将旧版服务节点停止服务。

进一步地，该步骤110具体可以包括：在升级或者灰度测试时，将所有提供对外服务的新版服务节点启动并注册到第一服务组中，然后将该第一服务组统一注册到服务发现应用程序的存储集群中。作为一个示例，该服务发现应用程序的存储集群可包括：etcd或zookeeper存储集群。etcd是一个开源的用来存储配置的分布式数据库中间件。etcd集群的工作原理基于raft共识算法(The Raft Consensus Algorithm)。raft共识算法的优点在于可以在高效的解决分布式系统中各个节点日志内容一致性问题的同时，也使得集群具备一定的容错能力。即使集群中出现部分节点故障、网络故障等问题，仍可保证其余大多数节点正确的步进。甚至当更多的节点(一般来说超过集群节点总数的一半)出现故障而导致集群不可用时，依然可以保证节点中的数据不会出现错误的结果。ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，它为分布式应用提供一致性服务，其功能包括：配置维护、域名服务、分布式同步、组服务等。服务发现应用程序是一个发现服务的手段或者服务，服务发现存储负责将发现的服务节点信息进行存储。

进一步地，该还包括步骤：将已注册的第一服务组和所述第二服务组从服务发现应用程序中更新到代理服务节点的代理服务列表。在步骤120中，从代理服务节点的代理服务列表中摘除多个旧版服务节点。这样可使得该多个旧版服务节点停止接收新的请求事务。代理服务节点是客户端与一个或多个服务节点之间的中间件，负责管理、记录多个服务节点的信息并完成服务节点的调度，例如在一个服务节点宕机时，其调度另一可用的服务节点继续为客户端/业务需求方服务，或者调度多个服务节点共同为同一客户端完成一项服务。

代理服务节点与服务发现应用程序进行实时数据通信，其能够获取服务发现存储集群中的服务发现列表，将该服务发现列表按照本代理服务节点的格式要求转换成代理服务列表。也即，服务发现应用程序负责发现提供服务的节点信息，包括服务节点的IP和PORT。代理服务节点通过例如数据同步的方式或借助监听服务模块进行数据更新，形成代理服务列表。代理服务列表是服务发现应用程序所发现的所有能提供某个服务的节点(服务器)列表，具体呈现方式可以是服务IP和端口号PORT。

作为一个示例，上述代理服务节点可包括：nginx代理服务节点、Linux虚拟服务器代理服务节点、或者heartbeat代理服务节点。对于服务代理软件，本发明实施例使用nginx这个开源软件来举例说明，但不以此为限，本发明的实施例也支持常用的lvs，heartbeat等代理中间件，其原理是程序自动修改代理软件的配置文件，然后自动化的重载配置。

本发明实施例的上述方法采用分组的方式划分服务节点，在升级时直接将新版本服务节点注册到新分配的服务组，并注册到服务发现应用程序中，然后从服务发现应用程序中批量模拟下线掉要下线的旧版本服务组，使其不再接收新的请求事务，而只是继续处理在模拟下线以前的待处理的旧的事务请求，并且在这些旧的事务请求均处理完成以后，才真正彻底地将旧版服务节点停止服务。这样可以确保在升级的过程中没有未完成的请求事务，尽可能地避免服务的抖动，降低服务在升级中服务频繁抖动的情况，实现平滑升级。

实施例2：

本实施例提供一种服务平滑升级的装置，其包括：服务组管理模块，用于将多个新版服务节点注册到第一服务组，并将该第一服务组注册到服务发现应用程序中；模拟下线管理模块，用于从该服务发现应用程序中对待下线的包括多个旧版服务节点的第二服务组执行模拟下线，并将新的请求事务全部连接到多个新版服务节点上，使多个旧版服务节点停止接收新的请求事务，仅处理在模拟下线之前接收到的待处理的请求事务；监听服务模块，用于当第二服务组中的旧版服务节点将待处理的请求事务处理完成后，将旧版服务节点停止服务。

进一步地，服务组管理模块，具体可用于在升级或者灰度测试时，将所有提供对外服务的新版服务节点启动并注册到第一服务组中，然后将该第一服务组统一注册到服务发现应用程序的存储集群中。该服务发现应用程序的存储集群可包括：etcd或zookeeper存储集群。

进一步地，监听服务模块，还用于将已注册的所述第一服务组和所述第二服务组从所述服务发现应用程序中更新到代理服务节点的代理服务列表。模拟下线管理模块，具体用于从该代理服务节点的代理服务列表中摘除上述多个旧版服务节点。该代理服务节点可包括：nginx代理服务节点、Linux虚拟服务器代理服务节点、或者heartbeat代理服务节点。

以下举例进行更加详细的说明，如图4所示，本发明的实施例在现有技术的基础上增加了服务组管理模块、模拟下线管理模块。服务组管理模块负责服务节点信息分组管理，模拟下线管理模块负责在对外服务的组，当一个组要从代理服务列表中摘除时用该模拟下线管理模块可以模拟下线将其摘除掉，其原理是模拟服务节点停止服务的方式，当监听到服务节点模拟停止服务，监听服务会将其从代理服务列表中摘除，但是真实的情况是该节点暂时还没有停止服务，只是通过从代理服务列表中摘除停止接受新的请求事务。从而避免在升级切换过程中导致有的事务没有完全处理完成就停止服务。当被摘除的服务节点没有处理的事务时再真正地将其停止掉。

再如图4所示，假如有N个服务节点，比如要升级这N这个服务节点，大致的流程是：将新版的服务节点重新分配一个组为group1，而旧版本的服务节点组名为group2，将所有的新版节点启动并注册到group1组中，然后统一注册到etcd服务发现存储中，在本发明的实施例中注册服务是通过组的方式注册，不再是以单个服务节点的方式注册。此时其实是新旧版混合的处理新的请求事务，利用模拟下线管理模块将旧版服务group2组下线掉，新的请求事务将全部连接到新版的服务节点上，旧版本的服务节点在处理完以前接收的请求事务就可以彻底地下线掉(停止掉)。

本申请的上述技术方案的有益技术效果在于：可以降低服务在升级中频繁抖动的情况，避免了服务升级中有未处理完全的请求，同时方便管理服务升级版本迭代。

本发明实施例中所描述的方法或算法的步骤可以直接嵌入硬件、处理器执行的软件模块、或者这两者的结合。软件模块可以存储于RAM存储器、闪存、ROM存储器、EPROM存储器、EEPROM存储器、寄存器、硬盘、可移动磁盘、CD-ROM或本领域中其它任意形式的存储媒介中。示例性地，存储媒介可以与处理器连接，以使得处理器可以从存储媒介中读取信息，并可以向存储媒介存写信息。可选地，存储媒介还可以集成到处理器中。处理器和存储媒介可以设置于ASIC中，ASIC可以设置于用户终端中。可选地，处理器和存储媒介也可以设置于用户终端中的不同的部件中。

以上所述的具体实施方式，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施方式而已，并不用于限定本发明的保护范围，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。