当分布式核心遇见DevOps --- 封铨贤·中国民生银行

豆沙包

作者简介

封铨贤
中国民生银行资深运维专家

民生银行在今年年初上了国内首家以分布式技术去搭建的核心账户体系的系统，在分布式核心建设过程当中，我们通过DevOps的工具和DevOps的理念给我们这个分布式核心有什么帮助？这两者之间发生了什么样的碰撞？这是我今天想跟大家分享的话题。

一. 分久必合,合久必分: 银行核心的演进

借用《三国演义》第一章的一句话，叫做论天下大事，分久必合，合久必分。银行核心系统的演进历史便是如此。

1.1 什么是银行核心系统?

所谓银行核心系统，其实这个定义有一个演进过程，并且各家银行覆盖的范围不一样。不管怎么样，核心顾名思义，在英文里面叫做CoreBanking System，就是客户信息，我们的账务、结算、现金管理、凭证、卡管理等等这些。核心系统就是我们一家银行最基础的账务管理体系，各家银行不一样，不同的历史时期也不一样。

核心银行系统(CoreBanking System)

• 以客户为中心，进行账务处理，满足综合柜员制，并提供24小时服务的核心银行业务系统;
• 顾名思义，银行账务处理的“心脏”;

1.2 银行核心系统的演进

曾经的“分布式”银行核心系统

• 纯手工:算盘就是当年的计算机
• 账务数据分散在各级网点
• 无法支持通存通兑

曾经的银行核心是天然分布式，因为我们的计算机历史其实是很短的，只有20世纪中叶的时候才出现，但是我们的银行业、金融业就是几百年的历史。

1346年意大利就出现了世界上第一家银行，我们国家在明朝末期就出现了票号、钱庄的金融机构，在没有计算机、IT的情况下，我们有核心系统吗？

我们的核心系统就是一个算盘，我们的账务数据是分散在各个网点，我们的核心系统叫做算盘+账本，老前辈可能知道以前70、80年代的时候是拿着几本存折，一本存折里面一打开是手写的，你拿着存折在哪点网点开户存的钱就在哪个网点取钱，想跨行跨省达不到，我记得我在上大学的时候家里给了我一本存折去广州上大学，同一家银行上柜台说对不起，我取不了钱，银行上少几个字通存通兑。

分久必合:90年代全国数据大集中

到了大概80、90年代的时候，那个时候我总结叫做分久必合的阶段。那个时候因为我们的计算机、IT技术起来了，各家银行开始大量采购IBM的小型机、大型机，开始做联机联网解决信息孤岛的过程，在那个时候是以中心化为荣。

在那个年代之后银行越来越像一个章鱼，把我们分散在各个分支机构的数据统一集中到我们的银行，在90年代的时候，国内很多银行都开始做一个叫做全国数据的大集中，这个数据大集中，民生银行业经历过这个历程，民生是1996年初成立的，成立之后一开始数据也是分散在各个分支机构，到2001年的时候，我们在银行业里面实现了比较快的全国的数据大集中，经过大集中建设之后，历史上叫做八大系统，正好吻合了我说的这个章鱼，也叫做八爪鱼，那个时代是综合业务系统，一个系统打天下，业务越做越复杂，系统越做越庞大，到了2000年之后核心系统越来越胖，负担越来越重。

合久必分1.0:SOA架构让核心“瘦身”

• 产品与账务分离:独立出众多专业化产品系统，比如贸易融资、现金管理、 理财、资金交易等
• 核算与账务分离:独立的会计总账及报表系统，年终结算不再停机
• 渠道系统大发展:ATM、网银、手机银行、POS、第三方支付迅猛发展，
  行业离柜率达84.31%

合久必分，总结的第一个阶段就是我们的SOA架构让核心瘦身，这个也有时代背景。

在开放平台面向服务架构兴起之后，市场上也发生很多变化，就是我们进入了一个信息化时代，在这个信息化时代里面，人民群众对金融服务、金融产品的需求是井喷式的发展，大家都会去买股票、理财各种基金和产品，这个时候如果把我的产品做大核心系统里面，这很沉重，并且我的变更对IT人员来说都是负担很重的。

2000年之后就决定把很多产品系统独立起来，比如做贸易融资、现金管理里、资金交易等这些产品我是可以自己有自己的生命周期，但是我的产品系统最终会通过支付系统调我的核心，实现账户的管理。核算与账务分离，每年的30号晚上我们是不睡觉的，以前的会计部门做年终核算，几年前有很多银行的核心系统支持不了年终决算不停机，还有一些银行在元旦这天是要关门停业的。在SOA架构引进来之后，把核算、会计总账、报表独立出去了，就能够支持整个年终结算不停机，就是元旦还可以开门营业。民生银行做这个架构是2013年系统性上线之后实现的。

第三个分离，改革渠道系统的大发展，以前我们可能大家都有一个经历，就是大概10年前，大家都要去网点排队，很多投诉说银行的工作人员不够，服务不够好，但是现在再去的话几乎没有排队了，在同期银行的网点没有增加，甚至很多银行的网点是减少的，因为银行在裁员。为什么呢？因为网银、手机银行、POS各种第三方支付迅猛发展，行业离柜率达到84.31%。经过渠道大发展，核心是由大而全走向小而专。

合久必分2.0:核心向分布式转型

为什么会进入这个阶段呢？

在前面的1.0阶段，我们的核心在功能上已经瘦身了。2010年之后进入了互联网时代，互联网时代带来了很多颠覆，比如说交易量飞涨，另外就是不确定性大增，风险也大增，比如双十一、618各种的促销，用户的行为难以预测，互联网带来的压力很大，这个时候我们银行最基础的核心账目体系也必须考虑做一些变化。

这个时代跟10年前、20年前又发生变化，这个时代叫做去中心化，有两个背景：一个是在硬件上，X86的平台、架构已经能够肩负重任，这个体系里面的东西已经可以与我们的大型机、小型机、主机平台可以抗衡了，因为很便宜，我们可以往上堆机器。就像那句广告，叫做价格便宜量又足。另一个是在软件方面，SOA推行了很多年，现在开始说微服务，弹性伸缩、支持异构，在应用程序上可以支持以前通过硬件保障的高可用和安全性都可以通过微服务化应用层面去改造来实现。在这个时代背景下，我们开始走向去中心化。

银行核心系统的演进大概以10年为一个周期。80、90年代的时候数据是分散的，2000年左右各家银行做数据的大集中，集中在总行，这是一个分久必合。再过10年，我们的数据又分开了，但是其实仍然在我们内部，只不过从8套系统分成了几百套系统。现在这个阶段，2018年还要继续分，合久必分的2.0版本，我相信未来的几年，银行系统往分布式的方向去改造，其实这是一个时代的趋势。

二. 去中心化,自主掌控: 分布式转型之路

前面说到了分布式转型是一个时代的趋势，那么接下来我们看看为什么要分布式转型以及什么是分布式架构。

2.1 为什么要分布式转型?

主要是两方面的考虑：

1. 外部的原因。一个是现在互联网金融对银行业的压力，还有各种趋势，迫切的迫使我们金融机构的系统架构去转型，然后去满足弹性伸缩和快速交付的需求。另外一个叫做国家战略，其实就是四个字，叫做自主可控。还有一个就是行业的背景，就是说我们看到在互联网已经是大规模应用了，我们在金融行业能不能去尝试，能不能去把互联网成功的经验做相对应的实践。
2. 内部的原因。因为我们的传统核心跑在小型机上，实实在在的确实是会存在一些架构上不易扩展的压力和问题，假设我们的流量、客户量和各种交易量如果是不断地翻倍、增长，我们现在的平台架构其实是很容易达到一个瓶颈的，也是有风险的。另外一个，我们的小型机，我们的主机平台，成本是非常贵的，跟X86架构比的话。第三点，就是产品的把控能力弱，这也是因为我们希望能够拥有自己的知识产权，未来也能打造银行业自己的金融科技的竞争力。

2.2 什么是分布式架构?

其实分布式架构也是一个见仁见智的问题，并且也是不断地在变化，90年代说的分布式系统跟现在说的并不是一个东西，所用的技术组件和各种框架都不一样。

一开始的时候，我们交易量很小，我们就找一台服务器，部署一个应用程序，安装一个数据库，慢慢的用户量上来之后，CPU承受不住了，就把数据库独立出来，建一个数据库服务器由应用程序访问。第三个阶段，我们的用户量越来越大，应用服务器计算能力无法匹配，就装很多应用服务器，布很多的应用程序，在前面设一个负载均衡层，底下仍然是一个数据库服务器。

为了减少应用程序跟数据库的交互，就在中间加一个缓存，甚至加一个分布式缓存。大家知道这个肯定是有问题的，数据库只有一个，那就是一个单点，并且存在巨大的风险。

为了解决这个问题，我们就把数据库给拆开，分库分表，读写分离，把数据库拆开之后，整个架构就实现了简单的分布式系统。

这个不是特别细的企业级的分布式架构，从服务接入层要实现服务路由、访问控制、服务限流、交易幂等性实现服支持服务与数据单元化部署。分布式服务建立分布式服务框架，集成分布式消息及批处理框架能力，分布式数据库实现分库分表的数据库水平扩展能力。

2.3 集中式架构与分布式架构对比

我们首先看到传统的架构有一个黄线，满足监管的要求两地三中心，我们在机房A和B部署了两套1：1一模一样的服务器，但是其实真正的交易通过渠道层到达核心的时候都是访问机房A，一直到我的数据库、存储，在存储层通过这个复制的技术，或者在数据库层通过日志同步的方式保证数据是一样的，但是计算能力并没有用上，这就是一个集中式架构。

分布式架构就通过这些分布式组件，然后在两个机房，在很多X86服务上布上应用和数据库，这个时候流量是通过存储路由和负载均衡是均匀的调到两个机房，以及里面不同的服务器。简单的对比，就是成本降低了，另外，计算资源利用率提上去了。

还有一点，通过这张图能看到，这儿有一个巨大的风险，集中式架构是把所有的鸡蛋放在了一个篮子里面，以前的思路就是通过大型机、小型机，通过主机平台去打造一个特别坚固、特别牢固的篮子，这个鸡蛋越来越多，篮子装不下了，就把这个篮子加高加大，但是不断地加高加大，我们会发现风险是聚集在这儿。分布式架构把他们拆成了很多的小篮子，把鸡蛋不断地放在这个小篮子里面，来更多的鸡蛋再购买更多的小篮子，这个时候如果一个小篮子破了，没有关系，只影响一小块业务，风险就降低了。

2.4 分布式核心系统技术架构

上图是我们分布式核心系统的技术架构，简单说的话提供了这些技术组件，最重要的一个就是分布式的数据访问，怎么样支持分库分表和读写分离？另外一个，做分布式系统，最主要的就是账能不能平，我的一笔交易账不能错，怎么实现呢？

我们知道分布式系统有CAP原理，在这个原理里面我们为了保证事物一致性通过两种手段，第一个手段是基于可靠消息的最终一致性。另外一个是万一可靠消息有一个延时，我们有一个完整的冲正模型反向处理，最终确保我的账是没有问题，对于银行来说这个是最关键的。其中的组件，一个是分布式服务框架，我们的包裹、限流等等这些都是一样的，还有分布式配置管理，还有分布式缓存，这是分层的设计。

下面这三个其实是跟银行业比较特殊、比较吻合的，我们银行有很多的批量处理，怎么样实现调度，这个做了一个单独处理。还有一个是全局序列怎么设计，怎么样实现全局的序列化。还有一个统一的流水化，不仅仅是核心系统，而是整个银行体系几百套的系统里面怎么样共用统一的流水规则去实现统一冲正。

分布式系统上线之后取得了不少的成果，我们是行业里面第一个吃螃蟹的，也是第一家把我们的直销银行的业务真正的跑在一个分布式的核心系统上，我们也得到了发改委、银监会、银行各种支持，也取得了一些发明专利。

三. 工具升级,流程再造: DevOps初露锋芒

在建设分布式核心的过程当中，DevOps扮演了什么样的角色？我们为了做这个分布式系统改造了哪些工具和流程？

3.1 分布式核心系统如何运维?

分布式核心上线之后这个系统怎么样运维？

我们面临很多的压力，我们的应用是分散的，原来是一个大核心，可能这些应用都是跑在一个平台上面，但是现在把这些应用拆成了几十个，变成每个应用变成几十个实例跑在上百台的机器上。另外数据也分散了，一个库拆成了4个库，一张表拆成了1024张表，拆完之后这些东西怎么管？分布式改造之后，服务的调度层次比原来多了，外面加了负载均衡和全局路由分发，还有nginx，还有应用服务器、数据库，整个链条很复杂。服务之间是怎么调用的？我们在运维的时候怎么看到，在做技术运维的时候怎么管理？还有系统状态，刚才可以看到集中式和分布式的系统差别，机房之间切换怎么切，还有弹性扩展，还有高可用。

还有四个多：

• 设备多，在两个数据中心布了几百台服务器。
• 应用多，原来可能在一个平台上做了很多的东西，做了很多传统的大核心的功能，现在拆成了很多的应用实现了微服务。
• 服务多，在应用上跑了很多的服务，还要能把传统的核心批处理迁移过来。
• 配置多，互联网也有这个问题，配置管理一直是个老大难。

3.2 如何定位故障？

2000年的时候核心是八大系统，现在有的银行是100多套，有的银行是几百套系统，一笔交易是两三秒钟，这个过程路过了两个城市三个机房，途径12个系统、21个台服务器，这个过程很难说得清楚。

系统出现业务异常的时候，快撞到冰山的时候，在冰山上面，你只能看到负载均衡表现异常，但是在这个冰山下面还有很多的技术组件，有可能是缓存、消费中心、服务治理，甚至有可能是我的分布式数据访问，这当中举个例子，也许是这条线出问题了，但是怎么发现呢？我做运维的怎么样去看呢？这些都是问题。

所以围绕这些问题，在分布式核心的建设过程当中，这个项目并不仅仅是开发中心的事情，运维团队也一起真的是在工作模式上实现了DevOps，我们围绕它做了一个分布式核心的运维支撑体系。

3.3 分布式核心系统运维支撑体系

分布式核心系统运维支撑体系分成四个板块：

首先是运维管理的集中化，我们在服务治理上，在管控上做了一个分布式管控平台去统一的管理维护我的系统的配置和各种参数、各种配置，还有我的服务治理的各种操作。另外我们做了一个运维试点，通过这个运维试点最重要的是屏蔽我分布式数据库分库分表、读写分离之后，通过运维试点，通过分布式的数据访问层去把它透明化，查起来就像一张表一样，如果没有这个工具，如果没有这些平台，就得去实时的去算，算这个数据应该分布在哪个库上，或者分布在哪个表上。另外还有集中监控平台，硬件、软件、数据库网络的集中监控。

第二块是运维操作的自动化，DevOps的概念可大可小，我们这里叫做分布式DevOps部署平台，这些东西就是见仁见智，真正的实现了一个从代码开发到测试到发布到部署实现了自动化，这是最重要的事情。另外一个，就是我们有一个灾备自动化智慧平台，流量的切换是秒级的。

第三块是应用排错可视化，冰山的例子是通过这块解决的，通过实时的交易系统分析每个系统的交易运行状态是怎么样的，在交易易监控技术上做了一个全景运维的平台，端到端的交易通过流水号调度整个链路是怎么样的，这个东西不管有多少套系统，很自然的能够看到这个交易躲在哪儿了，在哪个系统上，之后定位到C系统上，不仅仅是分布式核心系统，这就是围绕着这个体系，在做分布式核心的时候不能说只管我们，外围的各种渠道也得管。另外一个叫做云图系统，实现的是运维架构的可视化，部署结构，服务器整个架构是在线可看的，哪个机器上出现告警了，出现问题了，是能够一目了然的，这是一个来帮助我们做排错。

第四块是服务跟踪智能化。我们做日志分析，一两千平台，我要查日志怎么办？不能说几百个服务器一个一个查，或者去拆看这个交易落到哪个应用服务器上，通过这个做大数据的配置。还有一个是海链服务跟踪，解决刚才说的问题，就是当一个落地出现的时候，这个故障到底是落在哪个地方，通过它可以跟踪到调用的层次，这就是我们整个工具号称十大工具的建设，现在还在不断的完善和优化当中，这当中不只是运维的事情，我们和开发团队也有了紧密的合作。

3.4 用DevOps来武装分布式核心

怎么样用DevOps来武装我的分布式核心？

首先，我们提供了一个DevOps部署平台支持分布式系统从开发到运维的全生命周期管理，提供分布式核心批量部署和变更，事实上这个所谓的批量就是自动化，还有就是提供分布式系统的监控和管理控制台，这当中有三块，在开发阶段能实现持续集成，这个东西都是见仁见智，这个范围很难说，但是不管怎么样，我们能提供的自动化编译、打包运行，还有代码扫描、自动化测试，这些覆盖率都已经能达到。发布方面支持应用的多环境管理，支持在线发布，还有配置，都是在线的，支持版本管理，在运维管理上，主要是监控，刚刚提到的监控日志和服务跟踪、管理控制台这块，这些东西都不是上线之后才完成的，我们在这个项目规划、开发的阶段运维团队就介入了和开发团队一起把这块东西一起实现。

上图就是我们的分布式核心DevOps部署平台的界面，通过这个能看到我们现在管理了多少个主机和集群，然后是实例和各种资源分布的情况，有多少个应用。可以在这个平台去实现一个批量的操作，去做应用的发布，在这里面都是简化了很多的操作，说白了最后实现就是一个按钮的事情，不管是谁来点，我们既然有这么多的服务器，最后的操作屏蔽掉了，我们上线的过程，每次完整发布的过程其实是很简单的，比如说哪个地方有问题了，都可以实现秒级的流量切换，切完之后就没有关系了，部署的时候支持应用级、主机级、集群级、机房级，部署的结果也有自动的健康检查。

刚才提到的DevOps平台组件功能，包括构建、发布、修改、实例管理，包括平台上面的服务开关、故障排查、性能分析做了比较完整的东西，这个并不是说一个通用的部署流水线，针对我们的分布式核心特点，围绕它做了一些定制化的东西。

讲完我们工具建设，简单介绍一下流程建设。

双速IT是现在行业里面比较热的，比如说直销银行、手机银行直接面对客户的业务要快速的响应市场和用户的变化，就需要快速的迭代，但是我们还有一些典型的传统的银行金融业务，可能需要强调稳定为主的，这个简单来说就是叫做敏态和稳态的差别，我的核心系统，账务管理体系其实是很少变化的，账务管理当中最重要的就是计算利息，这些规则很难变化，现在很多监管的要求，不准你开五张卡、四张卡，然后有很多限额，可能因为监管的调整才会做这些变化，传统的核心系统其实是这个。

因为分布式架构在技术框架上，我们必须要做到支持刚才说的敏态，就是快速的双速IT敏态的实现，我们在技术上必须能支持从开发编译到打包自动化，到仓库发布，还有多环境、配置、注册这套的东西必须向互联网看齐，向互联网的企业学习这一整套的东西，最后我们提出来一个观念叫做技术上我们要实现敏态，比如说有一个要求说让一个星期上线，我们也能做到当天之内从开发打包到上线，但是在运维管理流程上，仍然采用稳态的模式，传统的IT运维服务管理流程，用这个是因为我们的业务模式决定了我们应该采用这样的管理手段。

上图就是针对分布式核心的一个DevOps部署流水线，其实也都大同小异，开发人员使用这个平台创建项目、申请资源、开发代码、提交，中间有一个自动化测试，然后通过一些工具到生产，应用人员也是通过这些来实现运维的交付管理，用到的组件包括开发平台这是一整套的。

四. 组织变革,文化重塑: DevOps创造未来

这部分想从企业文化和组织上分享一下我的一些感受和变化。

应用运维专业化

我是在应用运维的团队，以前银行是没有应用运维这个部门的，后来因为监管的要求，会要求开发人员不允许碰生产，不允许接触生产环境，所以数据中心组建了运维的团队，这个过程叫做应用运维的专业化，每个系统分配一个负责人，然后中心化管理、流程统一，跟数据中心的基本能力进行匹配，这是应用层次的管理，这是第一个阶段。

运维团队虚拟化

经过几年的团队建设之后，应用运维进入了虚拟化的阶段，我们以前叫什么中心，现在我们更喜欢两个披萨的原理，我们一个团队应该是用两个披萨就能够喂饱了，大概不超过8个人，我们成立了很多虚拟组，比如说根据业务功能去聚合，比如说存管、贷款、银联支付、报表组等等不同多个的虚拟组实现扁平化的管理。在IT服务管理流程层面，我们也组建了一个虚拟化的支持层，传统的变更管理、事件管理、问题管理等等，包括业务连续性管理，通过这个虚拟层提供一个协同。在工具方面我们做到了大数据、日志平台有专门的虚拟化小组去建设，现在做的是机器学习、可视化等等各种各样的场景，现在都在往这块转型和努力，这就是第二个阶段叫做虚拟化。

DevOps文化建设

现在正在做的，我们叫做运维前置，跟开发、测试团队达到虚拟DevOps小组，主要关注流程和工具链的建设、持续改进和优化，分析度量软件交付运行各环节，精益管理。现在这个团队由各个部门人员组成，推行一套统一化、标准化的流水线。实现在需求阶段测试运维需求，开发阶段就能够确定怎么样测试、部署，到生产阶段应用运维的团队能够持续的反馈给开发和测试，最终调整，实现一个闭环。

我们的小组虚拟化以后，有很多团队开始向DevOps的文化看齐，使用这种看板和站立会的方式，跟进日常的管理和项目交付，通过标签看到任务是怎么样流动的，在办公环境上也做了文化的宣传，比如持续交付、持续创新，大家在这个环境里面的变化和大家观念的统一。

整个DevOps虚拟化小组的推进过程当中推进了实施原则，主要是五个方面：

1. 流程的固化和规范化。规避原来开发人员手工做的事情，要做一些统一。
2. 审批的环节尽量不要手工填写，而是把各种各样的工具用上，就是上线审批的流程，实现完整性，避免数据收集的错误。
3. 在测试环节，不断地嵌入各种安全扫描测试工具，实现测试自动化，提高交付的质量。DevOps流水线现在的建设重点，就是怎么样实现可视化，怎么观测到我们的制品库。
4. 简单上云的标准化配置。
5. 通过流程与工程的创新，希望能够向DevOps最佳实践靠拢，希望能够建设一个统一的平台，连接开发、测试、运维的三个角色，能够打通需求、开发、集成、测试、运维的五个环节，从以前的铁路警察各管一段，走向共同的目标，最终实现高质量软件的快速缴费。