【51CTO.com原创稿件】导言
在互联网金融快速发展的当下,面对爆发式增长的数据量、高并发海量交易场景，传统集中式架构的性能瓶颈愈发凸显。基于此,越来越多的银行等金融机构近年来逐步关注和应用分布式架构。受51CTO企业学院邀请，微众银行科技合作支持部架构师刘力在第十一期“技术大咖面对面”中带来了相关演讲《微众银行：分布式架构之高可用》。特此整理，以飨读者。
正文
我将基于微众银行的实践经验，把我们的设计思路和做法分享给同业，希望可以和大家交流，共同在金融科技领域取得进步。
今天的分享内容主要集中在三个方面：第一，微众银行的分布式架构的设计思路；第二，分布式的核心系统是如何来匹配分布式架构的；第三，基于分布式架构的运维管控如何进行。此外，我也会就微众银行的分布式架构和微服务之间的关系进行解释。
01 分布式架构的设计思路
1.1 整体原则：通过架构实现安全可控，解除对底层技术的依赖
建设分布式架构的前提：作为第一家民营互联网银行，微众银行起步比较晚，没有太多历史负担；出于合规限制，当时获准的筹建期是六个月，初始资本为30亿；定位是普惠金融，因此需要全面降低成本。
纵观这些前置条件，可以看到启动资金的规模意味着我们在进行IT建设时天生不具备采购IOE的条件，普惠金融的定位在某种角度上意味着成本控制和底部组件的设定基本已确定。基于这一情况，我们从设计角度定义了三个不同原则：
其一，坚持技术通用性，不被单一厂商锁定；
其二，极简主义。尽量采用稳定成熟的技术，不依赖技术性能来完成整体的性能指标；
其三，依靠可控的。对一家金融机构的IT部门来说，从架构角度出发，可控的主要是架构规划以及业务系统相关的程序代码。其他无法独立研发完成的部分就通过技术通用性来解决。
对于提供技术支持的厂商，我们希望他们的解决方案尽量白盒化，尽可能采用开源组件，开源社区本身具备一定的通用性，厂商自身有比较核心的研发能力。另外需要明确的一点是，如果计划用X86来完成分布式架构，就要默认你的底层技术和系统是不稳定的。如何通过运维手段来面对和解决这种不稳定性也是需要提前在设计中有一定规划的。
1.2 安全可控的核心技术建设理念：通过XML实现安全可控
下面将具体说明为了实现安全可控，我们如何设计搭建分布式架构。
主机：一般情况下，由几十到一百台X86服务器组成1个固定集群。这样1个单独的集群在分布式架构里也可以理解为1个单元。这个服务器集群提供应用计算服务、数据库服务和存储服务。我们通常也称之为数据中心的1个节点，这种单元化的节点在我们内部被命名为DCN（后文将有所提及）。
数据库：我们需要一个基于MySQL，至少是与其高度兼容的数据库。而这个数据库的特点在于——设计原则秉持“三幅本强同步”（稍后详述）；数据放在本地磁盘上，而不依赖存储；实现自动化的故障监控和恢复。
其他技术：目前基本上是以Linux和KVM为代表的开源技术的组合，来完成整个底层的支撑。
1.2.1 数据库选型：以客户为单位的分布式松耦合单主多副本强同步架构
关于数据库选型，我们当时选择的是腾讯TDSQL数据库。在实践过程中，我们发现所有分布式架构的设计实质上就需要对你的客群或者业务来进行划分。
传统银行的IOE架构，程序基本运行在一、两台主机服务器上，数据一致性没问题，但在需要扩容的时候，更换硬件、数据迁移都极为复杂，闲置和风险都比较高。相对地，很多互联网企业在数据库优化中会进行分库分表，全量的分布式方式会获得很好的灵活性和扩展性，但数据一致性很难保证，而且金融业务的安全性和稳定性要求比一般的互联网业务也要高。综合来看，这两种模式就是各有千秋，所以我们思考的是能不能设计一种架构结合两者的特点。
基于这种考虑，我们采用了分布式松耦合架构。首先把所有的分布式节点按客群和业务两个维度做一次划分，即每个数据中心的分布式节点只支持一部分客群，也只支持某一类型的业务。其次在数据库层面，我们选择采用一主两从的节点强同步结构，以此来保证数据的最终一致性。
这样做的优势是：按客群拆分计算节点，每一个节点只支持部分客群，有效降低了单节点故障影响面，同时能够控制运营风险；业务逻辑分散到多个计算节点上去，实现高性能要求；数据层则通过一主两从的方式来实现数据高度冗余，满足高可用性要求；我们默认情况下会是以主节点的数据为主，来规避CAP理论的限制。
这样做的负面影响是：需要配套自动化管理工具，降低管理复杂度，提升运维效率；需要健全数据库技术，实现高效率的数据强同步机制。
1.2.2数据中心节点的分布逻辑：通过DCN架构构建全分布式银行系统
微众银行的数据中心节点的分布逻辑即：按客户维度拆分多组DCN，每组DCN只会支持一定容量的客户，客户数量增加时复制部署DCN即可，一组DCN会在同城的不同数据中心有三个或三个以上副本。
简单来说，每组DCN就像微众银行的1个分行。比如拆出100个节点就相当于开了100家小分行，而这100家小分行任意一个节点出现问题，都不会影响到全量业务或者客群。如此一来，就相当于把所有的业务和客群打散到了所有的分布式的小节点里面去。且每个分布式节点的规格、计算资源和数据库的定义也是标准的。
1.2.3 实践用例：微众银行分布式架构整体逻辑视图
如何进行分布式节点的客群分配呢？我们有一个专门的组件叫GNS（Global Naming Service），是整个以客户为单位的可控分布的核心。这个组件会在每个用户进来时自动分配1个GNS编号。这个GNS编号有一定的编写规则，会为新用户分配1个分布式节点，以后新用户相关的业务处理和数据保存基本就会固定在这个节点上。后续业务处理过程中通过查找GNS编码就会马上找到用户所在的节点。如果每个DCN节点的配置都固化下来就非常有利于做横向扩容。随着用户规模增长需要，只要固定地增加DCN节点就可以进行，系统处理能力就可以无限横向扩展。
1.2.4 微众IDC 2.0架构：同城六中心多活+异地灾备
当前在微众银行IDC2.0的架构中实现同城多活的方法，跟DCN节点的设计也密切相关。首先我们有一个全局的负载均衡机制，业务从外网进入后会被分配到某个数据中心。业务接入后会通过消息通道进行处理，进而访问到后台不同的业务应用，最后落入主库进行所有的写库操作。万一出现问题，不管是外网访问的问题、应用问题还是数据库的问题，在IDC故障时，备库会切换成主库来承担数据库的读取和写入。数据库的切换机制速度极快，因为每笔业务在操作中写完主库后会再写两个副本，这两个副本分布在不同的数据中心。这个步骤完成后才会反馈到用户，继续下面的业务流程。
由此看到，微众银行实际上是把同城多活的机制交由数据库本身的高可用机制来完成。这种做法的优点在于，它并不依赖底层硬件的同步来完成，只用数据库的机制来进行，大体可以实现RPO等于0。达成这样一种状态：业务基本不会发生中断，但RPO会有秒级切换。
1.2.5 通过消息总线路由机制实现高效稳定的同城多活架构
如何通过消息总线的路由机制来实现高效稳定的同城多活架构？
首先，微众银行有一个基于消息总线的分布式架构数据骨干。总线实现系统间通讯解耦。通过总线隔离机制，配合网络隔离，实现法人间消息流转控制。总线提供服务端负载均衡、限流、熔断等保护机制，确保海量交易下服务的稳定性。
其次，交易尽量在本地处理。消息路由优先选择本数据中心内的服务，减少跨数据中心的调用，降低交易延迟。
再者，赋予消息队列灵活的路由寻址能力。使用消息地址定位组件，在系统间调用时提供消息寻址能力，避免应用代码逻辑和服务部署地址的耦合。
最后，严格控制消息交换。支持跨法人消息路由，但通过服务治理，严格控制权限及策略。默认不可通讯，按需开通消息路由，避免不恰当的调用。
02分布式核心设计分享
这一部分的主要内容是关于分布式核心系统如何与分布式架构来结合。
2.1互联网银行微核心分布式特性
目前微众银行的互联网核心系统，包括存贷核心、信用卡核心都是完全由微众银行自研的。因此我们在做核心系统的分布式时，其实进行了拆分。第一个拆分是我们的核心功能需要是分布式的。第二个是业务特性需要是分布式的。第三个是系统性能也需要是分布式的。
2.1.1微核心 – 基于核心功能的分布式
我们当时在做核心和账户体系设计时希望功能能够实现分布式，因而很早之前我们就对一些核心系统做了功能拆分。举例来说，我们会把存款核心的边界缩小到账目核心和记账的角度，在这之上的组合交易层，诸如支付、头寸管理、反欺诈等部分会以单独的功能来存在。这样一来，设计产品时在合适的功能里面进行组合即可。换句话说，我们尽量把一些通用性的功能变成服务型的、平台型的能力。
可以看到，这个设计思路跟微服务的逻辑非常相像。实际从服务和分布上来讲，微众银行内部已经非常接近于用微服务的逻辑在建设所有的系统和子系统，只不过现在的这些系统间的通讯是通过消息队列来完成的。至此我们可以说已经做到了基于功能的分布式。
2.1.2微核心 – 业务特性的多核心分布
基于业务特性的分布式处理也是出于更好地适应业务发展的考量。因为很多系统在诉求方面其实有显著差异，比如网银app的常见场景是，客群变化不大，并发数量不大，但要求是能看到全局的产品，给用户展示更多的内容。但如果是对接微信零钱通这样的互联网场景，对用户来说这就只是一个单一入口，其他产品形态、用户信息都不是他感兴趣的。这个流程的特点就是交易极高频，但整个流程非常简单。海量场景下需求总是多样化的。
后来我们发现没有必要把所有东西都放到一个核心上去。比如存款核心系统，这个核心系统某一个版本的系统就对应某一种业务，比如存款核心2.0可能专门对应通用存款，3.0版本可能对应高频交易场景，3.1版本可能对应同业之间的合作存款。不同版本的核心对应的是不同的业务产品，从这一层面来说基于业务特性实现了分布式。
对于我们来说，互联网核心可以被拆开，也可以被迭代，也可以成长，也可以消亡。
2.1.3基于微核心的技术体系互联网核心
性能的解耦也就是前文提到的，通过DCN节点的方式来做解耦，进而实现其横向扩张和纵向扩张。总之，从功能到业务特性到性能都可以来实现解耦，因而微众目前的架构就是，我们的产品要选择合适的微核心组件，对应到这个产品的交易库后就可以让这个产品跑起来，跑起来后可以把所有信息再汇总。每个产品都有自己的交易库后，这个交易库最终的数据工具会在行业级的大数据平台再一次汇总，以供实时查询、数据统计等需求。
一言以蔽之，在构建分布式核心系统的同时要在最后通过大数据平台采集和汇总数据，来实现银行视角的管理和满足监管要求的诉求。
2.2 应用级分布式事务实现
在没出现微服务的概念，没有成熟的框架可以依赖时，我们当时为了保证事务一致性，选择在账户层，即每个互联网核心里来实现应用级的分布式事务。
这个实现逻辑是：服务发起者确保发起的子事务的状态一致性；服务处理方提供相应的异常处理接口，供调用方在异常状态下使用；同步异常处理或登记差错登记表并触发预警。在交易的处理流程上，尽量先做业务检查，再做业务处理，降低事务异常的概率。一致性可以通过统一的分布式事务管理中间件来实现，也可以通过应用代码来实现。
03 分布式架构管控工具体系
最后简要介绍一下分布式架构的管控体系。
3.1 分布式架构管理运维发展路径
分布式架构对于管理运维带来了四大挑战。其一，经验丰富的运维工程师成本高并依然有出错的可能；其二，架构规模大，当下微众银行管理的服务器已经超过一万两千台了，应用节点更多，如果加上虚机的话可能会更多，此外可能还包括一些容器的管理；其三，7/24不间断营业对业务连续性有严格的要求；其四，分布式核心体系同时运行超过90套核心系统服务全行客户，版本配置管理，灰度发布等工作量大。这些挑战对运维的标准化、自动化、智能化提出了更高的要求。
3.2 强化运维体系建设，突出自动化智能运维能力
我们有一套非常严格的运维工具、体系和管理办法。我们当时最重要的一个标准是——如何保证从架构设计驱动来进行运维管理。这就要求从架构设计开始就要把运维的逻辑考虑进去，而且架构做完设计以后到最终系统上线的运行态要求尽量一致。另外还要遵循这样四条原则：
练好外功。建设面向运维的自动化工具集，提高运维效率，降低人力成本以及人为可能造成的失误。
练好内功。从架构设计驱动运维上线，设计态到运行态的信息流闭环。
保证信息的准确性。不单是技术平台层（IaaS/PaaS）信息的管理，也要结合SaaS层信息，包括系统、服务等信息，确保从设计到运维的落地的一致性。
保证信息的准确性。对每项数据明确负责组织，建立数据校验机制，保证信息的准确性。
除了运维体系建设以外，目前在AIOps的领域我们也做了一些工作，包括一些容量预估和生产异常的根因定位。微众银行成立至今的运维数据都在，我们实际上可以把这些运维数据来做一个建模，以此来识别一些异常的定位和做一些根因的分析。目前来看，多层AI算法模型识别的准确率可以达到90%以上，而根因定位准确率也接近70%，都可以用来减轻人为运维的压力。
【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】
