CN112882691B - 一种基于宏服务的业务服务方法及系统 - Google Patents

Abstract

本发明涉及一种基于宏服务的业务服务方法及系统，以一笔金融业务在一个事务内完成的高内聚原则，形成若干子系统，进而在宏服务架构下进行子系统规划及服务封装，子系统按业务领域进行划分，原则上无跨节点事务访问，即解决了单体应用框架的扩展性问题，集群架构的部署灵活性问题，满足分布式架构的成本低廉，可用性、可扩展性更好的特性，同时也解决了传统分布式应用架构对业务强一致性保证的难点。

Description

一种基于宏服务的业务服务方法及系统

技术领域

本发明涉及分布式系统技术领域，尤其涉及一种基于宏服务的业务服务方法及系统。

背景技术

银行核心业务系统是银行应用系统架构中最核心的业务服务系统，承载银行重要的产品服务能力和关键基础业务，包括存款、贷款、支付、客户信息、会计核算等业务。以往中大型银行的核心业务系统通常基于IBM主机系统建设，但主机集中式技术架构缺乏水平可扩展能力，难以满足互联网经济时代银行IT系统的高容量和资源动态分配的要求，核心业务系统普遍尝试进行基于X86平台的分布式架构转型，其在扩展性、成本、自主可控等方面优势明显。

分布式核心系统应用架构的通常做法有以下两种:

1.按照业务领域将应用系统进行纵向拆分，将原有单体核心业务系统，拆分为独立的负债系统(对公/对私)、资产系统(对公/对私)、支付系统、客户信息系统、公共业务系统等，分布式架构模式采用SOA模式(基于企业服务总线响应各系统间交互)或微服务模式(各系统通过RPC调用服务交互)。

2.采用分布式集群应用架构，既每个应用节点同构部署，应用集群前通过F5或软负载实现交易的负载均衡。

以上分布式核心应用架构模式，分别存在以下不足：

1、应用系统拆分后的交易一致性问题：交易强一致性是银行核心业务系统的关键要求，交易一致性要求远高于电商平台和其他互联网应用。银行核心业务系统具有高内聚特性，例如一笔贷款放款交易通常涉及到资产系统(贷款账户处理)、负债系统(存款账户处理)、客户信息系统等。应用系统拆分后，一笔业务需要调用多个系统节点的服务，并且需要保证强一致性，这个问题对系统设计带来了很高的复杂度。

2、应用系统拆分后交易性能问题：分布式拆分后，原来一笔交易由一个节点完成，变成了需要多个节点协同完成，各节点通过RPC或者消息传递完成进程间通讯机制,增加了网络延时,整个交易链路变长，单笔交易响应时间降低。

3、集群架构的部署灵活性问题：a.由于集群架构采用应用节点同构，任何一个业务需求交付都需要在所有节点进行部署，造成了部署流程和时间长。b.随着业务的不断发展，每个节点的应用包会不断增长，构建时间也会相应变长。c.每个业务模块的规模不同，同构部署不利于计算和存储资源的有效利用。

发明内容

为解决现有技术的不足，本发明提出一种基于宏服务的业务服务方法及系统，以一笔金融业务在一个事务内完成的高内聚原则，形成若干子系统，进而在宏服务架构下进行子系统规划及服务封装，子系统按业务领域进行划分，原则上无跨节点事务访问，即解决了单体应用框架的扩展性问题，集群架构的部署灵活性问题，满足分布式架构的成本低廉，可用性、可扩展性更好的特性，同时也解决了传统分布式应用架构对业务强一致性保证的难点。

为实现以上目的，本发明所采用的技术方案包括：

一种基于宏服务的业务服务方法，其特征在于，包括：

子系统规划，依照业务领域不同将业务服务划分为若干子系统；

组件建设，将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的组件；

组件调度策略制定，将不同组件之间的调度关系整合为统一的组件调度策略；

子系统封装，依照子系统规划将对应的组件封装为子系统；

分布式架构建设，将一个或多个子系统组合为分布式架构部署至节点提供业务服务。

进一步地，所述组件建设包括：

依照功能的类型区别，将业务服务中的不同独立功能分别各自建设为服务组件、单元组件或公共函数组件；

所述服务组件的属性定义对应业务服务请求，接口定义对应业务服务请求需要调用的单元组件；

所述单元组件的属性定义对应业务服务功能，接口定义对应需求该业务服务功能的服务组件；

所述公共函数组件的属性定义对应只读请求，接口定义对应该只读请求调取数据所需要访问的服务组件和/单元组件。

进一步地，所述子系统封装包括：

依据业务服务请求将对应的服务组件、单元组件和公共函数组件封装为模块；

依照子系统规划将对应的若干模块封装为子系统。

进一步地，所述子系统封装还包括：

将多个子系统均需要使用的服务组件、单元组件和公共函数组件封装为公共服务模块，并使用公共服务模块参与子系统封装操作。

进一步地，所述子系统采用容器化部署。

进一步地，所述服务组件、单元组件和公共函数组件均为互相不具备直接耦合关系的独立组件。

进一步地，所述组件调度策略制定包括整合服务组件的对应业务服务请求。

本发明还涉及一种基于宏服务的业务服务系统，其特征在于，包括：

子系统规划部件，用于依照业务领域不同将业务服务划分为若干子系统；

组件建设部件，用于将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的服务组件、单元组件或公共函数组件；

组件调度策略制定部件，用于将不同组件之间的调度关系整合为统一的组件调度策略；

子系统封装部件，用于依据业务服务请求将对应的服务组件、单元组件和公共函数组件封装为模块，并依照子系统规划将对应的若干模块封装为子系统；

分布式架构建设部件，用于将一个或多个子系统组合为分布式架构部署至节点提供业务服务。

本发明还涉及一种计算机可读存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述的方法。

本发明还涉及一种电子设备，其特征在于，包括处理器和存储器；

所述存储器，用于存储服务组件、单元组件和公共函数组件；

所述处理器，用于通过调用服务组件、单元组件和公共函数组件，执行上述的方法。

本发明的有益效果为：

采用本发明所述基于宏服务的业务服务方法及系统，有效提升了银行业务系统的分布式应用架构能力，使得按子系统交付和部署更加灵活，高可用性能力更强。保证了银行业务交易在分布式架构模式下的一致性和处理效率。

附图说明

图1为本发明基于宏服务的业务服务方法流程示意图。

图2为本发明基于宏服务的业务服务系统结构示意图。

具体实施方式

为了更清楚的理解本发明的内容，将结合附图和实施例详细说明。

相对于微服务，宏服务不再只是完成一件事，而是提供一组服务，使其服务于一项业务领域。每一个业务功能由一各宏服务节点的一只服务独立完成，而不涉及多个服务节点的服务调用。

如图1所示为本发明基于宏服务的业务服务方法流程示意图，主要包括以下步骤：

子系统规划，依照业务领域不同将业务服务划分为若干子系统；

组件建设，将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的服务组件、单元组件或公共函数组件，其中，服务组件的属性定义对应业务服务请求、接口定义对应业务服务请求需要调用的单元组件，单元组件的属性定义对应业务服务功能、接口定义对应需求该业务服务功能的服务组件，公共函数组件的属性定义对应只读请求、接口定义对应该只读请求调取数据所需要访问的服务组件和/单元组件；

组件调度策略制定，将不同组件之间的调度关系整合为统一的组件调度策略；

子系统封装，依据业务服务请求将对应的服务组件、单元组件和公共函数组件封装为模块，再依照子系统规划将对应的若干模块封装为子系统，优选的，将多个子系统均需要使用的服务组件、单元组件和公共函数组件封装为公共服务模块，并使用公共服务模块参与子系统封装操作；

分布式架构建设，将一个或多个子系统组合为分布式架构部署至节点提供业务服务，优选的，采用容器化部署子系统及其组合。

在执行上述方法过程中，整个系统应用逻辑架构面向业务领域采用层次化模块化设计方法，层次化设计的目标是逻辑层次清晰，降低功能模块间的耦合性，增强可维护性和功能扩展性，按高内聚、低耦合的原则确定模块的功能边界和模块间的关系，从功能层次间解耦、业务子系统间解耦。业务抽象层次从高到底分为子系统、模块、组件三层。子系统按照业务领域进行划分；模块是将子系统内的耦合紧密的一部分子功能划分为模块；组件是模块内具体功能的实现抽象。从开发角度子系统和模块都是逻辑组织单元，组件是具体实现的物理单元。

具体至银行业务领域，由于银行业务的高内聚特性，通常某个子系统的交易会依赖于另一个子系统的组件功能，所以宏服务架构非常重要的一个设计是抽象出一个公共业务层模块，基于对整个系统组件化设计后的业务组件依赖关系，将各子系统被其他子系统所依赖的组件定义为对外访问，这些组件形成相对稳定的公共服务模块(按模块可划分为多个公共服务模块)。每一个子系统在构建时，将其依赖的公共服务模块进行引入打包构建出可独立运行的子系统程序包。优选的，子系统基于云原生平台开发并使用容器化部署，每个子系统支持独立开发、测试、发布，各子系统服务独立运行，资源独立分配。

对于子系统规划、封装过程的代码工程管理，相关的代码通过一个工程项目进行管理，工程应该依据功能模块划分，整个系统的代码工程结构和依赖关系清晰明确。宏服务子系统的应用工程应该于应用模块一一对应，一个应用模块包含一个内部工程和公共工程。各应用模块的内部工程相互独立。应用公共工程可别其他应用模块的工程依赖。工程间的依赖必须采取最小依赖原则，不允许定义多余无关依赖或图便利直接使用全依赖方式进行依赖配置。工程的依赖管理可通过成熟的maven或gradle工具进行管理。随着业务的发展和变化，应用架构和组件依赖关系也会发生变化，工程管理上应该能够灵活的支持工程的新增、修改、合并和拆分。

对于组件建设步骤，其基本原则是业务功能单一明确、具备复用价值、粒度适中。复杂的业务功能可以通过组件的组装来实现。组件技术的设计原则是提高规范性、降低耦合度，不断地分层、不断地抽象、不断地重构。设计出来的组件高内聚，低耦合，可重用，维护性好，单独开发，单独编译，单独测试。组件与组件之间不存在直接的耦合关系。同时，组件与组件之间又并非绝对的独立。组件经过组装后可以与其他的组件进行业务上的交互。组件可以按规则相互调用。每个组件有严格定义的功能和参数区(属性定义和接口定义)。

服务组件、单元组件或公共函数组件的划分基于处理的单元及业务完整性。服务组件的主要目的是完成业务的整体调度，它本身并不实现业务功能，而是通过调用其他的组件来实现业务功能。服务组件其实就是服务交易的主调度程序。服务组件具有较强的客户特色，系统通过服务组件来实现完整的业务。服务组件应面向交易设计，一个服务组件即对应一个系统提供给消费方的联机交易。单元组件是银行业务的最小业务单元，它可以完成单个交易的部分功能，系统主要通过单元组件来实现对业务完整性的控制。该组件要求保证业务的一致性，所有主档的修改均在此层完成。业务抽象主要在此层完成，面向业务领域设计，其稳定性要求高，继承性要求高，可随着产品的发展不断完善，不断稳定；从设计的角度单元组件的粒度应该足够细、尽量保持不可再分，功能范围要清晰明确。公共函数组件一般用于特定领域的查询、计算的业务场景实现。公共函数组件对系统只读，不能进行交易的上下文和业务实体更新处理，不参与事务(即不对事务的一致性造成任何影响)。

组件设计方法可以归纳为自顶向下法和自下向上法。自顶向下法可以归结为从业务系统到模块再到组件这样的层次。根据业务系统的子系统或模块的分析，根据高内聚，松耦合以及是否可以复用的原则来讨论和细分，抽象到最细粒度的组件层次。自下向上法就是通过对业务流程分析，将业务系统涉及的所有业务活动和业务数据都列举出来，分析业务活动和业务数据之间的关系，根据业务系统的需要和可复用的要求将业务进行细分，归类，形成可独立部署的组件。在设计工作中，要始终贯彻组件化设计思想。根据业务系统的业务场景不断地讨论、识别，抽象出最细粒度的组件，并最终形成组件功能分册设计书。包括组件总体示意图，组件概要设计，组件属性定义和组件接口定义。

对于组件调度策略制定，应用子系统内或应用子系统之间的组件调用，统一经由组件调度平台进行。统一的调度管理，更便于对组件的状态、调度层级规则进行检查、控制，同时，也为调度现场/调度堆栈的统一管理、调度出错返回的统一处理提供可能。优选的，各类组件有清晰的层次关系，组件调用应该按这种层次关系进行约束管理，即：公共函数组件可以调用公共函数组件；单元组件可以调用单元组件、公共函数组件，不能调用服务组件；服务组件可以调用单元组件、公共函数组件，不能调用服务组件。

通过使用独立的组件建设和组件调度策略制定可以实现灵活的服务组装和拆分，特别是可随着业务发展、流程优化，对提供服务进行组合和拆分。例如，银行核心系统的基本服务有冻结、解冻、扣账，都可以独立对外提供的服务，假设出于流程优化，希望一次性完成对某个预先冻结了的账户进行部门金额的扣账，然后在冻结该账务的剩余资金，这样完全可以很方便地将解冻、扣账、冻结打包成一个新的服务，对外提供三位一体的服务。

本发明还涉及一种如图2所示结构的基于宏服务的业务服务系统，包括：

子系统规划部件，用于依照业务领域不同将业务服务划分为若干子系统；

组件建设部件，用于将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的服务组件、单元组件或公共函数组件；

组件调度策略制定部件，用于将不同组件之间的调度关系整合为统一的组件调度策略；

子系统封装部件，用于依据业务服务请求将对应的服务组件、单元组件和公共函数组件封装为模块，并依照子系统规划将对应的若干模块封装为子系统；

分布式架构建设部件，用于将一个或多个子系统组合为分布式架构部署至节点提供业务服务。

本发明还涉及一种计算机可读存储介质，所述存储介质上存储有执行时实现上述方法的计算机程序。

本发明还涉及一种电子设备，包括调用服务组件、单元组件和公共函数组件并执行上述方法的处理器和存储服务组件、单元组件和公共函数组件的存储器。

以上所述仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换等都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求书的保护范围为准。

Claims (6)

1.一种基于宏服务的业务服务方法，其特征在于，包括：

子系统规划，依照业务领域不同将业务服务划分为若干子系统；

组件建设，将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的组件；

所述组件建设包括：

依照功能的类型区别，将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的服务组件、单元组件或公共函数组件；

所述服务组件的属性定义对应业务服务请求，接口定义对应业务服务请求需要调用的单元组件；

所述单元组件的属性定义对应业务服务功能，接口定义对应需求该业务服务功能的服务组件；

所述公共函数组件的属性定义对应只读请求，接口定义对应该只读请求调取数据所需要访问的服务组件和/单元组件；

组件调度策略制定，将不同组件之间的调度关系整合为统一的组件调度策略；

所述组件调度策略制定包括整合服务组件的对应业务服务请求；

子系统封装，依照子系统规划将对应的组件封装为子系统；

所述子系统封装包括：

依据业务服务请求将对应的服务组件、单元组件和公共函数组件封装为模块；

依照子系统规划将对应的若干模块封装为子系统；

所述子系统封装还包括：

将多个子系统均需要使用的服务组件、单元组件和公共函数组件封装为公共服务模块，并使用公共服务模块参与子系统封装操作；

分布式架构建设，将一个或多个子系统组合为分布式架构部署至节点提供业务服务。

2.如权利要求1所述的方法，其特征在于，所述子系统采用容器化部署。

3.如权利要求1所述的方法，其特征在于，所述服务组件、单元组件和公共函数组件均为互相不具备直接耦合关系的独立组件。

4.一种基于宏服务的业务服务系统，其特征在于，包括：

子系统规划部件，用于依照业务领域不同将业务服务划分为若干子系统；

组件建设部件，用于将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的服务组件、单元组件或公共函数组件，包括：

依照功能的类型区别，将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的服务组件、单元组件或公共函数组件；

所述服务组件的属性定义对应业务服务请求，接口定义对应业务服务请求需要调用的单元组件；

所述单元组件的属性定义对应业务服务功能，接口定义对应需求该业务服务功能的服务组件；

所述公共函数组件的属性定义对应只读请求，接口定义对应该只读请求调取数据所需要访问的服务组件和/单元组件；

组件调度策略制定部件，用于将不同组件之间的调度关系整合为统一的组件调度策略，包括：整合服务组件的对应业务服务请求；

子系统封装部件，用于依据业务服务请求将对应的服务组件、单元组件和公共函数组件封装为模块，并依照子系统规划将对应的若干模块封装为子系统；还用于将多个子系统均需要使用的服务组件、单元组件和公共函数组件封装为公共服务模块，并使用公共服务模块参与子系统封装操作；

分布式架构建设部件，用于将一个或多个子系统组合为分布式架构部署至节点提供业务服务。

5.一种计算机可读存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现权利要求1至3中任一项所述的方法。

6.一种电子设备，其特征在于，包括处理器和存储器；

所述存储器，用于存储服务组件、单元组件和公共函数组件；

所述处理器，用于通过调用服务组件、单元组件和公共函数组件，执行权利要求1至3中任一项所述的方法。