CN115150406B - 跨数据中心分布式esb配置管理系统 - Google Patents

Abstract

本发明涉及通信技术领域，尤其涉及一种跨数据中心分布式ESB配置管理系统，包括：消息推送集群和至少两个数据中心；每个数据中心中包括管控平台、配置中心和边车；消息推送集群与每个数据中心中的管控平台建立有通信连接，用于建立各个管控平台之间的消息订阅和消息发布；可以解决传统的ESB不支持跨数据中心的配置管理，无法实现在一个数据中心的管理其它数据中心中分布式ESB的配置，导致分布式ESB配置效率较低的问题。可以提高分布式ESB配置效率。

Description

跨数据中心分布式ESB配置管理系统

技术领域

本发明涉及通信技术领域，尤其涉及跨数据中心分布式ESB配置管理系统。

背景技术

企业服务总线（Enterprise Service Bus，ESB）：是实现系统间集成和互联互通的一个技术架构，可以理解为是一种消息和服务集成的中间件平台。具体地，ESB是构建基于面向服务体系结构(service-oriented architecture，SOA)解决方案时所使用基础架构的关键部分，是由中间件技术实现并支持SOA的一组基础架构功能。ESB支持异构环境中的服务、消息、以及基于事件的交互，并且具有适当的服务级别和可管理性。简而言之，ESB提供了连接企业内部及跨企业间新的和现有软件应用程序的功能，以一组丰富的功能启用管理和监控应用程序之间的交互。在SOA分层模型中，ESB用于组件层以及服务层之间，它能够通过多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务。

目前，在企业中会新建多个数据中心，为保证业务的连续性，同一业务会在至少两个数据中心部署，以使两个数据中心中业务同时提供服务。传统ESB无法下沉到业务进程，无法做到分布式部署，ESB居多是在一个数据中心进行路由寻址，无法做到多个数据中心寻址。

然而，传统的ESB不支持跨数据中心的配置管理，无法实现在一个数据中心的管理其它数据中心中分布式ESB的配置，导致分布式ESB配置效率较低的问题。

发明内容

本申请提供了跨数据中心分布式ESB配置管理系统，可以解决传统的ESB不支持跨数据中心的配置管理，无法实现在一个数据中心的管理其它数据中心中分布式ESB的配置，导致分布式ESB配置效率较低的问题。本申请提供如下技术方案：

第一方面，本申请提供了一种跨数据中心分布式ESB配置管理系统，包括：消息推送集群和至少两个数据中心；每个所述数据中心中包括管控平台、配置中心和边车；所述消息推送集群与每个所述数据中心中的管控平台建立有通信连接，用于建立各个所述管控平台之间的消息订阅和消息发布；所述管控平台，用于确定在所述配置中心中注册的其它数据中心的业务应用；获取业务应用对应的配置信息；基于所述配置信息生成配置消息；通过所述消息推送集群将所述配置消息发送至所述其它数据中心的管控平台，以使所述其它数据中心的管控平台在接收到所述配置消息后，将所述配置消息对应的配置信息发送至所述其它数据中心的配置中心；所述配置中心，用于在接收所述配置信息后，将所述配置信息发送给所述应用业务对应的边车。

可选地，每个所述数据中心还包括服务提供业务和服务调用业务；所述边车与所述服务提供业务或所述服务调用业务一一对应。

可选地，所述服务提供业务用于为所述至少两个数据中心中的服务调用业务提供服务；相应地，所述服务调用业务用于调用所述至少两个数据中心中的服务提供业务。

可选地，所述配置中心还用于接收所述服务提供业务的状态信息。

可选地，每个所述数据中心还包括监控代理，所述监控代理用于监控所述配置中心；在所述监控代理监控到所述配置中心接收到异常状态信息的情况下，所述监控代理还用于将所述异常状态信息同步至所述管控平台；所述管控平台还用于，分析所述异常状态信息，确定所述异常状态信息对应的目标服务提供业务；基于所述目标服务提供业务确定目标数据中心，所述目标数据中心中包括所述目标服务提供业务对应的目标服务调用业务；通过所述消息推送集群发送摘除流量消息至所述目标数据中心的管控平台，以使所述目标数据中心的管控平台在接收到所述摘除流量消息后，将所述目标服务调用业务对应的所述目标服务提供业务的流量摘除。

可选地，所述管控平台还用于在所述管控平台启动时，确定一个定时器；在所述定时器触发的情况下，所述管控平台，还用于检查是否存在未完成消息；在存在所述未完成消息的情况下，通过所述消息推送集群将所述未完成消息发送至所述其它数据中心的管控平台，以使所述其它数据中心的管控平台在接收到所述未完成消息后进行处理；将所述未完成消息的状态设置为已完成。

可选地，所述配置中心还用于接收所述业务应用的注册信息，以在所述配置中心中注册所述业务应用。

可选地，所述系统还包括负载均衡器；所述负载均衡器用于接收访问者的访问请求；分析所述访问请求，得到所述访问请求中的访问者的地域信息；将所述访问请求转发至所述地域信息对应的数据中心的管控平台。

可选地，所述监控代理可以为Agent组件。

可选地，所述消息推送集群可以为Redis集群。

本申请的有益效果在于：通过设置消息推送集群和至少两个数据中心；每个所述数据中心中包括管控平台、配置中心和边车；消息推送集群与每个所述数据中心中的管控平台建立有通信连接，用于建立各个管控平台之间的消息订阅和消息发布；管控平台，用于确定在配置中心中注册的其它数据中心的业务应用；获取业务应用对应的配置信息；基于配置信息生成配置消息；通过消息推送集群将配置消息发送至其它数据中心的管控平台，以使其它数据中心的管控平台在接收到配置消息后，将配置消息对应的配置信息发送至其它数据中心的配置中心；配置中心，用于在接收配置信息后，将配置信息发送给应用业务对应的边车；可以解决传统的ESB不支持跨数据中心的配置管理，无法实现在一个数据中心的管理其它数据中心中分布式ESB的配置，导致分布式ESB配置效率较低的问题；可以将其它数据中心中的业务应用在当前数据中心中的配置中心注，通过当前数据中心的管控平台生成其它数据中心中的业务应用的配置消息，并通过消息推送集群发送至其它数据中心的管控平台，可以实现在一个数据中心的管理其它数据中心中分布式ESB的配置，进而提高分布式ESB的配置效率。

另外，通过管控平台设置定时器，在触发定时器后，检查未完成消息，在存在未完成消息的情况下，通过消息推送集群将未完成消息发送至对应的数据中心的管控平台处理，可以保证配置消息全部处理，进而保证分布式ESB配置能够正常完成。

另外，通过监控代理监控配置中心接收的服务提供业务的状态信息，在监控到异常状态信息的情况下，将异常状态信息发送至管控中心处理，这样可以保证服务调用业务能够正常运行。

另外，由于采用了边车的模式来处理被代理服务的请求，解决了集中式处理所需要的大量服务器资源以及部署这些服务所需要的人力资源和维护成本。

另外，由于采用了分布式架构设计边车的方式，每个服务的边车只处理自己对应的服务，可以提升处理性能。

附图说明

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

图1是本申请的一个实施例提供的跨数据中心分布式ESB配置管理系统的结构示意图；

图2是本申请的一个实施例提供的跨数据中心分布式ESB配置管理方法的流程图；

图3是本申请的一个实施例提供的另一个跨数据中心分布式ESB配置管理方法的流程图。

具体实施方式

下面将结合附图对本申请的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。

在申请中，在未作相反说明的情况下，使用的方位词如“上、下、顶、底”通常是针对附图所示的方向而言的，或者是针对部件本身在竖直、垂直或重力方向上而言的；同样地，为便于理解和描述，“内、外”是指相对于各部件本身的轮廓的内、外，但上述方位词并不用于限制本申请。

首先，对于本申请涉及的若干名词进行介绍。

企业服务总线（Enterprise Service Bus，ESB）：是实现系统间集成和互联互通的一个技术架构，可以理解为是一种消息和服务集成的中间件平台。具体地，ESB是构建基于面向服务体系结构(service-oriented architecture，SOA)解决方案时所使用基础架构的关键部分，是由中间件技术实现并支持SOA的一组基础架构功能。ESB支持异构环境中的服务、消息、以及基于事件的交互，并且具有适当的服务级别和可管理性。简而言之，ESB提供了连接企业内部及跨企业间新的和现有软件应用程序的功能，以一组丰富的功能启用管理和监控应用程序之间的交互。在SOA分层模型中，ESB用于组件层以及服务层之间，它能够通过多种通信协议连接并集成不同平台上的组件将其映射成服务层的服务。

ESB主要是为了解决多个应用系统互联所面临的复杂性，降低集成和维护成本。比如：医疗业务系统分为很多个系统，包括HIS、LIS、EMR等等，如果这些业务系统是由多个开发商开发的，可能会有构建语言不同、通信协议不同、数据传输格式不同等问题，将这些系统用一条线串起来即可通过ESB实现。ESB需要保证多个应用系统的服务接入，协议转换，提供可靠的消息传输，数据格式转换，基于内容路由等功能。

ESB的服务接入方式包括简单对象访问协议（Simple Object Access Protocol，SOAP）面向服务的架构。其中，SOAP是交换数据的一种协议规范，是一种轻量的、简单的、基于标准通用标记语言（Extensible Markup Language，XML）下的一个子集的协议，它被设计成在WEB上交换结构化的和固化的信息。

服务网格(SERVICE MESH)：用于控制应用的不同部分之间如何共享数据。与用于管理此类通信的其他系统不同，服务网格内置于应用程序中的专用基础架构层。它使每个service实例之间的通信更加流畅、可靠和迅速。服务网格提供了诸如服务发现、负载均衡、加密、身份鉴定、授权、支持熔断器模式( Circuit Breaker Pattern )以及其他一系列功能。

服务网格的实现通常是提供一个代理实例—边车（sidecar）。sidecar 包含在每一个service 之中。sidecar 主要处理 service 间的通信、监控、以及以从服务本体中抽象出来的安全方面的部分。

Sidecar用到软件架构中，Sidecar应用是连接到父应用，并为其扩展或增强功能。Sidecar应用于主应用程序松耦合。

Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

数据中心(Data Center)顾名思义就是数据的中心，是处理和存储海量数据的地方。

如图1所示，本申请的实施例提供的跨数据中心分布式ESB配置管理系统的结构示意图，根据图1可知，该系统至少包括：消息推送集群110和至少两个数据中心120。

其中，每个数据中心120包括管控平台130、配置中心140和边车150。

本实施例中，消息推送集群110与每个数据中心120中的管控平台130建立有通信连接，用于建立各个管控平台130之间的消息订阅和消息发布。

可选地，消息推送集群110可以为Redis集群。

每个数据中心120中的管控平台130与所属数据中心120中的配置中心140通信连接；每个配置中心140还与所属数据中心120中的边车150通信连接。

管控平台130主要作用是协调器的作用，具体协调多个数据中心120中多活应用的流量分发，默认流量模型由管控平台120下发至配置中心，由其推送进行差异化推送到各个边车150上。

配置中心140主要用于进行数据中心120中边车150的注册，以及供管控平台130下发配置信息，最终由配置中心140推送至所有边车150上，包含下游应用订阅所有服务提供者信息、流量切分数据、接入接出协议模型。

边车150可视为一个根据不同下游应用定制版ESB，将ESB功能下沉至每个边车150上，边车150上实现了当前下游的接入协议、报文、编码转换，且根据报文内容进行路由，通常下游服务调用ESB是不知道具体上游地址具体是谁，下游不需要知道具体上游地址，由边车150根据报文信息分析出上游地址，并最终将数据调用到上游，在调用过程中记录所有信息并上报至可观测性平台，如链路跟踪和日志平台。边车150也会根据管控平台130设置的流量模型将流量在本数据中心120和外部数据中心120切换。

本实施例中，每个数据中心120还包括服务提供业务和服务调用业务；其中，边车150与服务提供业务或服务调用业务一一对应。

本实施例中，每个数据中心120中还包括监控代理160，监控代理160与配置中心140和管控平台130均建立有通信连接。

监控代理160用于监听配置中心140、边车150及业务进程的健康状态，配置中心140实现了主动及被动的健康检查。当某个数据中心120的应用异常时，监控代理160将信息上报至管控平台130，由管控平台130协调数据中心流量，及时将流量倒流至其它数据中心120的相同应用上，保证业务的连续性。

可选地，监控代理160可以为Agent组件。

另外，本实施例提供的系统还包括负载均衡器170；负载均衡器170用于接收访问者的访问请求；分析访问请求得到访问请求中的访问者的地域信息；将访问请求转发至地域信息对应的数据中心120的管控平台130。

下面对本系统的跨数据中心分布式ESB配置管理方法进行介绍。

如图2所示，本申请的实施例提供的一个跨数据中心分布式ESB配置管理系统的配置管理方法，该方法至少包括以下几个步骤：

步骤201，管控平台确定在配置中心中注册的其它数据中心的业务应用。

本实施例中，每个数据中心中的配置中心用于接收业务应用的注册信息，以在配置中心中注册业务应用。

具体地，每个配置中心接收的注册信息包括本数据中心中的业务应用的注册信息和其它数据中心中的业务应用的注册信息。

其中，业务应用是指服务调度业务对应的应用。

本实施例中，每个数据中心包括服务提供业务和服务调用业务，边车与服务提供业务或服务调用业务一一对应。换言之，一个边车对应一个服务提供业务，或者，一个边车对应一个服务调用业务。

服务提供业务用于为至少两个数据中心中的服务调用业务提供服务；相应地，服务调用业务用于调用至少两个数据中心中的服务提供业务。

另外，为了保证服务调用业务能够正常运行，还需要对为服务调用业务提供服务的服务提供业务状态进行监控，具体包括以下几个步骤：

步骤S11，通过配置中心接收服务提供业务的状态信息。

步骤S12，通过监控代理监控配置中心。

步骤S13，在监控代理监控到配置中心接收到异常状态信息的情况下，通过监控代理将异常状态信息同步至管控平台。

其中，监控代理、配置中心和管控平台属于同一个数据中心。

比如，参考图1，以数据中心1为例，配置中心与对应服务提供业务的边车通信连接，通过此通信连接接收服务提供业务的状态信息；监控代理对配置中心进行监控，在配置中心接收到异常状态信息的情况下，将异常状态信息发送管控平台。

步骤S14，通过管控平台分析异常状态信息，确定异常状态信息对应的目标服务提供业务。

步骤S15，管控平台基于目标服务提供业务确定目标数据中心。

其中，目标数据中心中包括目标服务提供业务对应的目标服务调用业务。

步骤S16，管控平台通过消息推送集群发送摘除流量消息至目标数据中心的管控平台，以使目标数据中心的管控平台在接收到摘除流量消息后，将目标服务调用业务对应的目标服务提供业务的流量摘除。

比如：参考图1，以数据中心1和数据中心2为例，数据中心2中的服务调用业务同时调用数据中心1和数据中心2中的服务提供业务，数据中心1和数据中心2中的服务提供业务分别为数据中心2中的服务调用业务提供50%的流量；在数据中心1中的服务提供业务出现异常的情况下，由数据中心1中的管控平台摘除数据中心1中的服务提供业务的流量，此时，数据中心2中的服务调用业务由数据中心2中的服务提供业务提供100%的流量。

步骤202，管理平台获取业务应用对应的配置信息。

其中，配置信息包括服务提供业务的信息和策略信息，策略信息用于指示配置的策略，例如黑名单策略、白名单策略、流量转发策略等。

步骤203，管理平台基于配置信息生成配置消息。

步骤204，管理平台通过消息推送集群将配置消息发送至其它数据中心的管控平台。

另外，在管控平台关闭时，可能存在未完成消息，则在管控平台再次启动后，需要对检查是否存在未完成消息，在存在未完成消息的情况下，将未完成消息发送至未完成消息对应的管控平台进行处理。

具体地，在管控平台启动时，确定一个定时器；在定时器触发的情况下，管控平台还用于检查是否存在未完成消息；在存在未完成消息的情况下，通过消息推送集群将未完成消息发送至其它数据中心的管控平台，以使其它数据中心的管控平台在接收到未完成消息后进行处理；将未完成消息的状态设置为已完成。

比如：参考图3，以数据中心1和数据中心2为例，数据中心1中的管控平台在启动后确定一个定时器；在定时器触发的情况下，检查是否存在未完成消息；发送未完成消息至消息推送集群；消息推送集群将未完成消息发送至数据中心2的管控平台；数据中心2的管控平台接收未完成消息并处理；数据中心1中的管控平台将未完成消息的状态设置为已完成。

步骤205，其它数据中心的管控平台在接收到配置消息后，将配置消息对应的配置信息发送至其它数据中心的配置中心，以使配置中心在接收配置信息后，将配置信息发送给应用业务对应的边车。

综上所述，本实施例提供的基于服务网格技术实现分布式ESB场景下的应用多活系统，通过设置消息推送集群和至少两个数据中心；每个所述数据中心中包括管控平台、配置中心和边车；消息推送集群与每个所述数据中心中的管控平台建立有通信连接，用于建立各个管控平台之间的消息订阅和消息发布；管控平台，用于确定在配置中心中注册的其它数据中心的业务应用；获取业务应用对应的配置信息；基于配置信息生成配置消息；通过消息推送集群将配置消息发送至其它数据中心的管控平台，以使其它数据中心的管控平台在接收到配置消息后，将配置消息对应的配置信息发送至其它数据中心的配置中心；配置中心，用于在接收配置信息后，将配置信息发送给应用业务对应的边车；可以解决传统的ESB不支持跨数据中心的配置管理，无法实现在一个数据中心的管理其它数据中心中分布式ESB的配置，导致分布式ESB配置效率较低的问题；可以将其它数据中心中的业务应用在当前数据中心中的配置中心注，通过当前数据中心的管控平台生成其它数据中心中的业务应用的配置消息，并通过消息推送集群发送至其它数据中心的管控平台，可以实现在一个数据中心的管理其它数据中心中分布式ESB的配置，进而提高分布式ESB的配置效率。

另外，通过管控平台设置定时器，在触发定时器后，检查未完成消息，在存在未完成消息的情况下，通过消息推送集群将未完成消息发送至对应的数据中心的管控平台处理，可以保证配置消息全部处理，进而保证分布式ESB配置能够正常完成。

另外，通过监控代理监控配置中心接收的服务提供业务的状态信息，在监控到异常状态信息的情况下，将异常状态信息发送至管控中心处理，这样可以保证服务调用业务能够正常运行。

另外，由于采用了边车的模式来处理被代理服务的请求，解决了集中式处理所需要的大量服务器资源以及部署这些服务所需要的人力资源和维护成本。

另外，由于采用了分布式架构设计边车的方式，每个服务的边车只处理自己对应的服务，可以提升处理性能。

以上所述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

显然，上述所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下，可以做出其它不同形式的变化或变动，都应当属于本申请保护的范围。

Claims (10)

1.一种跨数据中心分布式企业服务总线（ESB）配置管理系统，其特征在于，所述系统包括：消息推送集群和至少两个数据中心；

每个所述数据中心中包括管控平台、配置中心和边车；

所述消息推送集群与每个所述数据中心中的管控平台建立有通信连接，用于建立各个所述管控平台之间的消息订阅和消息发布；

所述管控平台，用于确定在所述配置中心中注册的其它数据中心的业务应用；获取业务应用对应的配置信息；基于所述配置信息生成配置消息；通过所述消息推送集群将所述配置消息发送至所述其它数据中心的管控平台，以使所述其它数据中心的管控平台在接收到所述配置消息后，将所述配置消息对应的配置信息发送至所述其它数据中心的配置中心；

所述配置中心，用于在接收所述配置信息后，将所述配置信息发送给所述业务应用对应的边车。

2.根据权利要求1所述的系统，其特征在于，每个所述数据中心还包括服务提供业务和服务调用业务；所述边车与所述服务提供业务或所述服务调用业务一一对应。

3.根据权利要求2所述的系统，其特征在于，所述服务提供业务用于为所述至少两个数据中心中的服务调用业务提供服务；

相应地，所述服务调用业务用于调用所述至少两个数据中心中的服务提供业务。

4.根据权利要求2所述的系统，其特征在于，所述配置中心还用于接收所述服务提供业务的状态信息。

5.根据权利要求4所述的系统，其特征在于，每个所述数据中心还包括监控代理，所述监控代理用于监控所述配置中心；

在所述监控代理监控到所述配置中心接收到异常状态信息的情况下，所述监控代理还用于将所述异常状态信息同步至所述管控平台；

所述管控平台还用于，分析所述异常状态信息，确定所述异常状态信息对应的目标服务提供业务；基于所述目标服务提供业务确定目标数据中心，所述目标数据中心中包括所述目标服务提供业务对应的目标服务调用业务；通过所述消息推送集群发送摘除流量消息至所述目标数据中心的管控平台，以使所述目标数据中心的管控平台在接收到所述摘除流量消息后，将所述目标服务调用业务对应的所述目标服务提供业务的流量摘除。

6.根据权利要求1所述的系统，其特征在于，所述管控平台还用于在所述管控平台启动时，确定一个定时器；

在所述定时器触发的情况下，所述管控平台，还用于检查是否存在未完成消息；在存在所述未完成消息的情况下，通过所述消息推送集群将所述未完成消息发送至所述其它数据中心的管控平台，以使所述其它数据中心的管控平台在接收到所述未完成消息后进行处理；将所述未完成消息的状态设置为已完成。

7.根据权利要求1所述的系统，其特征在于，所述配置中心还用于接收所述业务应用的注册信息，以在所述配置中心中注册所述业务应用。

8.根据权利要求1所述的系统，其特征在于，所述系统还包括负载均衡器；

所述负载均衡器用于接收访问者的访问请求；分析所述访问请求，得到所述访问请求中的访问者的地域信息；将所述访问请求转发至所述地域信息对应的数据中心的管控平台。

9.根据权利要求5所述的系统，其特征在于，所述监控代理可以为Agent组件。

10.根据权利要求1至9任一所述的系统，其特征在于，所述消息推送集群可以为Redis集群。

Images