一种分布式服务健康检查的方法及其系统与流程

本发明涉及的云计算技术领域，尤其涉及一种分布式服务健康检查的方法及其系统。

背景技术：

在基于分布式服务部署的云计算平台中通常会部署负载均衡服务，该服务将负载(工作任务)进行平衡并分摊到多个操作单元上进行运行，例如ftp服务器、web服务器、企业核心应用服务器和其它主要任务服务器等，从而协同完成工作任务。

负载均衡服务进行任务分派的策略之一是判断工作单元的健康度是否达标，如果工作单元的健康度异常，负载均衡在该工作单元健康恢复之前停止分派任务给该工作单元，当负载均衡服务判断工作单元恢复健康后继续将工作单元纳入工作任务的调度集合中；然而目前，负载均衡服务判断工作单元健康的方法有两种：一种是心跳检查，负载均衡服务发送一个心跳报文(例如采用tcp/udp协议)给工作单元，工作单元在配置的时间范围内回复心跳，表示工作单元健康；第二种是api调用检查，负载均衡服务和工作单元约定一个api接口(例如采用http协议)，负载均衡服务调用api接口，工作单元返回预期的响应，表示工作单元健康；其工作单元一般是一台服务器，服务器执行实际工作任务的子单元(进程或线程)和用于执行健康检查的心跳任务或是响应负载均衡api调用请求的任务(进程或线程)是独立的；如果工作单元在执行处理健康检查任务的子单元出现问题，不代表工作单元处理工作任务的子单元也出现问题，因此，当前方法在判断工作单元是否健康的粒度过于粗大，无法精确判断工作单元在处理工作任务维度的健康度。

技术实现要素：

本部分的目的在于概述本发明的实施例的一些方面以及简要介绍一些较佳实施例。在本部分以及本申请的说明书摘要和发明名称中可能会做些简化或省略以避免使本部分、说明书摘要和发明名称的目的模糊，而这种简化或省略不能用于限制本发明的范围。

鉴于上述现有分布式服务健康检查的方法存在在判断工作单元是否健康的粒度过于粗大，且无法精确判断工作单元在处理工作任务维度的健康度的问题，提出了本发明。

因此，本发明目的是提供一种分布式服务健康检查的方法。

为解决上述技术问题，本发明提供如下技术方案：一种分布式服务健康检查的方法，包括如下步骤：

注册工作单元的工作任务健康参数到服务管理平台；

启动健康检查服务并向服务管理平台订阅各个工作单元注册的工作任务级别的健康参数；

健康检查服务周期性的向分布式服务中的各个工作单元发起健康检查；

启动负载均衡服务并向健康检查服务订阅工作单元在处理某个工作任务维度上的健康度，并根据健康度调整该工作单元的任务量。

作为本发明所述分布式服务健康检查的方法的一种优选方案，其中：所述注册工作单元的工作任务健康参数到服务管理平台包括步骤：

新建的工作单元在启动时通过接口调用将工作任务健康参数注册到服务管理平台；

对于已有的工作单元采用手动将工作任务健康参数注册到服务管理平台；

其中，所述接口通过http协议实现。

作为本发明所述分布式服务健康检查的方法及其系统的一种优选方案，其中：所述服务管理平台采用关系型数据库保存工作任务健康参数。

作为本发明所述分布式服务健康检查的方法及其系统的一种优选方案，其中：所述健康参数区分为工作单元的访问信息和工作任务健康参数；

其中，所述工作单元的访问信息包括ip地址和端口号；

其中，所述工作任务健康参数包括工作单元地址、工作任务标识和工作任务内容。

作为本发明所述分布式服务健康检查的方法及其系统的一种优选方案，其中：所述启动健康检查服务并向服务管理平台订阅各个工作单元注册的工作任务级别的健康参数的步骤还包括：当新的工作单元向服务管理平台注册健康参数，服务管理平台返回参数给健康检查服务。

作为本发明所述分布式服务健康检查的方法及其系统的一种优选方案，其中：所述订阅采用定时轮询或/和tcp长连接的方式实现。

作为本发明所述分布式服务健康检查的方法及其系统的一种优选方案，其中：所述健康检查服务周期性的向分布式服务中的各个工作单元发起健康检查的步骤包括：

配置周期性检查参数；

根据配置，读取工作任务检测参数；

构造api请求并发送至工作单元；

工作单元接收api请求并处理；

工作单元返回结果给健康检测服务；

健康检测服务根据返回结果评判该工作单元是否健康；

其中，所述检查参数包括检测时间间隔和检测次数；

其中，所述返回结果区分为返回成功、返回失败和返回超时。

作为本发明所述分布式服务健康检查的方法及其系统的一种优选方案，其中：所述健康度区分为健康和不健康。

作为本发明所述分布式服务健康检查的方法及其系统的一种优选方案，其中：所述负载均衡服务向健康检查服务订阅方式与所述健康检查服务向服务管理平台订阅方式相同。

作为本发明所述分布式服务健康检查的方法及其系统的一种优选方案，其中：一种分布式服务健康检查的方法，包括，

服务管理平台，用于工作单元注册并储存工作单元的工作任务健康参数；

向分布式服务，包括工作单元，所述工作单元与所述服务管理平台和健康检查服务建立连接；

健康检查服务，订阅服务管理平台上的各个工作单元的工作任务健康参数，并发送周期性的向分布式服务中的各个工作单元发起健康检查；以及，

负载均衡服务，与所述健康检查服务和连接，并根据健康检查服务检查的健康度调整所述工作单元的任务量。

本发明的有益效果：本发明能够对工作单元处理工作任务进行健康检查，从而精确判断出工作单元在处理工作任务时的健康度，进而避免了工作单元无法处理工作任务的情况下，负载均衡服务仍然将工作任务分配给工作单元，导致工作任务处理失败以及工作单元可以处理工作任务的情况下，负载均衡服务停止将工作任务分配给工作单元导致工作单元资源浪费的问题。

附图说明

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

图1为本发明分布式服务健康检查的方法及其系统的整体流程示意图。

图2为本发明分布式服务健康检查的方法及其系统所述的s1流程示意图。

图3为本发明分布式服务健康检查的方法及其系统所述的s3流程示意图。

图4为本发明分布式服务健康检查的方法及其系统所述的健康检查的详细流程示意图。

图5为本发明分布式服务健康检查的方法及其系统所述系统的原理示意图。

具体实施方式

为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合说明书附图对本发明的具体实施方式做详细的说明。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是本发明还可以采用其他不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本发明内涵的情况下做类似推广，因此本发明不受下面公开的具体实施例的限制。

其次，此处所称的“一个实施例”或“实施例”是指可包含于本发明至少一个实现方式中的特定特征、结构或特性。在本说明书中不同地方出现的“在一个实施例中”并非均指同一个实施例，也不是单独的或选择性的与其他实施例互相排斥的实施例。

再其次，本发明结合示意图进行详细描述，在详述本发明实施例时，为便于说明，表示器件结构的剖面图会不依一般比例作局部放大，而且所述示意图只是示例，其在此不应限制本发明保护的范围。此外，在实际制作中应包含长度、宽度及深度的三维空间尺寸。

实施例1

参照图1，提供了一种分布式服务健康检查的方法的整体结构示意图，如图1，一种分布式服务健康检查的方法包括步骤：s1：注册工作单元201的工作任务健康参数到服务管理平台100；

s2：启动健康检查服务300并向服务管理平台100订阅各个工作单元201注册的工作任务级别的健康参数；

s3：健康检查服务300周期性的向分布式服务200中的各个工作单元201发起健康检查；

s4：启动负载均衡服务400并向健康检查服务300订阅工作单元201在处理某个工作任务维度上的健康度，并根据健康度调整该工作单元的任务量。

具体的，本发明方法包括s1：注册工作单元201的工作任务健康参数到服务管理平台100；其中，服务管理平台100采用关系型数据库保存工作任务健康参数，而健康参数区分为工作单元的访问信息和工作任务健康参数；需说明的是，工作单元的访问信息包括ip地址和端口号；而工作任务健康参数包括工作单元地址、工作任务标识和工作任务内容，本实施例中，工作任务健康参数包括以下几个字段：

本实施例给出的方法是每个工作任务提供一个独立的api接口，例如api-h1表示工作任务1的健康检查api接口，健康检查服务300访问工作单元的api-h1接口，工作单元返回成功，表示工作单元在执行工作任务1的维度的健康度是达标的，反之则是不达标(失败或是超时)。

进一步的，如图2所示，注册工作单元201的工作任务健康参数到服务管理平台100的步骤包括：

s11：新建的工作单元201在启动时通过接口调用将工作任务健康参数注册到服务管理平台100，其中，工作单元是进行分布式计算的一个程序实例，可以运行在物理机(例如普通计算机)或是虚拟机上，新建就是在物理机或虚拟机启动这个程序实例，启动可以是人工启动也可以是通过执行脚本程序启动，而接口通过http协议实现，需说明的是，http是一个请求-响应协议，其指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应，而请求和响应消息的头以ascii码形式给出，其消息内容则具有一个类似mime的格式；

s12：对于已有的工作单元201采用运维人员手动将工作任务健康参数注册到服务管理平台100。

s2：启动健康检查服务300并向服务管理平台100订阅各个工作单元201注册的工作任务级别的健康参数；其中，启动健康检查服务300并向服务管理平台100订阅各个工作单元201注册的工作任务级别的健康参数的步骤还包括：当新的工作单元201向服务管理平台100注册健康参数，服务管理平台100返回参数给健康检查服务300，需说明的是，订阅采用定时轮询或/和tcp长连接的方式实现，其定时轮询是一种cpu定时决策如何提供周边设备服务的方式，又称“程控输入输出”(programmedi/o)，轮询法的概念是：由cpu定时发出询问，依序询问每一个周边设备是否需要其服务，有即给予服务，服务结束后再问下一个周边，接着不断周而复始，而tcp长连接，指在一个连接上可以连续发送多个数据包，在连接保持期间，如果没有数据包发送，需要双方发链路检测包；本实施例，订阅采用的是websocket协议实现(一种tcp长连接的方式)，健康检查服务向服务管理平台发起一个websocket连接，当有新的工作单元向服务管理平台注册健康参数后，服务管理平台通过websocket连接返回参数给健康检查服务。

需说明的是，当s1中服务管理平台100调用数据库sql的insert、update或是delete改变了工作单元的健康检查参数后，服务管理平台100通过websocket将改变后的参数返回给健康检查服务300。

s3：健康检查服务300周期性的向分布式服务200中的各个工作单元201发起健康检查，需说明的是，向分布式服务中一个工作单元包含多个工作任务，每个共工作任务实现了一个分布式服务功能，例如有一台计算机，该计算机启动了一个程序，此程序是一个工作单元，该程序实现了3个接口(别的工作单元通过网络通信调用这3个接口)，每个接口可以看作是一个工作任务；进一步的，如图3和图4所示，健康检查服务300周期性的向分布式服务中的各个工作单元201发起健康检查的步骤包括：

s31：配置周期性检查参数，其中，检查参数包括检测时间间隔和检测次数等；

s32：根据配置，读取工作任务检测参数；

s33：构造api请求并发送至工作单元201；

s34：工作单元201接收api请求并处理；

s35：工作单元201返回结果给健康检测服务300；

s36：健康检测服务300根据返回结果评判该工作单元是否健康；其中，健康度区分为健康和不健康，而返回结果区分为返回成功、返回失败和返回超时，需说明的是，返回成功表示该工作单元健康，而返回失败和返回超时该表示工作单元不健康，具体的，健康度基于不同业务场景，可以用true表示健康false表示不健康，本实施例不做限制，另外，健康检查服务可以基于工作任务相关的健康检查参数进行评定，比如说，健康检查参数包括了一个访问地址、访问参数、预期返回值、失败值以及返回超时参数，在健康检查时，如果收到失败值或者请求超时了，都可以评定为不健康。

本实施例中，提供的检查方式是s1描述的api调用，因为每个工作任务有对应的api，当工作单元收到api调用并返回成功结果给健康检查服务后，健康检查服务标记该工作单元在处理该工作任务的维度上是健康的。本方案在实施过程中，健康检查服务标记方式是写入数据库。

s4：启动负载均衡服务400并向健康检查服务300订阅工作单元201在处理某个工作任务维度上的健康度，并根据健康度调整该工作单元的任务量，其中，负载均衡服务400向健康检查服务300订阅方式与健康检查服务300向服务管理平台100订阅方式相同。

实施例2

本实施例中，worker1、worker2和worker3三台服务器为工作单元，三台服务器上都运行相同的服务程序：userservice；userservice提供一个http接口用于调用方获取用户信息；worker1、worker2和worker3运行的userservice代表本方案描述的工作单元；userservice启动后，通过服务管理平台提供的http接口注册任务健康参数，因为userservice只提供了一个http接口，因此它只注册一个任务健康参数，任务健康参数采用json格式表示，内容是：

其中address是运行了userservice的服务器地址；worker1、worker2和worker3启动后都向服务管理平台进行注册，因此服务管理平台将记录三条json表示的任务健康参数，其中除了address值不同之外，其它两个字段的值都相同；

健康检查服务(healthchecker)启动后和服务管理平台通过websocket协议建立一个长连接，连接建成功后，服务管理平台通过该长连接向healthchecker发送步骤2中worker1、worker2以及worker3已注册的任务健康检查参数；另外，healthchecker启动后同时和负载均衡服务器通过websocket建立一个长连接，用来进行信息交换；

healthchecker根据自身配置(本应用场景是每隔5秒)周期性的读取健康检查参数，对提供userservice服务的服务器进健康检查。在本应用场景中，healthchecker读取了三条健康检查参数后，分别向worker1、worker2以及worker3发送http请求，其中：

请求的方法、地址从taskid字段读取，

请求参数从taskcontent的rquest字段读取。

其中，worker1、worker2返回的结果和taskcontent的response字段一致表示worker1、worker2在处理该接口任务时正常，是健康的；worker3返回的结果和taskcontent的response字段不一致，表示worker3在处理该任务接口时不正常的；healthchecker将worker1、worker2和worker3的健康状态通过步骤4中和负载均衡服务器建立的长连接发送给负载均衡服务器；负载均衡服务器更新worker1、worker2、worker3健康状态，后续收到获取用户信息请求时，只将该请求转发给worker1和worker2。

本实施例的测试场景一：

把分布式服务健康检查系统在服务器上部署，传统方法的服务器和使用本方法的服务器上都运行相同的服务程序，测试人员分别同时向两台服务器发送服务健康度检查，经过多次测试实验得出的检测准确率可参照下表中。

表1为传统方法与本发明服务健康检查的对比表

通过上表，可观察到，使用本方法的服务健康准确度明显大于传统方式(基于心跳的服务健康度检查)服务健康准确度，如此可避免了工作单元无法处理工作任务的情况下，负载均衡服务仍然将工作任务分配给工作单元，导致工作任务处理失败以及工作单元可以处理工作任务的情况下，负载均衡服务停止将工作任务分配给工作单元导致工作单元资源浪费的问题。

本实施例的测试场景二：

测试场景：

1、10个工作任务。

2、每个工作任务是一个服务进程。

3、每个服务进程中运行两个线程。

3.a、线程1(任务线程)实现一个http测试接口，表示实际的工作任务。

3.b、线程2(心跳线程)实现一个心跳接口。

4、每次测试随机让工作任务的3.a或3.b返回错误，其中3.a返回错误，表示服务进程不健康；设置错误线程分布及测试结果如下：

由上表可得到：传统方案存在服务健康检查识别不出以及识别错误的情况；本方案服务健康检查识别准确率接近100％，并且没有错误的情况，同时能够精确判断出工作单元在处理工作任务时的健康度，进而避免了工作单元无法处理工作任务的情况下，负载均衡服务仍然将工作任务分配给工作单元，导致工作任务处理失败以及工作单元可以处理工作任务的情况下，负载均衡服务停止将工作任务分配给工作单元导致工作单元资源浪费的问题。

实施例3

参照图5，该实施例不同于第一个实施例的是：本实施例为一种分布式服务健康检查的系统，其分布式服务健康检查的系统包括服务管理平台100，用于工作单元201注册并储存工作单元201的工作任务健康参数；向分布式服务200，包括工作单元201，工作单元201与服务管理平台100和健康检查服务300建立连接；健康检查服务300，订阅服务管理平台100上的各个工作单元201的工作任务健康参数，并发送周期性的向分布式服务200中的各个工作单元201发起健康检查；以及，负载均衡服务400，与健康检查服务300和连接，并根据健康检查服务300检查的健康度调整工作单元201的任务量。具体的，本分布式服务健康检查的系统包括服务管理平台100，用于工作单元201注册并储存工作单元201的工作任务健康参数，其工作单元和服务管理平台都是软件app，这些软件运行在服务器上，服务器可以是物理机(譬如pc就是电脑)或是虚拟机(可能一台物理的电脑上部署了多个虚拟机)也可能是类似亚马逊提供的云主机；向分布式服务200，包括工作单元201，工作单元201与服务管理平台100和健康检查服务300建立连接，需说明的是，分布式服务是一个业务处理流程相关的软件实例部署在不同的服务器主机上(服务器可以是普通电脑，虚拟机甚至是云主机)，这些服务器通过网络互联；当一个业务请求从客户端发起后，经过若干服务器上的软件服务处理完成后，这个业务最终生成结果；健康检查服务300，订阅服务管理平台100上的各个工作单元201的工作任务健康参数，并发送周期性的向分布式服务200中的各个工作单元201发起健康检查，健康检查服务是一个软件服务，就是用某种计算机语言例如java写的一个软件，该软件可以人工启动，也可以通过脚本配置在操作系统启动后自动；而负载均衡服务400，与健康检查服务300和工作单元201连接，并根据健康检查服务300检查的健康度调整工作单元201的任务量。

采用本发明能精确判断出工作单元在处理工作任务时的健康度，从而避免了：

1、工作单元无法处理工作任务的情况下，负载均衡服务仍然将工作任务分配给工作单元，导致工作任务处理失败；

2、工作单元可以处理工作任务的情况下，负载均衡服务停止将工作任务分配给工作单元导致工作单元资源浪费。

重要的是，应注意，在多个不同示例性实施方案中示出的本申请的构造和布置仅是例示性的。尽管在此公开内容中仅详细描述了几个实施方案，但参阅此公开内容的人员应容易理解，在实质上不偏离该申请中所描述的主题的新颖教导和优点的前提下，许多改型是可能的(例如，各种元件的尺寸、尺度、结构、形状和比例、以及参数值(例如，温度、压力等)、安装布置、材料的使用、颜色、定向的变化等)。例如，示出为整体成形的元件可以由多个部分或元件构成，元件的位置可被倒置或以其它方式改变，并且分立元件的性质或数目或位置可被更改或改变。因此，所有这样的改型旨在被包含在本发明的范围内。可以根据替代的实施方案改变或重新排序任何过程或方法步骤的次序或顺序。在权利要求中，任何“装置加功能”的条款都旨在覆盖在本文中所描述的执行所述功能的结构，且不仅是结构等同而且还是等同结构。在不背离本发明的范围的前提下，可以在示例性实施方案的设计、运行状况和布置中做出其他替换、改型、改变和省略。因此，本发明不限制于特定的实施方案，而是扩展至仍落在所附的权利要求书的范围内的多种改型。

此外，为了提供示例性实施方案的简练描述，可以不描述实际实施方案的所有特征(即，与当前考虑的执行本发明的最佳模式不相关的那些特征，或于实现本发明不相关的那些特征)。

应理解的是，在任何实际实施方式的开发过程中，如在任何工程或设计项目中，可做出大量的具体实施方式决定。这样的开发努力可能是复杂的且耗时的，但对于那些得益于此公开内容的普通技术人员来说，不需要过多实验，所述开发努力将是一个设计、制造和生产的常规工作。

应说明的是，以上实施例仅用以说明本发明的技术方案而非限制，尽管参照较佳实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，可以对本发明的技术方案进行修改或者等同替换，而不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。