谈谈银行核心系统建设--篇4：核心系统的服务拆分

文章来源：e路向上，文章仅供个人学习

最好的架构模式演进，应该是随着业务需求（需要解决的问题）引入的，而不是为技术而技术。核心系统的服务下移，实际上从开放式核心建设时期就开始了，如额度管理、押品管理、商业汇票（承兑、贴现、转贴）、国际结算、贷款核算等相关的服务、随着银行系统专业化的发展，而逐渐从核心系统剥离，形成所谓的瘦核心。事实上，不论是基于IBM主机的单体核心，还是开放式瘦核心，并没有遇到什么特别无法解决的业务问题。目前方兴未艾的云原生、分布式架构的核心建设，主要驱动因素还是在技术安全部分，在这一点上，与互联网行业面临业务爆炸式增长后，不得不依靠新技术来解决业务问题不可同日而语。

淘宝架构模式演进对商业银行的启示

《淘宝技术这十年》一书，对淘宝技术的演进路径做了较全面的介绍，书中可以非常清晰的看到淘宝不同业务发展阶段所面对的不同业务问题，以及由业务推动的淘宝技术演进。以下将书中的发展历程简要整理，并与商业银行同时期架构进行简单对比：

约2003–2004年，淘宝初创。当时面临的业务形态是日均PV不足百万，采用技术架构为LAMP架构（Linux+Apache+MySQL+PHP）–全站采用单体PHP应用，单台MySQL承载所有数据。其时，需要解决的业务问题是：快速验证商业模式，”能用”比”好用”重要。其技术架构示意如下（图片引用自书中原图）：

与之对应，这一阶段多数商业银行已经完成大集中，其架构模式与淘宝一样，都是单体架构，只是，此单体非彼单体：商业银行大范围采用的是390大型机或AS400小型机之类淘宝想都不敢想的解决方案。商业银行从信息化开始的那天起，就没有碰到过互联网创业团队通常会面临的预算压力。

2004–约2007，业务爆发。期间，发生了几次标志性事件，一是随着2004年Mysql替换为Oracle集群，背景是Mysql单机很快触及性能瓶颈（代价是单台Oracle服务器成本是Mysql的20倍）；二是2005年Oracle服务器不得不换成小型机，同时开始进行应用层重构，用JAVA替代PHP，服务开始垂直拆分（分库），Oracle集群节点扩张；三是2006年开始，去小型机的努力（成本太高了，小型机维保费用占IT预算总成本的x成），期间自研分布式文件系统，用PC服务器替换EMC存储阵列等；四是2007年，完成自研分布式缓存Tair等，为全面切换到分布式时代做好了准备。（图片引用自书中原图：这一时期淘宝架构示意图）

与之对应的，当前商业银行的架构模式大部分与2005~2006年时期的淘宝架构模式类似：部分服务做了垂直拆分，为解决性能问题（如果有的话，其实以大部分银行的交易量，只要应用代码不是实在太差，一般不会有性能问题），做了分库分表和读写分离。其架构模式大致如下：

所不同的是，商业银行的架构，大多没有如淘宝这样不断演进，而是在某个时间点上，宣布要“建设新核心系统”，以战役方式，完成从单体架构，到类上图所示的架构的转变。互联网分拆单体系统常用的“先增量，后存量”的服务迁移策略，进行技术优化常用的“先存储层，后计算层”的替换策略，在商业银行则变成了一次性的切换，这可能的原因有两点：一是商业银行业务相对稳态，技术架构相对稳定；二是过去的20几年，得益于经济的高速发展，IT成本没有像淘宝那样，成为需要考虑的关键因素（时移世易，后面还是不是这样，就不一定了。对于有降本增效指标的银行技术主管而言，可以多学学淘宝，降本的道路千万条，尽量避免一谈到降本增效就是裁员）。无论如何，这一阶段的淘宝，至少给了我们两点启示：1、语言和架构的升级必须服从于业务发展阶段；2、技术架构升级的本质是商业价值与技术成本的博弈，技术架构的采用，必须考虑总拥有成本（TCO）。

2008–2011，架构成熟期。随着业务量的进一步增长，市面上已经没有可以买到的产品可以解决淘宝的问题，倒逼技术团队必须自己解决问题，于是分布式服务框架、分布式消息中间件、配置中心、服务注册中心、分布式数据库、全链路追踪工具、Sentinel限流降级框架等应运而生，标志着分布式架构进入工程化阶段。（图片引用自书中原图）

2012年至今，云原生。容器化部署，弹性扩容，异地多活，全链路压测，将双11玩成了“谈笑间，樯橹灰飞烟灭”….

商业银行当前正处于准备一步从IOE架构跨越到云原生分布式架构的阶段（部分商业银行已经进行一段时间，并取得相应成果了）。与淘宝当年需要自研几乎所有的中间件不同，商业银行处于的是一个技术环境成熟，可以取“拿来主义”策略的阶段，只要花钱能买到的，都不是问题……问题是，与淘宝面临非如此不可的选择相比，商业银行并不面临因技术架构而制约业务发展的问题，现行IOE架构仍可充分满足绝大多数银行的需要，因此，实现云原生分布式架构下系统总拥有成本低于IOE架构，就成为技术演进价值的重要组成（信创除外）。而分布式架构的系统总拥有成本，与服务拆分息息相关。

微服务拆分的原则

关于微服务的大小，莫衷一是，并没有准确的定义，多“微”算是微服务？有人认为一个微服务应该是可以在两周内完全重写的，也有人认为一个微服务的有效代码行数不应该超过4K行。对银行业业务系统稍有了解的，从直觉上就能知道，这基本上不太可能，按这个粒度来拆分微服务，把全行系统重构一遍的话，估计会收获几千个微服务，这不但会给服务治理带来灾难，一般的银行，也养不起这么多开发工程师和运维工程师。

那么，我们后面要谈的微服务拆分，需要遵循什么原则呢？有几点业界普遍认可的原则建议作为核心系统服务拆分的根本遵循：

围绕业务概念建模。以银行的业务领域（如对公存款、对私存款、内部户、存放同业、保证金、支付清算、风控审核、客户信息）为边界划分服务，而非系统的技术分层：如前端、服务整合与编排、后端服务、持久层（所谓的洋葱架构）。

定义有界上下文。有界上下文是一个业务领域的语义边界。稍微有点费解，比较直观的理解是，同样一个客户模型，在核心客户信息服务和风控服务、CRM中的外延和内涵，是不一样的，不能因为他们都是“客户”，就聚合到一起。

自治性与独立部署。每个服务拥有独立代码库、数据库、技术栈选择权（如支付服务用Java，报表服务用Python）。

微服务不是免费的午餐，理论上，服务拆分的粒度越小，就越可以带来更多的自治性与独立性（事实上也未必，如果拆分有问题的话，会形成大量的服务间依赖），但是，管理大量服务的成本也会大量增加（涉及服务部署、测试、监控、全链路追踪、故障定位、日志分析等等），而这些，很多时候并不创造业务价值。

核心系统的服务拆分

基于以上原则，我们先假定银行核心系统要承载的业务功能有如下这些：客户、活期存款、定期存款、保证金存款、内部户、存放同业账户、产品、定价、费用、机构、柜员（用户）、会计账务。贷款账务服务从业务形态上看，融资业务有更高的关联性，先默认已经从核心系统剥离（未来有机会，在讨论融资业务时，再行论述）。实际上，上述业务功能已经大体将核心系统服务拆分相关的业务领域进行了大致厘定，以下对几个关键服务进行探讨：

客户服务。商业银行服务的目标客群，包括个人客户与法人客户，法人客户中，还有一类特殊的同业客户。基于有界上下文原则，个人客户与法人客户虽然都是客户，但二者的业务模型并不一致，商业银行在客群管理上，同样也是泾渭分明–分为零售与非零（一般还会有金融市场，不过一般将企金业务与金融市场业务，由分管对公的副行长统管），因此，将客户服务分拆为个人客户服务，与企业客户服务两个服务，可能更为合理。

存款服务。按照垂直拆分原则，可以考虑拆分为，个人活期存款服务、个人定期存款服务、企业活期存款服务、企业定期存款服务，vostro相关的同业存款可划入企业存款服务中、部分有大额存单的商业银行，还可以考虑建设独立的大额存单服务。存款服务中，对部分有海量客户(≥千万级账户量）的商业银行，需要考虑个人活期存款、个人定期存款的数据库分片。活期账户分片架构示意图（服务层（Pod）与数据层（分片）均可独立扩展，数据库分片采用主从架构，避免单点故障，分片中间件嵌入服务，减少网络开销）：

保证金服务。保证金服务从功能特点上看，与定活存款高度类似（包括借、贷、计结息、冻结解冻等等），但保证金与投融资服务高度相关，保证金账户的开户服务等，与结算账户，有很大区别，从业务边界上看，具备建设独立自治服务的要件，建议将服务进行拆分。保证金服务因为计息方式的不同，部分银行会有非计息保证金、活期保证金、定期保证金的区别，但实际上，计息属性并不影响账户本身的借、贷处理，保证金服务不建议再分拆为活期保证金服务或定期保证金服务，从治理形态上，也不建议区分个人保证金服务或企业保证金服务。

内部户服务。见浅谈银行内部户治理，一文，内部户具备独立的业务边界，建议建设为独立服务。

存放同业服务。存放同业服务，是一类相对特殊的服务，活期、定期、保证金等，均作为银行的负债存在，存放同业余额则反映在资产端，是商业银行存放在其他机构的账户的影子账户，其账户服务，除了借、贷、计结息外，经常也会将对账服务囊括在内，因为账务特性和提供服务特性的差异，存放同业在拆分为独立服务之前，常用内部户来处理相关功能。

机构服务。机构服务与核心系统其他服务的交互，主要在账务机构获取的部分，及由此可能导致的机构撤并、机构升降级（分行降为支行，支行升为分行）。理想状态下，机构服务还需要面向网点作业、集中作业、审批类服务，及行政管理，即统筹考虑行政机构、经营（审批）机构、账务机构三大类属性，将机构服务升级为全行共享服务，但因为系统异构的原因，多数从外面买来的系统都自带完整的机构、用户、权限管理体系，基于全行级的机构管理服务，反而带来集成工作量。详细讨论见小命题的大乾坤：IT视角下的银行机构设置。

产品中心。很多机构都希望能够构建一个全行级的产品中心服务，但这貌似违反了限界上下文的规则，负债产品与融资产品、支付产品、投资产品，在业务模型上有着重大差别，在企业级架构视角下，建立一个很薄的，仅体现目录管理的产品中心服务（即不体现业务模型），是可行的，但不建议将产品中心升级为关键枢纽级服务。核心中的产品服务，在领域内进行定义，或许是比较合适的。详细探讨见建设全行级产品工厂：梦想能否照进现实？

用户中心。从纯服务视角看，核心系统事实上与用户无关。广义上的三类用户，分别是电子渠道（手机银行、网银等）的用户、与网点作业及集中作业相关的Teller和Operator、各类审批系统中的用户，均与自身的业务特性密切相关，可分别随渠道类服务、运营类服务及审批类服务进行构建。

费用中心。这是一个与产品中心类似的服务，建议是泛核心业务领域内的全功能口径的费用工厂（通过RPC进行通讯）随核心系统建设，但企业级的费用工厂，建设薄薄一层即可–即用于发布银行的收费目录。详细探讨见因需而变–银行收费管理系统的集中与自治。

定价中心。用于发布全行定价，支持按渠道、按机构、按客户进行分层定价，可建设独立服务，主要面向利率及汇率的管理。

会计引擎。独立服务，详见：会计引擎：交易与核算分离的前世今生

服务内部需要进一步的拆分吗？

有开放式核心建设经历的同学，很容易会看到，这个服务拆分，除了数据库做了垂直拆分，引入了分布式服务治理体系外，服务拆分的模式似乎与之前的开放式核心并无太大区别。确实是这样，微服务架构本质上是SOA的进一步发展，是实现SOA的一种特定方法。以存款服务为例，我们来看看两个做了进一步服务细分的案例：

引入合约中心服务。其起源推测（纯猜测，有了解更多来龙去脉的同学，可后台私信）来自于IBM的FSDM–金融服务模型。该建模理论提出，参与者、合约、条件、产品、地点、分类、业务方向、事件、资源项等9大要素，可以作为不同业务领域金融模型的通用性描述。该方法论被很多机构采用，并衍生出诸多不同的版本（比如某大厂的飞马模型）。产品中心服务、合约中心服务等，由此被引入业务建模。在建模实践中，原与账户相关的业务属性，被剥离到合约中，由此导致存款服务无法实现自治，计息、结息、结清等操作，均需依赖合约服务，似乎无此必要。

存款服务的洋葱式拆分。在对存款服务进行更细粒度拆分的过程中（或许也是很多其他服务拆分常用的方式），依据提供的功能进行拆分，拆分出存款产品服务（服务编排层，与产品中心那个产品不是一回事），存款核心–服务开户、冻结、解冻等，借记核心–主要做借记、贷记处理，计息中心–计结息处理。再叠加合约中心、产品中心、限额中心，还有累计中心，其服务调度大概会变成这样：

是不是有点晕？：）。存款服务的数据模型，被分散拆分到若干服务中，原在一个服务中可以内部自治的功能，现在全都要通过RPC调用进行访问，服务的调度依赖，及交易链路跟踪的复杂度，都增加了，关键的是，原来一两个人可以搞掂的存款，可能得增加开发人手了。因此，个人的建议是，不建议再做细粒度的拆分了。

结语

行业或企业的架构演进，与业务发展和技术变革息息相关，银行业作为一个已延续几百年的行业，其业务形态相对稳态，与互联网行业高速发展时期一日千里的快速演进，有着很大的区别。但不管是互联网还是银行业，微服务化，本质上都需要回归行业特点，在业务指标（交易量、并发量）、技术指标（延迟、可用性）、经济指标（成本与回报）之间寻找动态平衡点。银行业的微服务改造，也并不需要从0开始，得益于行业的历史沉淀，不论是主机核心时代，又或是开放式核心时代，都沉淀了大量关于模块划分、垂直拆分的先进实践，一般来说，对分布式架构的核心建设而言，将早已被反复验证过的优秀实践（业务建模）与更先进的技术手段（云原生技术体系）相结合，以更低的成本，实现更敏捷响应、更稳定运行、更容易扩展的系统架构，才应该是分布式核心建设应追求的目标。