CN102624919A - 一种面向服务架构的分布式业务集成***及其应用方法 - Google Patents

Abstract

本发明公开了一种面向服务架构的分布式业务集成***及其应用方法，属于计算机应用技术，解决了目前业务***无法进行动态管理，并且服务组件实例自动扩容、收缩能力较差，无法支撑大规模业务***实例同时进行的缺陷。本发明主要由部署节点集群、业务控制处理器、资源控制服务器、Web门户、服务接入点组成。本发明简化了服务提供商和用户的操作，提供稳定的运营环境，可以并发处理多个业务***的操作请求，在部署节点出现故障宕机时，通过解析出它们的关系，把注册过的消息通知相应的实例，让它们做出相应的处理，使得业务***提供的服务能在短时间内恢复可用，实现***的高可用性，非常适合推广使用。

Description

一种面向服务架构的分布式业务集成***及其应用方法

技术领域

本发明涉及一种业务集成***及其应用方法，具体地说，是涉及一种面向服务架构的分布式业务集成***及其应用方法。

背景技术

目前，大部分业务***都是单独设计和部署的，随着计算机应用的发展，这些单独设计和部署的业务***建设时间周期过长，无法快速提供能力，并且资源一经分配便难以更改，动态伸缩性差，按峰值规模建设的思路导致***平均利用率较低，缺乏一致性的服务访问，无法整合服务能力以及集成开发过程中的遗留***的问题，无法适应计算机领域的快速发展，因此业务***正逐步向半分布式，全分布式方向发展。

近些年来，面向服务的体系结构作为一个新兴的组件模型受到广泛的关注和使用，面向服务的体系结构通过建立统一的架构，使得软件开发人员能快速开发、集成和应用。目前的面向服务的体系结构大多数无法对各种分布式业务进行动态管理，并且服务组件实例自动扩容、收缩能力较差，无法支撑大规模业务***实例同时运行。同时，鉴于分布式结构的不可靠性，***容易出现故障宕机，***无法提供一个稳定的运营环境。

发明内容

本发明的目的在于克服业务***无法进行动态管理，并且服务组件实例自动扩容、收缩能力较差，无法支撑大规模业务***实例同时进行的缺陷，提供以一种面向服务架构的分布式业务集成***及应用方法，简化有权限的运营商的操作，提供稳定的运营环境，可以并发处理多个业务***的操作请求，达到提高***高可用性、高伸缩性和重用性的目的。

为了实现上述目的，本发明采用的技术方案如下：

一种面向服务架构的分布式业务集成***，包括承载服务组件的部署节点集群、监控和管理部署节点集群的资源控制服务器、与该资源控制服务器连接并处理业务***的请求和响应内部事件的业务控制服务器，以及分别连接该业务控制服务器的作为***对外统一的控制接口的Web门户和提供***服务接口查询的服务接入点。

进一步的，所述部署节点集群包括至少一个部署节点。

更进一步的，所述服务组件由一个服务插件和至少一个服务程序组成。

以上述硬件***为基础，本发明提供的面向服务架构的分布式业务集成***的应用方法，包括以下步骤：

（a）在分布式业务集成***上安装由配置文件、服务插件以及服务程序集组成的业务***；

（b）服务提供商通过Web门户启动安装的业务***；

（c）用户通过服务接入点访问安装的业务***的服务接口，进行对分布式业务集成***的使用。

其中所述步骤（a）具体包括：

（a1）用户填写配置文件；

（a2）按照***提示依次上传资源文件后，由业务控制服务器检查资源文件合法性并存储，生成对应的元数据。

进一步的，所述步骤（b）具体包括：

（b1）服务提供商在Web门户上选择已安装的业务***，并发送至业务控制服务器上进行处理；

（b2）业务控制服务器解析文件，并将其发送至资源控制服务器，资源控制服务器选择一个部署节点运行服务组件；

（b3）部署节点为服务组件分配地址，实现服务组件的启动及初始化工作，完成后，将启动结果返回；

（b4）重复步骤（b2）和（b3），直至所有服务组件启动成功；

（b5）业务***启动成功后，业务控制服务器通过资源控制服务器和业务控制服务器向服务接入点注册该业务***的服务接口、***实例号；

（b6）完成后向用户报告此次启动实例的结果以及服务组件实例的资源分布情况。

更进一步的，所述步骤（c）中用户完成对业务***的访问方式至少包括以下三种方式：

（c1）服务接入点首先查询自己内存中的服务组件列表，并将查询结果回复给客户；

（c2）服务接入点再查询自己内存中某个实例的服务接口，并将查询结果回复给客户；

（c3）用户完成查询后，调用部署节点上的服务。

本发明中还包括对服务组件的自动扩容和/或收缩方法，其步骤如下：

（1）部署节点检测到自身消耗的内存和/或网络中阈值超过预设的上限和/或下限时，向资源控制服务器发送该事件通知；

（2）资源控制服务器将事件转发给业务控制服务器；

（3）业务控制服务器对服务组件实例进行扩容和/或收缩。

再进一步的，本发明还包括对部署节点出现故障宕机后的恢复方法，包括以下步骤：

（1）资源控制服务器检测到部署节点出现故障宕机后，将出现故障宕机的部署节点上运行的服务组件放入故障实例队列内；

（2）业务控制服务器定时从资源控制服务器拉取出现故障宕机的服务组件，并将其重新启动。

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

（1）本发明对业务***实现了动态管理，并且对主机资源进行了分机，使服务提供商能够自动化、定制化地部署和运营具备高可用、高伸缩性和重用性强的服务。

（2）本发明运用服务组件实例框架，用户只需按照规范填写配置文件即可完成业务***的安装，既保证了业务正常运营，又简化了运营商的操作，简单实用。

（3）启动业务实例时，服务提供商只需在Web门户进行简单的操作，Web门户为浏览器门户，操作方便，极大地提高了业务应用的部署效率。

（4）服务组件通过资源控制服务器和业务控制服务器的配合操作，实现了自动扩容、收缩，并支撑了多个业务***的同时运行，既实现了高伸缩性，又实现了强重用性。

（5）部署节点出现故障宕机后，资源控制服务器能够感知此事件并且把宕机的部署节点放入待处理故障队列，业务控制服务器会定时向资源控制服务器拉取宕机的部署节点，并对其进行修复，从而使业务***能够在短时间内恢复可用，实现了动态管理，以及***的高可用性。

附图说明

图1为本发明的***框图。

图2为本发明的应用方法的流程图。

图3为本发明-实施例中业务***的安装流程图。

图4为本发明-实施例中业务***的启动流程图。

图5为本发明-实施例中业务***的访问流程图。

图6为本发明-实施例中业务组件的扩容和/或收缩方法的流程图。

图7为本发明-实施例中恢复故障节点的流程图。

具体实施方式

下面结合附图与实施例对本发明作进一步说明，本发明的实施方式包括但不限于下列实施例。

实施例1

一种面向服务架构的分布式业务集成***，如图1、2所示，包括承载服务组件的部署节点集群、监控和管理部署节点集群的资源控制服务器、与该资源控制服务器连接并处理业务***的请求和响应内部事件的业务控制服务器、以及分别连接该业务控制服务器的作为***对外统一的控制接口的Web门户和提供***中服务接口查询的服务接入点。业务控制服务器处理Web门户或者资源控制服务器的请求和响应内部事件，驱动其他模块进行相应操作，资源控制服务器负责部署节点集群的监控和管理，发现并建立、管理、负载均衡和监控部署节点，定位并处理故障节点的服务组件实例迁移。部署节点集群至少有一个部署节点，部署节点集群主要调用接口完成相应的操作，并且收集节点上资源的使用情况以及监控服务组件实例运行过程中的负载异常、程序故障等***突发事件，并汇报给资源控制服务器。Web门户连接业务控制服务器，实现对***的控制，业务控制服务器将服务接口的信息表传送给服务接入点，并且连接资源控制服务器，驱动资源控制服务器进行相应操作。资源控制服务器收到请求后监控以及管理部署节点集群，定位并处理故障节点的服务组件实例迁移。而服务元数据库的内存上保持着服务接口的信息表，供用户查询。

一个业务***包括配置文件、服务插件以及服务程序集三类资源。配置文件是服务提供商与***之间达成的协议，服务组件实例与服务程序集安装在部署节点上，服务插件是在部署节点上的具有相同的命名规则和接口标准的动态链接库，实现服务程序集的启动、停止和通知操作，具体的实现由服务开发商完成。服务程序集是具有特定功能的应用程序，它用来实现业务***的功能应用。部署节点可以抽象为一个服务组件实例框架，服务插件与服务程序集组成服务组件实例。配置文件以及服务组件实例的主要标签及说明如表1、2所示。

表1 ***配置文件主要标签说明

标签名	父标签	说明
			SYSTEM	无	业务***名及描述
MODULE_QUANTITY	START_ORDER	该业务服务组件实例的数量
			MODULE	START_ORDER	标识服务组件实例启动的时序关系
QUANTITYMAX	MODULE	该服务组件实例运行的最大数
			QUANTITYMIN	MODULE	该服务组件实例运行的最小数
KEYMODULE	MODULE	该服务组件实例是否为宕机就必须关闭整个业务***的关键组件
			ENTRY	MODULE	该服务组件实例是否为一个服务接口的入口
MONOPOLIZE	MODULE	该服务组件实例是否需要独占一个部署节

表2 服务组件实例配置文件主要标签说明

标签名	父标签	说明
			MODULE_NAME	MODULE_CONFIG	服务组件实例名
BIN_NAME_LIST	MODULE_CONFIG	应用程序名列表
			MONITOR_LIMIT	MODULE_CONFIG	扩容和/或收缩阀值

只有按照上述规范填写配置文件，然后才能在业务***安装时候正确解析配置的XML文档的树形结构，加载必要信息和属性，保证业务正常运营。

其中，如图3所示，安装一个业务流程的步骤如下：

（1）用户通过Web门户上的安装业务***页面上的提示，依次上传资源文件；

（2）Web门户将这些资源文件传至业务控制服务器；

（3）业务控制服务器按特定的目录结果存放，并检查资源文件的合法性，生成对应的业务***的元数据。

实施例2

在启动一个业务***时，由服务提供商进行操作，并且由***内部完成生成文件，对业务***进行编号，运行服务组件实例，返回启动结果的功能，

如图4所示，按照下面步骤启动一个业务***：

（1）服务提供商在Web门户上选择启动已安装的业务***；

（2）Web门户生成该业务的格式为“业务***名_实例号”，并发至业务控制服务器进行处理；

（3）业务控制服务器接收请求后，从***配置文件解析出服务组件实例数量和关系、启动顺序等，将要启动的服务组件实例名放入队列。业务检查队列不为空，读出队头服务组建的配置文件，生成一个服务组件实例实施号，启动报文并发送至资源控制服务器进行处理；

（4）资源控制服务器有资源池里部署节点的状态以及负载信息，根据负载因子计算权值，选择一个最为空闲的部署节点运行这个服务组件实例；

（5）部署节点上的Agent守护进程接收到启动报文后，为该服务组件实例分配IP、Port等资源，然后调用服务插件的Start接口，由服务插件实现服务程序集启动及初始化工作，完成后，将启动结果返回；

（6）若该组件返回启动成功，业务控制服务器将分配资源的位置进行记录，并且将信息发送至服务接入点进行保存，重复步骤（3）至（6），直至所有服务组件实例都启动完毕。若返回启动失败，则关闭已经启动的服务组件实例，并且从步骤（3）开始重新运行整个流程；

（7）业务***实例在***上启动成功后，业务控制服务器会向所有的服务接入点注册该业务的服务及接口、***实施号等信息；

（8）向用户报告此次启动实例的结果以及服务组件实例的资源分布情况。至此，启动业务***实例完成，服务提供商只需在浏览器上进行简单的操作，这种操作极大的提高了业务应用的部署效率。

实施例3

无论外部***的服务接入点还是其它业务***，如图5所示，都通过下列方法完成服务对平台内部署的所有业务***接口的访问：

（1）首先查询服务组件实例列表：用户通过服务接入点查询内存中存储的业务***实例表；

（2）收到回复后，用户查询服务组件实例中实例的服务接口：用户通过服务接入点发送报文，查询业务***实例的入口，业务***实例名被包含在报文中，然后用户再查询内存中存储的业务***入口表；

（3）服务组件实例得到服务接口的位置信息后，使用已部署的服务。

实施例4

部署节点采用集群方式实现，具有良好的伸缩性，动态地加入和/或减少节点并不会影响到平台的其它工作，部署节点上的服务组件实例可以实现自动扩容和/或收缩，如图6所示，按照下面的步骤完成：

（1）部署节点的守护进程检测到一段时间内该服务组件实例消耗的内存和/或网络其中一项或多项阈值超过上限和/或下限，向资源控制服务器发送该事件的通知；

（2）资源控制服务器将此事件转发给业务控制服务器；

（3）业务控制服务器对业务组件实例进行调整，然后检查调整后的业务***实例下组件实例数是否超过最大或者最小值，若超过，则忽略该消息，若没有超过，则开始扩容或者收缩。

实施例5

为了提供稳定的运营环境，***所有模块均采用异步事件驱动编程模型，可以并发处理多个业务***实例的操作请求，支撑大规模业务***实例同时运行，一个部署节点若出现宕机时，该节点上运行的服务组件实例将迁移到其它部署节点上。

部署节点出现故障宕机时，部署节点心跳超时，资源控制服务器监测到此事件后，重新启动部署节点上的实例分类排序列表，解析出它们之间的关系，并把注册过的消息通知相应的实例，让它们做出相应的处理，使得业务***提供的服务能在短时间内恢复可用。如图7所示，具体步骤包括：

（1）部署节点出现故障宕机后，部署节点心跳超时，监测到此事件后，资源控制服务器将该部署节点运行的服务实例放入故障实例队列里；

（2）业务控制服务器每隔一段时间向资源控制服务器拉取故障实例，按照***实例号分类并排序这批故障实例，通过资源控制服务器重新启动；

（3）某个业务***在故障的部署节点上可能运行着多个模块实例，各个模块在启动时候都有严格的启动顺序和依赖关系，***采用的是一种双迁移队列的方案来解决避免模块重启时的乱序问题，当某个部署节点出现故障宕机时，资源控制服务器会因心跳感知到此事件，把宕机的模块放入待处理故障队列，业务控制服务器会定时向资源控制服务器拉取这些已宕机的模块实例，按业务顺序排列，并将此时间通知依赖于它的模块实例。

按照上述实施例，便可很好地实现本发明。

Claims (9)

1.一种面向服务架构的分布式业务集成***，其特征在于，包括承载服务组件的部署节点集群、监控和管理部署节点集群的资源控制服务器、与该资源控制服务器连接并处理业务***的请求和响应内部事件的业务控制服务器，以及分别连接该业务控制服务器的作为***对外统一的控制接口的Web门户和提供***服务接口查询的服务接入点。

2.根据权利要求1所述的一种面向服务架构的分布式业务集成***，其特征在于，所述部署节点集群包括至少一个部署节点。

3.根据权利要求1或2所述的一种面向服务架构的分布式业务集成***，其特征在于，所述服务组件由一个服务插件和至少一个服务程序组成。

4.一种面向服务架构的分布式业务集成***的应用方法，其特征在于，包括以下步骤：

（a）在分布式业务集成***上安装由配置文件、服务插件以及服务程序集组成的业务***；

（b）服务提供商通过Web门户启动安装的业务***；

（c）用户通过服务接入点访问安装的业务***的服务接口，进行对业务***的访问。

5.根据权利要求4所述的一种面向服务架构的分布式业务集成***的应用方法，其特征在于，所述步骤（a）具体包括：

（a1）用户填写配置文件；

（a2）按照***提示依次上传资源文件后，由业务控制服务器检查资源文件的合法性并存储，生成对应的元数据。

6.根据权利要求4或5所述的一种面向服务架构的分布式业务集成***的应用方法，其特征在于，所述步骤（b）具体包括：

（b1）服务提供商在Web门户上选择已安装的业务***，并发送至业务控制服务器进行处理；

（b2）业务控制服务器解析文件，并将其发送至资源控制服务器，资源控制服务器选择一个部署节点运行服务组件；

（b3）部署节点为服务组件分配地址，实现服务组件的启动及初始化工作，完成后，将启动结果返回；

（b4）重复步骤（b2）和（b3），直至所有服务组件启动成功；

（b5）业务***启动成功后，业务控制服务器通过资源控制服务器向服务接入点注册该业务***的服务接口、***实例号；

（b6）完成后向用户报告此次启动实例的结果以及服务组件的资源分布情况。

7.根据权利要求6所述的一种面向服务架构的分布式业务集成***的应用方法，其特征在于，所述步骤（c）中用户完成对业务***的访问包括以下三种方式：

（c1）服务接入点首先查询自己内存中的服务组件列表，并将查询结果回复给客户；

（c2）服务接入点再查询自己内存中服务组件的服务接口，并将查询结果回复给客户；

（c3）用户完成查询后，调用部署节点上的服务。

8.根据权利要求4或5或7所述的一种面向服务架构的分布式业务集成***的应用方法，其特征在于，还包括对服务组件的自动扩容和/或收缩方法，其步骤如下：

（1）部署节点检测到自身消耗的内存和/或网络中阈值超过预设的上限和/或下限时，向资源控制服务器发送该事件通知；

（2）资源控制服务器将事件转发给业务控制服务器；

（3）业务控制服务器对服务组件进行扩容和/或收缩。

9.根据权利要求4或5或7所述的一种面向服务架构的分布式业务集成***的应用方法，其特征在于，还包括部署节点出现故障宕机后的恢复方法，包括以下步骤：

（1）资源控制服务器检测到部署节点出现故障宕机后，将出现故障宕机的部署节点上运行的服务组件放入故障实例队列内；

（2）业务控制服务器定时从资源控制服务器拉取出现故障宕机的服务组件，并将其重新启动。

Images