CN115202882B - 分布式应用架构和该架构的执行方法 - Google Patents

Abstract

本申请涉及一种分布式应用架构，包括：配置管理模块sse‑config，被配置用于管理和存储来自客户端的配置信息；管理进程模块sse‑service(main)，被配置用于根据服务器的资源使用情况将sse‑service(worker)分配到对应的服务器上；工作进程模块sse‑service(worker)，被配置用于执行业务的各项任务；管理进程模块sse‑cti(main)，被配置用于根据服务器的资源使用情况将sse‑cti(worker)分配到对应的服务器上；以及工作进程模块sse‑cti(worker)，被配置用于根据指令执行与交易所平台的对接；其中，所述sse‑service(main)和sse‑cti(main)还被配置为分别对sse‑service(worker)和sse‑cti(worker)所在的服务器的资源使用情况进行监控，并且当所在的服务器的资源消耗超出警线或者宕机时，自动切换到空闲的服务器。

Description

分布式应用架构和该架构的执行方法

技术领域

本申请涉及分布式应用架构领域，更具体而言，涉及一种用于金融平台的分布式应用架构和其执行方法。

背景技术

在当今社会，随着计算机的普及和功能的强大，越来越多的行业都开始使用计算机来完成其工作。例如，在金融领域各种线上交易所应运而生为客户提供各种金融服务。

出于成本和维护的原因，目前的很多线上交易所都是采取托管模式，即交易所会员(也可称为“租户”、“客户”)的服务都托管在云端，每家会员与交易所都有单独的网关服务。利用云端数据中心强大的处理能力和高效的运维能力，可以同时为众多会员提供服务。

但现有的这种托管模式也存在很多缺点，例如缺少不同会员之间的物理隔离，资源分配不均、存在串数据的风险等问题。

因此，希望能够提供一种能够克服上述缺点和问题，同时能为用户提供更好更强大服务的应用架构和平台。

发明内容

本申请涉及将固定提供交易所报价的后台服务进程，改造成分布式、动态提供多租户报价的后台服务进程。

根据本申请的第一方面，提供了一种分布式应用架构，包括：

配置管理模块sse-config，被配置用于管理和存储来自客户端的配置信息；

管理进程模块sse-service(main)，被配置用于根据服务器的资源使用情况将sse-service(worker)分配到对应的服务器上；

工作进程模块sse-service(worker)，被配置用于执行业务的各项任务；

管理进程模块sse-cti(main)，被配置用于根据服务器的资源使用情况将sse-cti(worker)分配到对应的服务器上；以及

工作进程模块sse-cti(worker)，被配置用于根据指令执行与交易所平台的对接；

其中，所述sse-service(main)和sse-cti(main)还被配置为分别对sse-service(worker)和sse-cti(worker)所在的服务器的资源使用情况进行监控，并且当所在的服务器的资源消耗超出警线或者宕机时，自动切换到空闲的服务器。

根据本申请的第二方面，提供了一种用于执行分布式应用架构的服务的方法，包括：

sse-config接收并存储来自客户端的服务的配置信息；

sse-service(main)根据所述sse-config提供的所述客户端的所述配置信息，并依据服务器的资源使用情况将sse-service(worker)进程分配到对应的服务器上以执行相应的业务任务；

sse-cti(main)根据sse-config提供的所述客户端的所述配置信息，并依据服务器的资源使用情况将sse-cti(worker)进程分配给对应的服务器以执行与交易所平台的对接；

所述sse-service(main)和sse-cti(main)分别对所述sse-service(worker)进程和所述sse-cti(worker)进程所在的服务器的资源使用情况进行监控，并且当所在的服务器的资源消耗超出警线或者宕机时，自动切换到空闲的服务器。

提供本概述以便以简化的形式介绍以下在详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。

附图说明

为了描述可获得本发明的上述和其它优点和特征的方式，将通过参考附图中示出的本发明的具体实施例来呈现以上简要描述的本发明的更具体描述。可以理解，这些附图只描绘了本发明的各典型实施例，并且因此不被认为是对其范围的限制，将通过使用附图并利用附加特征和细节来描述和解释本发明，在附图中：

图1A是一种现有的交易所采用的分布式应用架构的示意图。

图1B、1C和1D分别是图1A中的sse应用架构的三个主要部件sse-service、sse-cti以及sse-config的示例框图。

图2是根据本申请的一个实施例的分布式应用架构的示意图。

图3示出了用于执行根据本申请的一个实施例的分布式应用架构的业务的方法的示例流程图。

具体实施方式

为了便于技术人员更好地理解本申请的方案，在描述本申请之前，先介绍下现有的交易所采用的应用架构。

如图1A所示，示出了一种现有的交易所采用的应用架构。

在所述应用架构方案中，采用了sse架构体系。sse是一种交易所的自动化交易管理平台，其提供了匿名点击、点击成交、协商交易、询价交易等多种交易方式以及与上交所、深交所、中金所的交易接口。而且，sse还将配合交易所的新债平台的建设，通过新债平台接口与交易所新债平台无缝衔接，构建一套完整的债券报价管理系统。

如图所示，所述sse架构体系主要可以分成sse-config、sse-service和sse-cti三个模块。

在图1B、1C和1D分别示出了图1A中的sse应用架构的三个主要部件sse-service、sse-cti以及sse-config的示例框图。

1)sse-service：为交易所的报价引擎系统，如图1B所示，除了常见的接口和数据存储部分之外，其主要还包括：用户管理模块、报价策略模块、基础数据模块以及各个品种报价模块。

其中，用户管理模块主要包括用户的新增、删除、修改，用户权限的管理。

报价策略模块：主要包括实时报价策略的配置和执行、套利监控策略的配置和执行、初始报价策略的配置和执行、衍生品策略的配置和执行。

而基础数据模块可以包括：交易所的债券基本信息、债券利息、交易商信息、交易主体信息、交易员信息

针对交易品种的不同，可以提供不同的报价模块，在附图中的示例报价模块可包括：深交所债券借贷、上交所回售模块、深交所回售模块、上交所做市模块、深交所做市模块、上交所ETF模块、深交所ETF模块、上交所撮合交易模块、深交所撮合交易模块、上交所协商交易模块、深交所协商交易模块。应该理解，上述模块仅仅是举例说明，技术人员可以根据实际的交易需求，增加或减少报价模块。

下面是实现所述sse-service的主要功能的一些示例代码，引入此处作为参考：

上面的示例代码主要演示了如何实现报价和调整。当然所述示例代码仅仅是为了帮助技术人员更好地理解，而非要局限于这些代码。

2)sse-cti：主要负责与交易所平台的对接，例如提供与诸如上交所的交易网关、证通云盘、中证登(上海)、EZSTEP、深交所的交易网关、fxclient、中证登(深圳)等业务的对接服务。如图1C所示，所述对接包括协议解析，即解析上交所、深交所、中金所二进制报文，以及报文转化，即把上交所、深交所、中金所二进制报文解析出来的转换成sse-servie识别的统一报文。

下面是协议转换代码的部分示例，以帮助技术人员更好地理解协议转换。

3)sse-config：被配置用于管理和存储来自客户端的配置信息，以供sse-service和sse-cti使用。如图1D所示，其核心部分主要包括配置管理模块和智能分配模块。这些模块可以实现下述几种处理：

a)将来自客户端的包括服务的IP、端口和内存以及其他信息的配置信息存储到配置中心；

b)从配置中心将相关的配置信息发给sse-service、sse-cti进程；

c)当客户端修改配置时，实时将修改的配置信息传递到sse-service、sse-cti进程以进行更新。

在了解了sse应用架构的上述三个主要部件之后，在图1A的所述应用架构中的其他诸如Nginx、TDGW、EZOES、EZSTEP……，都是本领域常用的网络架构、协议、设备、模块或术语，因此，在此不再对其进行具体描述。

从所述示意架构中不难发现，现有的交易所采用的应用架构存在许多缺陷，例如：

1)后台服务(sse-service)是多家会员共用同一个服务，无法做到每个会员服务的物理隔离。

2)由于多家会员服务在同一个服务上处理，存在资源分配不均或者互相抢占的问题，也无法满足VIP会员需要高性能处理的问题。

3)多家会员服务在同一个服务上处理，存在着串数据的风险。

为了解决现有的交易所采用的应用架构中的这些问题，在图2中示出了一种根据本申请的一个实施例的改进的分布式应用架构的示意图。

如图所示，本方案的分布式应用架构从整体上来看还是延续了传统的应用架构的基本结构，但主要对sse-servicemain和sse-cti两个模块进行了进一步的改进。

具体而言，本方案由下面几部分组成：

1)配置管理模块(sse-config)，被配置用于管理和存储来自客户端的配置信息，以供sse-service和sse-cti使用。在下文中也被称为“配置中心”。具体而言，其主要工作流程可以包括下述几种处理：

a)将来自客户端的包括服务的IP、端口和内存以及其他信息的配置信息存储到配置中心；

b)从配置中心将相关的配置信息发给sse-service(main)、sse-cti(main)进程；

c)当客户端修改配置时，实时将修改的配置信息传递到sse-service(main)、sse-cti(main)进程以进行更新。

2)管理进程模块sse-service(main)和工作进程模块sse-service(worker)：

管理进程模块sse-service(main)和工作进程模块sse-service(worker)是通过例如程序进程实现的功能模块，所述sse-service(main)和sse-service(worker)可以是配套进程(如图所示，一般一个sse-service(main)进程可以同时管理多个sse-service(worker)进程)，它们主要负责交易所业务(服务)的处理。例如示例的sse-service可以为交易所的报价引擎系统，它主要包括：用户管理模块、报价策略模块、基础数据模块、深交所债券借贷、上交所回售模块、深交所回售模块、上交所做市模块、深交所做市模块、上交所ETF模块、深交所ETF模块、上交所撮合交易模块、深交所撮合交易模块、上交所协商交易模块、深交所协商交易模块。

具体而言，所述sse-service(main)主要被配置用于：

a)根据客户端的配置，启动对应的sse-service(worker)进程，所述启动包括根据服务器的资源使用情况将sse-service(worker)进程分配给相对空闲的服务器以均衡负载；

b)监控sse-service(worker)进程是否正常，当发现异常情况时，实时将异常推送给监控模块；

c)实时监听来自客户端的指令，并根据指令对相应的sse-service(worker)进程的配置信息进行调整；

d)监控sse-service(worker)进程所在的服务器资源的使用情况以执行高可用切换，即当所在的服务器资源消耗超出预警线或者宕机时，自动将其切换到空闲的服务器；

e)把相关的配置信息存储在配置中心sse-config。

而所述sse-service(worker)主要被配置用于：

a)监听sse-service(main)发送的指令任务，并进行业务的各项任务的处理。

3)管理进程模块sse-cti(main)和工作进程模块sse-cti(worker)：

管理进程模块sse-cti(main)和工作进程模块sse-cti(worker)是通过例如程序进程实现的功能模块，所述sse-cti(main)和sse-cti(worker)也是配套进程(如图所示，一般一sse-cti(main)进程可以同时管理多个sse-cti(worker)进程)，它们主要负责与交易所平台的对接，例如提供与诸如上交所的交易网关、证通云盘、中证登(上海)、EZSTEP、深交所的交易网关、fxclient、中证登(深圳)等业务的对接服务。

具体而言，所述sse-cti(main)主要被配置用于：

a)根据客户端的配置，启动对应的sse-cti(worker)进程，所述启动包括根据服务器的资源使用情况将sse-cti(worker)进程分配给相对空闲的服务器以均衡负载；

b)监控sse-cti(worker)进程是否工作正常，当发现异常情况时，实时将异常推送给监控模块；

c)实时监听来自客户端的指令，并根据指令对相应的sse-cti(worker)进程的配置信息进行调整；

d)监控sse-cti(worker)进程所在的服务器资源的使用情况以执行高可用切换，即当所在的服务器资源消耗超出警线或者宕机时，自动将其切换到空闲的服务器；

e)把相关的配置信息存储在配置中心sse-config。

而所述sse-cti(worker)主要被配置用于：

a)监听sse-cti(main)发送的指令任务，并根据指令执行对接任务的处理。

从上述内容并结合图2可以理解，与图1A的现有的交易所采用的应用架构相比，本方案至少具有下述改进：

1)所述分布式应用架构开发了sse-service模块，作为交易所报价系统的主服务，以同时向托管的所有客户提供服务，在其中，2个或多个sse-service被设计为多活模式，后台处理服务通过负载均衡将客户机构的服务请求分配到sse-service中处理。

2)针对每家客户都部署一套业务处理sse-service(worker)和交易所接口服务sse-cti(worker)。

具体而言，交易所的后台服务，被分为sse-service(main)和sse-service(worker)两组模块。每家客户分配独立的交易所后台服务进程sse-service(worker)，做到了每个会员服务的物理隔离。

sse-service(main)对多个sse-service(worker)进程进行统一的管理，根据服务器的资源使用情况智能分配worker进程到对应的服务器上，并负责接收和执行来自客户端的指令，例如配置的修改和启停worker。

sse-service(main)对sse-service(worker)进程的运行情况进行监控，对挂掉的worker进行自动的重启，监控worker进程的资源使用情况，当超过设定的资源比例时进行及时预警。

基于上述这些改进，本方案可以根据会员的需求，实现不同会员拥有不同的服务器资源；根据服务器资源的使用情况实现工作进程的智能分配；并且，当发生故障或资源负载不平衡时可以实现高可用的实时切换。

应该理解，所述分布式应用架构中的各个模块和组件可以由硬件、软件或其组合实现。并且所述交易所应用平台的应用架构的这些组成部分彼此可通过有线或无线网络进行数据通信。所述网络包括电缆、数据线、WiFI、蜂窝网络、局域网、广域网以及互联网等等。

下面结合具体的代码示例流程，来描述下所述改进是如何实现的，其中，为了解说简洁，用“main”指代sse-service(main)和/或ssse-cti(main)进程。同样，用“worker”指代sse-service(worker)和/或sse-cti(worker)进程。

a)客户端配置可用的服务器IP和可用的端口范围。

b)配置中心读取可用的服务器IP和可用的端口：

/>

c)把机构的worker服务分配到空闲率最低的服务器上，其中，空闲率＝已用量/总量：

/>

/>

d)配置中心发送启动指令到各个服务器的main进程，以启动对应机构的worker服务：

e)Main进程每隔10秒发送心跳信息给配置中心，如果配置中心1分钟未收到心跳，则判断为这台服务器不可用

f)配置中心重新分配可用的服务器，并发送启动服务指令给相应的Main进程以在新服务器上重新启动服务。

g)Main进程实时监控服务器资源的使用情况，当资源达到预警值时，通知配置中心调整服务器的可用总量。

h)Main进程实时监控worker进程是否可用，不可用则进行重启worker。

/>

利用上述示例的程序代码就可以实现所述worker进程的智能分配以及监控工作中的各worker，并在需要时进行进程的动态切换。

综上所述，在现有的交易所采用的分布式应用架构中，只使用了sse-service和sse-cti来处理所有的业务。而在本申请中，进程被分为main(包括sse-service(main)和sse-cti(main))和worker(包括sse-service(worker)和sse-cti(worker))两种类型。

Main类型的进程主要用于接收配置中心(sse-config)的指令，启动对应的worker进程，并监控woker进程是否存活，如果woker进程停止了，则重新启动worker进程。同时监控各个worker进程的资源使用情况，如果存在资源不均衡的情况，则可以将worker进程切换到空闲的服务器上。

而Worker进程则负责具体的处理，例如sse-service(worker)负责执行交易所业务的处理，而sse-cti(worker)则负责与交易所平台的对接。

借助这两种不同类型的进程，本申请的方案可以提供一种分布式、动态提供交易所多会员交易服务的改进方案，消除了现有的分布式应用架构的缺陷，充分利用了服务器的资源，减少了故障的发生率，从而提高了交易服务的整体效率。

在图3中示出了用于执行根据本申请的一个实施例的分布式应用架构的业务的方法的示例流程图。

如图所示，在步骤302，sse-config(即配置中心)接收并存储来自客户端的服务的IP、端口和内存等配置信息。

随后，在步骤304，sse-service(main)根据sse-config提供的所述客户端的配置信息，并依据服务器的资源使用情况将sse-service(worker)进程分配到对应的服务器上以执行相应的业务任务。

接着，在步骤306，sse-cti(main)根据sse-config提供的所述客户端的配置信息，并依据服务器的资源使用情况将sse-cti(worker)进程分配给对应的服务器以执行与交易所平台的对接。

并且，在步骤308，所述sse-service(main)和sse-cti(main)分别对sse-service(worker)和sse-cti(worker)进程所在的服务器的资源使用情况进行监控，并且当所在的服务器的资源消耗超出警线或者宕机时，自动将对应的worker进程切换到空闲的服务器。

上述流程仅仅是分布式应用架构的服务的基本流程，所述流程实际上还可以包括监控worker工作的异常、监控来自worker的心跳，以及根据来自客户端的配置信息修改来重新配置worker等等步骤，具体请参考有关图2的内容和示例代码，在此不再累述。

虽然以上描述了不同的实施例，但应当理解的是它们只是作为示例而非限制。(诸)相关领域的技术人员将领会，在不偏离如所附权利要求书所定义的本发明的精神和范围的情况下，可以在形式和细节方面进行各种修改。因此，此处所公开的本发明的宽度和范围不应被上述所公开的示例性实施例所限制，而应当仅根据所附权利要求书及其等同替换来定义。

Claims (8)

1.一种分布式应用架构系统，包括：

配置管理模块，被配置用于管理和存储来自客户端的配置信息；

报价管理进程模块，被配置用于根据服务器的资源使用情况将报价工作进程分配到对应的服务器上；

报价工作进程模块，被配置用于执行业务的各项任务；

对接管理进程模块，被配置用于根据服务器的资源使用情况将对接工作进程分配到对应的服务器上；以及

对接工作进程模块，被配置用于根据指令执行与交易所平台的对接；

其中，所述报价管理进程模块和所述对接管理进程模块还被配置为分别对所述报价工作进程模块的进程和所述对接工作进程模块的进程所在的服务器的资源使用情况进行监控，并且当所在的服务器的资源消耗超出警线或者宕机时，自动切换到空闲的服务器。

2.如权利要求1所述的分布式应用架构系统，其特征在于，所述配置管理模块进一步被配置用于：

存储来自所述客户端的包括服务的IP、端口、内存以及其他信息的配置信息；

将相关的所述配置信息发给所述报价管理进程模块和所述对接管理进程模块；

当所述客户端修改配置时，实时将修改的配置信息传递到所述报价管理进程模块和所述对接管理进程模块以进行更新。

3.如权利要求1所述的分布式应用架构系统，其特征在于，所述报价管理进程模块还被配置用于：

监控所述报价工作进程模块是否正常，当发现异常情况时，实时将异常推送给监控模块；

实时监听来自所述客户端的指令，并根据所述指令对相应的报价工作进程模块的配置信息进行调整；

把相关的配置信息存储在所述配置管理模块。

4.如权利要求1所述的分布式应用架构系统，其特征在于，所述对接管理进程模块还被配置用于：

监控所述对接工作进程模块是否工作正常，当发现异常情况时，实时将异常推送给监控模块；

实时监听来自所述客户端的指令，并根据所述指令对相应的对接工作进程模块的配置信息进行调整；

把相关的配置信息存储在所述配置管理模块。

5.如权利要求1所述的分布式应用架构系统，其特征在于，在所述分布式应用架构中，针对每家客户都部署一套报价工作进程模块和对接工作进程模块，以实现每个客户服务的物理隔离。

6.如权利要求3所述的分布式应用架构系统，其特征在于，所述报价管理进程模块还被配置为根据来自所述客户端的指令，启停报价工作进程模块。

7.如权利要求3所述的分布式应用架构系统，其特征在于，所述报价管理进程模块还被配置为监控所述报价工作进程模块是否正常，并对挂掉的报价工作进程进行自动重启。

8.一种用于执行分布式应用架构的业务的方法，包括：

配置管理模块接收并存储来自客户端的服务的配置信息；

报价管理进程模块根据所述配置管理模块提供的所述客户端的所述配置信息，并依据服务器的资源使用情况将报价工作进程分配到对应的服务器上以执行相应的业务任务；

对接管理进程模块根据所述配置管理模块提供的所述客户端的所述配置信息，并依据服务器的资源使用情况将对接工作进程分配给对应的服务器以执行与交易所平台的对接；以及

所述报价管理进程模块和所述对接管理进程模块分别对所述报价工作进程模块的进程和所述对接工作进程模块的进程所在的服务器的资源使用情况进行监控，并且当所在的服务器的资源消耗超出警线或者宕机时，自动切换到空闲的服务器。