业务案例

2000年后，在IT系统全球化建设过程中，基于主机架构，国内各大银行分别开发了各自的银行业务系统，实现银行业务信息处理全国逻辑集中乃至全球逻辑集中。有些银行采用“胖核心”架构，即：大部分业务功能都在核心系统实现，公共信息都在核心系统存储，外围只有一些渠道类产品、少量的业务系统产品和辅助产品，公共信息从核心系统引用。也有一些银行采用“瘦核心”架构，核心系统只完成客户信息管理、存款业务、贷款业务、支付业务等主要业务功能，其他业务功能如额度管控、客户关系管理、国际结算业务、票据业务等，都由外围系统完成；公共信息如客户信息、客户关联信息、机构信息、货币码信息、汇率信息、国家地区信息等在各系统中分别保留。

“胖核心”的架构由于功能太过集中，对主机性能要求较高，且一旦出现性能故障，影响范围极大，且随着业务扩展，需要资源的成本很大。其优点是银行整体产品架构清晰简洁，对应业务操作、系统开发和运维，都有较大的优势。

“瘦核心”的架构因过多的产品层叠，存在因产品间耦合性过强产生的诸多隐患，而且随着业务的发展、接口延伸、产品功能扩展，会变得日益严重。

一是大量的数据数据冗余。机构信息、货币码信息、国家地区信息、汇率信息、利率信息等公共信息，很多系统都会用到，接收信息后在本地存储，利率和汇率数据若接收失败，还可能对业务产生一定影响。客户及客户关系信息在各个系统中各自录入或向核心及其他信息管理系统同步，有可能因同步不及时导致客户信息不一致，而且也会导致多头查询和多头录入的问题；对于机构撤并、客户信息保密等都需要分别处理。

二是产品间耦合度高。由于产品的重叠，存在公共信息、参数信息等数据同步要求，上游产品数据结构及接口变化，导致众多下游产品需要跟随变更的情况；批量时，还存在下游产品需要等待上游数据，导致批量时间窗口缩小的问题。由于产品间耦合太紧密，每一个需求开发都牵涉太多产品，导致开发、测试、投产和维护工作复杂度太高，工作量大，效率低下。

三是权限管理复杂。每个产品都有自己的权限管理功能，各产品之间缺乏统一的登录接口，柜员做一笔业务，往往要在不同的产品间多次登录（如开户），客户体验差；即使开发了单点登录系统，也无法解决全部问题。

以上各种问题，若只在单一产品上出现，产生的影响不是很大，但是，在整个产品架构成网状，各个产品互相关联互相影响的情况下，这种影响就会成几何倍数增长。造成的结果是：需求分析、产品开发、测试、投产等过程复杂化，效率严重下降，出错几率大大增加。对于业务的影响是：操作复杂化、业务分析复杂化、客户体验降低。每新增一个产品，都会导致这种问题更加严重，直至无法负荷。这种架构下，业务部门提出的需求，需要巨大的改造工作量，系统设计复杂，实现缓慢，导致业务人员抱怨系统开发赶不上业务发展的步伐。

在银行业务系统从主机的集中式向分布式转型时期，若只简单地把现有产品按照原来的架构和接口向X86下移，能否解决产品间大量的数据冗余及高耦合问题？很明显，答案是不能。但令我们欣喜的是，分布式系统架构本身就提供了更多的选择，让我们在新系统设计时，转向银行综合系统的模块共享设计思想，避免集中式系统架构的各种问题。

分布式下银行综合系统设计

目前银行各系统之间通过交易接口进行互相调用，交易粒度粗，难以细化和灵活组合满足新需求，模块分隔，灵活度较低，单个需求的改造量大。需要打破目前这种粗交易的调用模式，设计新的开放的微服务模式，为各种业务场景提供细化的灵活组合。

在分布式架构下，我们可以采用领域驱动、微服务定制、服务调用的方式，实现每一个银行业务场景。即，根据银行业务系统的划分，将系统定义为一个个领域模块。如：客户管理模块、账务信息管理模块、公共信息管理模块、贷款模块、支付模块、额度管控模块、信用卡业务模块等，在各个领域模块定制微服务。在客户信息模块中可定义：客户基本信息查询、客户附加信息查询、客户关联信息查询、集团牵头行查询、客户基本信息修改等。然后再跟进具体的业务场景定义出一个个组合服务，每个服务调用多个不同的微服务，银行的每一笔业务都由具体的微服务组合完成。

微服务的分布式系统需要分层设计，通常分以下几层。接口层：用于设计服务接口，通过接口定义进行服务隔离。服务层：用于调度多个领域和微服务组件，进行跨领域的流程调度，柔性事务和业务一致性处理。领域层：用于管理领域内的数据和逻辑，保持业务领域内的数据匹配。基础层：提供数据库访问、消息传递、外部资源调用等基础服务。

通过服务化改造，把IT系统全面服务化，支持开放调用，业务领域数据的统一管理，各系统之间通过统一的参数化定制服务调度平台，管理跨领域的一致性，进行IT服务的灵活组合，满足各种业务需求。

同时，将公共服务抽取出来，提供各种通用的服务，例如：通用柜员和权限服务、把所有服务的柜员和权限进行统一管理，各业务领域可以增加特殊权限接口，灵活扩充权限；通用参数服务，把所有服务的参数通过参数管理服务统一管理；通用客户信息服务，为所有业务模块提供统一的客户信息服务。

按照业务划分可以定义以下业务模块和大领域。

客户管理模块：管理和维护客户的所有信息，包括基本信息、附加信息、关联信息等。以银行号+客户号为基础标识，关联信息应包括集团与成员关联信息及同一客户在全球不同银行下客户号关联信息，以实现客户统一授信和全球服务。客户信息只在客户管理模块，其他模块不再留存，客户管理模块提供微服务，为其他所有业务模块提供客户信息的相关服务。

账务管理模块：账务模块管理内容包括账户信息AIF、交易信息TIF、总账和传票，所有业务系统模块发生的交易都在账务管理模块记账。账户分内部账户和外部账户，外部账户为客户账户，内部账户为银行内部核算账户。账户包括内部账号和外部账号，银行号+外部账号为账户的唯一识别标识。内部账号为账户的基本属性信息，由银行号+客户号+核算码+货币号+序号组成。

公共信息管理模块：公共模块管理银行的公共信息及公共参数，包括银行信息、机构信息、客户信息、货币信息、科目信息、汇率数据、利率数据、国家地区信息、运行控制信息等，公共信息不再放到各个领域模块中。

柜员权限管理模块：定义柜员的交易权限、访问权限、金额操作权限、授权权限等，公共的柜员管理和权限管理也在本模块中实现。服务管理模块：服务管理主要实现服务定制，各模块提供的微服务，由本模块进行组合，形成满足业务需求的系统功能，只有在本模块定义的服务才能对外提供业务服务。

其他业务模块：例如存款、贷款、支付、额度管控、信用卡业务、网银、ATM等，形成各种的业务模块领域，根据自身业务逻辑，设计微服务。

在分布式架构下，综合考虑业务特性，按照领域设置模块，由模块提供本领域的微服务，杜绝各个不属于本领域的冗余信息，可大幅度减少模块间耦合，不会出现类似：一个客户信息栏位变更，需要大量系统同步改造的问题，整体减少模块间接口的复杂度；系统变更设计时，考虑向前兼容，对于非BUG类微服务需求，原则上，只能新增，不做修改，避免大面积调整调用模块，可大大减少开发、测试及投产的复杂度，提高工作效率。

按照以上领域划分，我们可以举一个具体的例子：一笔汇款交易。渠道收到一笔汇款交易，根据交易地域及负载均衡，进行交易分发，然后根据交易管理中汇款交易的定义向各领域进行服务分发调用微服务，根据各微服务执行情况，整合处理，返回交易结果，完成汇款业务。

这个例子中，我们可以看到，一笔汇款业务，已经涉及了我们定义的六个模块，由各个模块的微服务组合，完整地实现一笔业务，系统架构简洁明了，不存在多余的数据同步和重重叠叠的接口调用等问题，不论开发还是测试，都更简单高效。

综上所述，分布式下新一代银行业务系统设计，应该综合分析，整体设计，按照业务划分，实施领域驱动，把系统整体架构，从面向交易的架构，转为面向微服务的架构。通过微服务调用实现数据共享和资源共享，通过微服务细化拆分和参数化调度配置，实现服务高度灵活性和可定制化。柔性系统设计，灵活组合各种服务，随机应变满足各种变化的业务场景和需求。这样我们才能快速响应业务需求，高质高效地实现系统的开发、测试和投产，保障系统平稳运行，为业务发展提供强有力的技术支撑。

来源：金融电子化