CN102135929A - 一种分布式容错服务系统 - Google Patents

Abstract

本发明实施例中提供了一种分布式容错服务系统，包括：至少一节点单元，用于运行并管理一个或多个服务进程，所述服务进程包括业务服务进程；至少两个主控控制单元，该主控控制单元互为冗余备份，用于获取各节点单元上报的各服务进程的服务状态信息，并据此使客户端根据获得的业务服务地址信息实现与相应的业务服务进程的业务交互；数据库，同时连接于所述多个主控控制单元，用于为所述多个主控节点提供数据共享。采用本发明实施例中的方案，可以实现容错备份。同时，节点单元上运行不同的服务进程进行相应的服务及服务的管理，实现分布式服务系统的集中管理，集中配置，自动发布部署，实时状态采集，实时流量监控功能。

Description

一种分布式容错服务系统

技术领域

本发明涉及计算机技术领域，尤其涉及一种分布式容错服务系统。

背景技术

分布式系统(distributed system)是建立在网络之上的软件系统。正是因为软件的特性，所以分布式系统具有高度的内聚性和透明性。因此，网络和分布式系统之间的区别更多的在于高层软件(特别是操作系统)，而不是硬件。

在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件(middleware)负责实现这个模型。

但是，现有的基于中间件的平台在实际运营上考虑较少，在实际使用时存在分布式部署不够灵活，平台服务状态采集监控考虑较少，服务不易集中管理等不足。例如以基于Ice 3.11版本Icegrid[1]平台为例，框架由Ice主控及节点组成。缺少实际运营中运营状态采集监控、web化集中管理。而且主控无法进行热备，存在单点缺陷

发明内容

本发明实施例所要解决的技术问题在于，提供一种分布式容错服务系统，可保证系统上运行的服务的集中管理，分布式容错运行。

在本发明实施例中提供的分布式容错服务系统包括：至少一节点单元，用于运行并管理一个或多个服务进程，所述服务进程包括业务服务进程和控制服务进程，所述控制服务进程用于实现系统的业务的控制；至少两个主控控制单元，该多个主控控制单元互为冗余备份，用于根据各节点单元上报的业务服务进程的服务状态信息，与客户端交互，并使客户端根据对应的业务服务地址信息实现与相应的业务服务进程的业务交互。

其中，该系统还可包括：Web服务管理平台，连接于所述多个主控控制单元，用于对所述多个节点单元运行的服务进程进行配置和管理。

以及下述单元中的一个或多个：发布服务单元，部署于所述节点单元，用于管理待发布服务文件，当进行服务发布时，为需要部署待发布服务的节点单元提供所述待发布服务文件；配置服务单元，部署于所述节点单元，用于管理服务配置文件，为运行于所述节点单元的服务进程提供配置文件；日志服务单元，部署于所述节点单元，用于接收并管理所述节点单元收集上报的日志信息；一组统计服务进程，部署于所述节点单元，用于统计系统中服务间接口调用情况，获取服务发起外部接口调用时上报的调用信息，根据该上报的调用信息进行服务监控；属性服务单元，部署于所述节点单元，用于接受业务自定义上报的属性信息，并根据上报的属性信息进行服务监控；异常信息上报服务单元，部署于所述节点单元，用于收集并管理各节点单元中运行的服务进程的异常信息，并将该收集的异常信息上传至所述Web服务管理平台。

上述的节点单元还可包括：服务管理模块，用于对自身运行的一个或多个服务进程进行管理，所述管理包括服务的起停控制、服务状态监控及服务消息的通知。

本发明实施例提供的方案中，系统中的主控控制单元为多个，可以实现容错备份。同时，节点单元上运行不同的服务进程进行相应的服务及服务的管理，使得该分布式系统部署灵活，服务易于集中管理。同时，由于引入了Web服务管理平台，使得管理web化，更加人性化；而采用发布服务进程统一管理服务的发布，可实现服务的同一发布。

附图说明

图1是本发明实施例中的分布式容错服务系统的一个具体组成示意图；

图2是本发明实施例中的分布式容错服务系统的另一个具体组成示意图；

图3是本发明实施例中的分布式容错服务系统的另一个具体组成示意图；

图4是本发明实施例中的分布式容错服务系统中的进程的示意图；

图5是本发明实施例中的web平台中的信息流示意图。

具体实施方式

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

随着无线业务的高速发展，分布式系统面临的开发问题越来越多：服务模块众多、服务模型多样化、部署管理凌乱、监控体系不够精细化、面向两种语言等。开发和运营都比较被动，为了能够系统解决这些问题，发明人提出了本发明实施例中的分布式容错服务系统，该系统的设计理念是在系统中实现框架分层可剥离设计，让平台解决大部分问题，并根据运营不断完善；让业务开发更关注业务逻辑，让运营面向单一、人性化的管理平台。为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图对本发明实施例进一步详细说明。

参考图1，为本发明实施例中的分布式容错服务系统的一个具体组成示意图，该系统包括：

节点单元2，用于运行并管理一个或多个服务进程，所述服务进程包括业务服务进程和控制服务进程，所述控制服务进程用于实现系统的业务的控制。在一个系统中可以包括一个或多个节点单元。

主控控制单元1，该主控控制单元至少为两个，当然也可以为三个或更多。这些主控控制单元之间互为冗余备份，用于根据各节点单元上报的业务服务进程的服务状态信息，与客户端交互，并使客户端根据对应的业务服务地址信息实现与相应的业务服务进程的业务交互。如，主控控制单元获取各节点单元上报的各服务进程的服务状态信息后，根据该服务状态信息生成可用服务列表信息，在接收到来自客户端发起的业务服务地址信息获取请求时，根据所述可用服务列表信息向所述客户端返回业务服务地址信息，以使客户端根据该业务服务地址信息实现与相应的业务服务进程的业务交互。

为了，实现数据共享，该系统还可以包括数据库3，同时连接于所述多个主控控制单元，用于为所述多个主控节点提供数据共享。如图2所示。

其中，所述节点单元可包括：服务管理模块，用于对自身运行的一个或多个服务进程进行管理，所述管理包括服务的起停控制、服务状态监控及服务消息的通知。

在一些实施例中，上述的节点单元和主控控制单元可以采用服务器实现。

如图3所示，该系统还可进一步包括Web服务管理平台4，连接于所述多个主控控制单元，用于对所述多个节点单元运行的服务进程进行配置和管理。

同时，上述的控制服务进程可以进一步包括以下进程组中的一个或多个：一组发布服务进程、一组配置服务进程、一组日志服务进程、一组统计服务进程、一组属性服务进程、一组异常信息上报服务进程。根据实际需要，不同的类型的进程可以布置在同一节点单元上，也可以布置在不同的节点单元上；一组进程，则可分别布置在不同的节点服务上，即，这些服务进程可以分布式的布置在系统的节点单元上。在后续实施例中将对其进行进一步的描述。其中，对上述的进程组中的进程数目并没有限制，可以为一个或多个等等。

相应的，则上述的分布式容错服务系统还包括：

一组发布服务单元，部署于所述节点单元，用于管理待发布服务文件，当进行服务发布时，为需要部署待发布服务的节点单元提供所述待发布服务文件。

一组配置服务单元，部署于所述节点单元，用于管理服务配置文件，为运行于所述节点单元的服务进程提供配置文件。

一组日志服务单元，部署于所述节点单元，用于接收并管理所述节点单元收集上报的日志信息。

一组统计服务单元，部署于所述节点单元，用于统计系统中服务间接口调用情况，获取服务发起外部接口调用时上报的调用信息，根据该上报的调用信息进行服务监控。其中，该统计服务进程还可进一步用于将所述服务监控的信息上报至Web服务管理平台，供运营维护人员进行查看监控。

一组属性服务单元，部署于所述节点单元，用于接受业务自定义上报的属性信息，并根据上报的属性信息进行服务监控。

一组异常信息上报服务单元，部署于所述节点单元，用于收集并管理各节点单元中运行的服务进程的异常信息，并将该收集的异常信息上传至所述Web服务管理平台。

上述的各单元(即服务服务单元、配置服务单元、日志服务单元、统计服务单元、属性服务单元及异常信息上报服务单元)对应于前述的各进程，用于实现相应的进程的功能。这些单元可以是按组的形式存在，对一组中的单元的数目也没有任何限制。

这些，系统中的运行在节点单元上的进程，在同一节点单元中可使用前述的服务管理模块进行管理。该服务管理模块在节点单元上也可采用一个相应的服务进程(如，节点服务进程)来实现。同时，根据需要，在同一节点单元上也可以布置多个节点服务进程。

在上述实施例中，系统中的主控控制单元为多个，可以实现容错备份。同时，节点单元上运行不同的服务进程进行相应的服务及服务的管理，使得该分布式系统部署灵活，服务易于集中管理。同时，由于引入了Web服务管理平台，使得管理web化，更加人性化；而采用发布服务进程统一管理服务的发布，可实现服务的同一发布。

以下以进程为基础，对本发明实施例进行进一步描述。相应的，如图4所示，该系统包括下述的控制服务进程：一组主控控制服务(图示为，registry 1、registry2、registryn)、一组节点服务(图示为，node1、noden)、一组发布服务(图示为，patch服务)、一组日志服务(图示为，log服务)、一组配置服务(图示为，config服务)、一组异常通知服务(图示为，notify服务)、一组服务间调用服务(图示为，stat服务)及一组属性上报服务(图示为，property服务)。同时系统还包括录入服务信息的Web服务管理平台(图示为，web平台)。

其中，在node1，......，noden中的Server1、Server2、ServerN表示节点管理的业务服务进程，“172.16.28.36”及“172.16.28.36+N”表示本例中的节点服务所在的IP地址。

其中，主控控制服务在各主控控制单元上运行，其余服务则在各节点单元上运行。各服务可通过web平台实现统一管理和配置。

对于应用服务(即针对客户端的具体的业务服务)，其通过web平台配置到主控控制单元，通过发布服务发布至各个节点单元。在节点单元上，节点服务对服务进行启动、停止、通知等管理操作，并根据应用服务的上报心跳情况对服务进行实时监控。节点服务负责向主控服务上报节点上应用服务的运行状态，上报状态可以通过web平台查看。

以下进一步结合上述各控制服务描述应用服务的运行：应用服务在运行过程中通过配置服务获取服务配置，通过主控服务获取需调用地址信息，通过内嵌api上报接口信息至服务间调用服务，通过异常通知服务上报运行中异常信息，通过属性服务上报需要关注的属性，通过日志服务统一写网络日志。实现对服务调用耗时信息、服务属性信息、服务异常信息的统一采集。平台根据这些数据完成服务的统一监控。

通过上述描述可知，上述的各控制服务也可以采用分布式技术运行在多个节点单元。一个节点单元可以只运行一种类型的服务进程也可以运行多种服务进程。对于系统而言，可以按照上述的分组类型将服务进程分组进行管理。

因此，由于系统各组服务均基于分布式容错部署，以组的形式发布在多个节点单元和主控控制单元上，而一般不同的主控控制单元和节点单元配置在不同的服务器上，保证一台机器的故障不影响整体业务。并通过本地保存数据缓存、对上报类服务器实行单行调用，降低了系统间耦合依赖性。防止服务器故障相互影响。

以上各组服务相互配合完成了服务的分布式部署、容错运行，实现了运营维护的集中管理、自动测试、实时监控，提高了服务稳定性及可维护性。在实际应用中效果良好。

另一方面，web平台除了服务配置功能外，还具备服务控制、服务信息展示及自动测试功能。可以通过主控控制服务调用节点服务实现对应用服务的启动、停止、发布、通知等操作进行服务控制。通过读取异常通知服务，展示服务的上报信息，包括启动停止记录等，通过读取服务间调用服务展示服务调用信息，通过读取属性上报服务器展示服务属性信息。

web平台自动测试功能原理如下，由于平台上部署的服务可采用了自定义的编解码协议，在web平台上通过主控控制服务获取服务信息后配置接口及调用参数，并组包发往后台服务端，根据后台返回包解包展示在web上实现web自动测试功能。

以下分别介绍各单元实现的相应的控制服务：

1、主控控制(registry)单元，用于运行主控控制服务，可部署在相应的服务器上。是系统的主控中心，提供了本发明实施例中的分布式容错服务系统的核心管理功能。服务的基本配置放在数据库(如称为mysql db)中，主控间通过数据库(db)完成数据共享。

主要功能包括：为节点服务提供各服务的配置信息；收集节点服务的服务状态信息；为客户端提供可用服务列表信息；缓存服务状态信息；db容错；提供命令行、脚本或管理页面等方式管理服务。

2、节点(node)单元，用于运行节点服务，不同的节点单元可分别部署在相应的服务器上。节点单元管理该服务器上的业务服务，内嵌了patch-client。在一个节点单元上可部署一个或多个节点服务。

节点服务主要负责对节点单元上的服务进行管理，主要功能：服务起停；服务监控，对异常退出服务、僵死服务重启；服务状态采集，采集服务进程id、运行状态等；配合进行服务发布，作为客户端与发布服务完成发布；配合进行服务配置管理，根据主控控制获得服务信息生成服务配置文件；服务消息通知，与web平台或admin服务、registry服务共同完成服务消息通知。

3、发布(patch)服务单元，用于实现发布服务进程，一个单元对应实现一个进程。可以组的形式存在，并布置在一组节点单元上，具体可用于发布更新具体的业务服务，节点服务内嵌了patch服务的客户端，可以从patch服务同步文件到node服务所在的节点单元。

Patch服务启动时需要设置一个需要同步的文件目录路径，客户端需要同步文件的时候，指定该目录的相对路径，即可以同步该目录下的任何文件和目录。

进行patch服务可包含以下几个组件部分：patch服务，提供文件下载功能；patch库，可以被其他程序使用，该库文件可以用于从patch服务同步文件和目录到本地，同时patchclient也调用了该库实现；patchclient(patch服务的客户端)，通过客户端执行程序，可以很方便的把patch的某个文件或者目录同步到本地。

4、配置(config)服务单元，用于实现配置服务进程，一个单元对应实现一个进程。可以组的形式存在，并布置在一组节点单元上，具体可用于管理配置文件，业务服务可以通过框架层的api从配置中心拉取指定的配置文件到本地。

5、日志(log)服务单元，用于实现日志服务进程，一个单元对应实现一个进程。可以组的形式存在，并布置在一组节点单元上，具体可用于接收远程日志。业务服务可以通过框架层的api异步发送日志到日志服务器。

6、统计(stat)服务单元，用于实现配置服务进程，一个单元对应实现一个进程。可以组的形式存在，并布置在一组节点单元上，具体可用于统计整个框架中接口调用的情况。并根据统计数据进行服务监控。本发明实施例的系统的服务内嵌stat客户端于通信器中，不是本系统中定义的服务也可以通过api上报。

主要作用功能：定时上报外部接口间调用信息给统计服务器，只要接入平台的服务将自动有框架进行上报；采集指标包括主调模块、被调模块、主调ip、被调ip、被调端口、返回值、成功数、超时数、异常数、最大处理时间、最小处理时间、总处理时间、服务调用时间区间分布；可查询指定服务性能；web平台展示数据调用情况；基于stat服务数据对服务进行告警监控；统计整个框架中接口调用的情况。

7、属性(property)服务单元，用于实现配置服务进程，一个单元对应实现一个进程。可以组的形式存在，并布置在一组节点单元上，具体可用于统计业务自己的数据。并基于上报属性进行告警。业务可以通过api将需要统计的数据上报给属性服务器；跟stat服务相比，stat服务的指标为框架自动采集，property服务的指标为用户自定义上报。属性服务支持：平均Avg、计数Count、求和Sum、分布Distr等统计方式，在web管理平台展示数据的状况。基于property服务数据进行服务属性监控

8、异常信息上报(notify)服务单元，用于实现配置服务进程，一个单元对应实现一个进程。可以组的形式存在，并布置在一组节点单元上。具体功能包括：上报框架和业务异常信息；上报后，在web管理平台可以展示；并基于异常信息进行监控，实现异常信息的邮件、RTX、短信通知。

相应的，本发明实施例中的系统还包括web管理平台(web平台)，该平台的管理的功能主要有：服务部署配置；发布服务；起停服务；查看服务状态；管理服务配置文件；接口级别的自动测试；自web网页进行服务接口测试；框架上各接口调用情况；展示stat服务信息；业务上报的属性统计状况；展示property服务信息；业务上报的异常信息；展示notify服务信息。

如图5所示，该web平台的信息流图：

1)Registry相关：

Start Registry：Registry启动时数据库加载服务信息；

Stop Server：Registry通知Node Stop服务，并更新数据库服务状态为inactive；

Start Server：Registry通知Node Start服务，并更新数据库服务状态为active；

Patch Server：Registry通知Node Patch服务；

Find Object List：Registry会收到Proxy获取对象列表的请求；

Node Keep Live(节点保持活跃)：node会定时向Registry上报状态。

2)Node相关：

Start Node：Node启动时到Registry注册，并从Registry获取Node上所有服务的配置信息；

Stop Server：收到Registry的Stop Server请求后，停止服务，并在内存在更新服务状态为inactive，服务在5s内没有退出，则Node直接kill掉服务；

Start Server：收到Registry的Start Server请求后，启动服务，并在内存在更新服务状态为active；

Check Server：Node定时检查状态为active的服务，如果死掉，则启动之；

Node定时检查状态为inactive的服务，如果在运行，则停止之；

Patch Server：收到Registry的Patch Server请求后，到PatchServer同步服务的程序目录到本地；

Keep Live：Node会定时向Registry上报状态；

Server Keep Live：Server会定时向Node上报自己的状态。

3)Server(服务)相关：

Server的启动通常是Node fork出来的，也可以是手工启动的；

Node和Server之间采用本地socket交互；

Stop Server：服务收到Node的Stop Server后，会自动停止；

Server会定时向Node上报自己的状态；

Server向stat上报接口间调用信息

Server向property上报属性信息

Server向log打印远程日志

Server向config拉取服务配置信息

Server向notify上报异常信息。

4)Proxy相关：

Find Object List：Proxy会定时调用Registry，获取对象的列表；

Proxy会根据对象列表，建立到每个服务的连接；

一旦调用服务失败，则屏蔽该服务，隔一段时间后重试。

通过以上描述可知，本发明实施例中的系统实现了服务的集中管理，统一发布，分布式容错运行，自动测试，实时状态采集，实时流量监控。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行各个实施例或者实施例的某些部分所述的方法。

以上所揭露的仅为本发明较佳实施例而已，当然不能以此来限定本发明之权利范围，因此依本发明权利要求所作的等同变化，仍属本发明所涵盖的范围。

Claims (10)

1.一种分布式容错服务系统，其特征在于，该系统包括：

至少一节点单元，用于运行并管理一个或多个服务进程，所述服务进程包括业务服务进程和控制服务进程，所述控制服务进程用于实现系统的业务的控制；

至少两个主控控制单元，该主控控制单元互为冗余备份，用于根据各节点单元上报的业务服务进程的服务状态信息，与客户端交互，并使客户端根据对应的业务服务地址信息实现与相应的业务服务进程的业务交互。

2.如权利要求1所述的系统，其特征在于，所述系统还包括：

Web服务管理平台，连接于所述多个主控控制单元，用于对所述多个节点单元运行的服务进程进行配置和管理。

3.如权利要求2所述的系统，其特征在于，所述控制服务进程还包括发布服务进程，所述系统还包括：

至少一发布服务单元，部署于所述节点单元，用于管理待发布服务文件，当进行服务发布时，为需要部署待发布服务的节点单元提供所述待发布服务文件。

4.如权利要求2所述的系统，其特征在于，所述控制服务进程还包括配置服务进程，所述系统还包括：

至少一配置服务单元，部署于所述节点单元，用于管理服务配置文件，为运行于所述节点单元的服务进程提供配置文件。

5.如权利要求2所述的系统，其特征在于，所述控制服务进程还包括日志服务进程，所述系统还包括：

至少一日志服务单元，部署于所述节点单元，用于接收并管理所述节点单元收集上报的日志信息。

6.如权利要求2所述的系统，其特征在于，所述控制服务进程还包括统计服务进程，所述系统还包括：

至少一统计服务单元，部署于所述节点单元，用于统计系统中服务间接口调用情况，获取服务发起外部接口调用时上报的调用信息，根据该上报的调用信息进行服务监控。

7.如权利要求6所述的系统，其特征在于，所述统计服务单元进一步用于将所述服务监控的信息上报至Web服务管理平台，供运营维护人员进行查看监控。

8.如权利要求2所述的系统，其特征在于，所述控制服务进程还包括属性服务进程，所述系统还包括：

至少一属性服务单元，部署于所述节点单元，用于接受业务自定义上报的属性信息，并根据上报的属性信息进行服务监控。

9.如权利要求2所述的系统，其特征在于，所述控制服务进程还包括异常信息上报服务进程，所述系统还包括：

至少一异常信息上报服务单元，部署于所述节点单元，用于收集并管理各节点单元中运行的服务进程的异常信息，并将该收集的异常信息上传至所述Web服务管理平台。

10.如权利要求2至9中任一项所述的系统，其特征在于，所述节点单元包括：

服务管理模块，用于对自身运行的一个或多个服务进程进行管理，所述管理包括服务的起停控制、服务状态监控及服务消息的通知。

Images