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

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

【技术实现步骤摘要】
一种基于宏服务的业务服务方法及系统
本专利技术涉及分布式系统
，尤其涉及一种基于宏服务的业务服务方法及系统。
技术介绍
银行核心业务系统是银行应用系统架构中最核心的业务服务系统，承载银行重要的产品服务能力和关键基础业务，包括存款、贷款、支付、客户信息、会计核算等业务。以往中大型银行的核心业务系统通常基于IBM主机系统建设，但主机集中式技术架构缺乏水平可扩展能力，难以满足互联网经济时代银行IT系统的高容量和资源动态分配的要求，核心业务系统普遍尝试进行基于X86平台的分布式架构转型，其在扩展性、成本、自主可控等方面优势明显。分布式核心系统应用架构的通常做法有以下两种:1.按照业务领域将应用系统进行纵向拆分，将原有单体核心业务系统，拆分为独立的负债系统(对公/对私)、资产系统(对公/对私)、支付系统、客户信息系统、公共业务系统等，分布式架构模式采用SOA模式(基于企业服务总线响应各系统间交互)或微服务模式(各系统通过RPC调用服务交互)。2.采用分布式集群应用架构，既每个应用节点同构部署，应用集群前通过F5或软负载实现交易的负载均衡。以上分布式核心应用架构模式，分别存在以下不足：1、应用系统拆分后的交易一致性问题：交易强一致性是银行核心业务系统的关键要求，交易一致性要求远高于电商平台和其他互联网应用。银行核心业务系统具有高内聚特性，例如一笔贷款放款交易通常涉及到资产系统(贷款账户处理)、负债系统(存款账户处理)、客户信息系统等。应用系统拆分后，一笔业务需要调用多个系统节点的服务，并且需要保证强一致性，这个问题对系统设计带来了很高的复杂度。2、应用系统拆分后交易性能问题：分布式拆分后，原来一笔交易由一个节点完成，变成了需要多个节点协同完成，各节点通过RPC或者消息传递完成进程间通讯机制,增加了网络延时,整个交易链路变长，单笔交易响应时间降低。3、集群架构的部署灵活性问题：a.由于集群架构采用应用节点同构，任何一个业务需求交付都需要在所有节点进行部署，造成了部署流程和时间长。b.随着业务的不断发展，每个节点的应用包会不断增长，构建时间也会相应变长。c.每个业务模块的规模不同，同构部署不利于计算和存储资源的有效利用。
技术实现思路
为解决现有技术的不足，本专利技术提出一种基于宏服务的业务服务方法及系统，以一笔金融业务在一个事务内完成的高内聚原则，形成若干子系统，进而在宏服务架构下进行子系统规划及服务封装，子系统按业务领域进行划分，原则上无跨节点事务访问，即解决了单体应用框架的扩展性问题，集群架构的部署灵活性问题，满足分布式架构的成本低廉，可用性、可扩展性更好的特性，同时也解决了传统分布式应用架构对业务强一致性保证的难点。为实现以上目的，本专利技术所采用的技术方案包括：一种基于宏服务的业务服务方法，其特征在于，包括：子系统规划，依照业务领域不同将业务服务划分为若干子系统；组件建设，将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的组件；组件调度策略制定，将不同组件之间的调度关系整合为统一的组件调度策略；子系统封装，依照子系统规划将对应的组件封装为子系统；分布式架构建设，将一个或多个子系统组合为分布式架构部署至节点提供业务服务。进一步地，所述组件建设包括：依照功能的类型区别，将业务服务中的不同独立功能分别各自建设为服务组件、单元组件或公共函数组件；所述服务组件的属性定义对应业务服务请求，接口定义对应业务服务请求需要调用的单元组件；所述单元组件的属性定义对应业务服务功能，接口定义对应需求该业务服务功能的服务组件；所述公共函数组件的属性定义对应只读请求，接口定义对应该只读请求调取数据所需要访问的服务组件和/单元组件。进一步地，所述子系统封装包括：依据业务服务请求将对应的服务组件、单元组件和公共函数组件封装为模块；依照子系统规划将对应的若干模块封装为子系统。进一步地，所述子系统封装还包括：将多个子系统均需要使用的服务组件、单元组件和公共函数组件封装为公共服务模块，并使用公共服务模块参与子系统封装操作。进一步地，所述子系统采用容器化部署。进一步地，所述服务组件、单元组件和公共函数组件均为互相不具备直接耦合关系的独立组件。进一步地，所述组件调度策略制定包括整合服务组件的对应业务服务请求。本专利技术还涉及一种基于宏服务的业务服务系统，其特征在于，包括：子系统规划部件，用于依照业务领域不同将业务服务划分为若干子系统；组件建设部件，用于将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的服务组件、单元组件或公共函数组件；组件调度策略制定部件，用于将不同组件之间的调度关系整合为统一的组件调度策略；子系统封装部件，用于依据业务服务请求将对应的服务组件、单元组件和公共函数组件封装为模块，并依照子系统规划将对应的若干模块封装为子系统；分布式架构建设部件，用于将一个或多个子系统组合为分布式架构部署至节点提供业务服务。本专利技术还涉及一种计算机可读存储介质，其特征在于，所述存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述的方法。本专利技术还涉及一种电子设备，其特征在于，包括处理器和存储器；所述存储器，用于存储服务组件、单元组件和公共函数组件；所述处理器，用于通过调用服务组件、单元组件和公共函数组件，执行上述的方法。本专利技术的有益效果为：采用本专利技术所述基于宏服务的业务服务方法及系统，有效提升了银行业务系统的分布式应用架构能力，使得按子系统交付和部署更加灵活，高可用性能力更强。保证了银行业务交易在分布式架构模式下的一致性和处理效率。附图说明图1为本专利技术基于宏服务的业务服务方法流程示意图。图2为本专利技术基于宏服务的业务服务系统结构示意图。具体实施方式为了更清楚的理解本专利技术的内容，将结合附图和实施例详细说明。相对于微服务，宏服务不再只是完成一件事，而是提供一组服务，使其服务于一项业务领域。每一个业务功能由一各宏服务节点的一只服务独立完成，而不涉及多个服务节点的服务调用。如图1所示为本专利技术基于宏服务的业务服务方法流程示意图，主要包括以下步骤：子系统规划，依照业务领域不同将业务服务划分为若干子系统；组件建设，将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的服务组件、单元组件或公共函数组件，其中，服务组件的属性定义对应业务服务请求、接口定义对应业务服务请求需要调用的单元组件，单元组件的属性定义对应业务服务功能、接口定义对应需求该业务服务功能的服务组件，公共函数组件的属性定义对应只读请求、接口定义对应该只读请求调取数据所需要访问的服务组件和/单元组件；组件调度策略制定，将不同组件之间的调度关系整合为统一的组件调度策略；子系统封装，依据业务服务请本文档来自技高网...

【技术保护点】
1.一种基于宏服务的业务服务方法，其特征在于，包括：/n子系统规划，依照业务领域不同将业务服务划分为若干子系统；/n组件建设，将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的组件；/n组件调度策略制定，将不同组件之间的调度关系整合为统一的组件调度策略；/n子系统封装，依照子系统规划将对应的组件封装为子系统；/n分布式架构建设，将一个或多个子系统组合为分布式架构部署至节点提供业务服务。/n

【技术特征摘要】
1.一种基于宏服务的业务服务方法，其特征在于，包括：
子系统规划，依照业务领域不同将业务服务划分为若干子系统；
组件建设，将业务服务中的不同独立功能分别各自建设为具有属性定义和接口定义的组件；
组件调度策略制定，将不同组件之间的调度关系整合为统一的组件调度策略；
子系统封装，依照子系统规划将对应的组件封装为子系统；
分布式架构建设，将一个或多个子系统组合为分布式架构部署至节点提供业务服务。


2.如权利要求1所述的方法，其特征在于，所述组件建设包括：
依照功能的类型区别，将业务服务中的不同独立功能分别各自建设为服务组件、单元组件或公共函数组件；
所述服务组件的属性定义对应业务服务请求，接口定义对应业务服务请求需要调用的单元组件；
所述单元组件的属性定义对应业务服务功能，接口定义对应需求该业务服务功能的服务组件；
所述公共函数组件的属性定义对应只读请求，接口定义对应该只读请求调取数据所需要访问的服务组件和/单元组件。


3.如权利要求2所述的方法，其特征在于，所述子系统封装包括：
依据业务服务请求将对应的服务组件、单元组件和公共函数组件封装为模块；
依照子系统规划将对应的若干模块封装为子系统。


4.如权利要求3所述的方法，其特征在于，所述子系统封装还包括：
将多个子系统均需要使用的服务组件、单元组件和公共函数组件封装为公共服务模块，并使用公共服务模块参与子系统封装操作。
<...

【专利技术属性】
技术研发人员：田磊，陈强，
申请(专利权)人：中信银行股份有限公司，
类型：发明
国别省市：北京;11