作者介绍

近期收到来自微众银行的赠书《新一代银行IT架构》。阅读之后，颇受启发。作为互联网银行的代表之一，微众银行在较短时间内，构建了全新的银行IT基础架构。相较于传统银行，其无论在架构理念，还是实践技术方面均非常有其特色。也为银行未来的发展，摸索出一条道路。

其通过高度规范的架构设计、灵活高效的运营体系、安全可控的技术体系有效减低运维成本；且具有容量、性能的无限扩展能力，满足业务上涨需求；同时其高度冗余设计实现了最高级别的可用性，确保业务连续性。可以说，微众银行的实践为提升金融机构信息安全水平，做出很好的实践，值得很多同业者参考学习；甚至可说具备一定的社会效益。

在规划整体架构之前，我们首先需了解业务，然后据此明确架构目标及科技发展战略。互联网银行在建设之初，就与传统银行存在诸多不同之处（如下表所示）。

可见其在覆盖人群、服务模式、服务理念等均有较大差异，这也对后续架构产生影响。从业务角度来讲，微众银行也据此确立了"普惠金融为目标，个存小贷为特色，数据科技为抓手，同行合作为依托"的整体战略定位。

作为与之辅助的科技发展战略，微众银行制定了"纯线上、轻人力、强系统"的科技发展战略。通过完全依托互联网作为客户服务渠道，由计算机系统提供的自动化服务替代传统的人工服务，规避线下渠道建设以及运营所带来的高昂成本，最终实现整体运营成本的大幅度降低、运营效率的明显提升。

在明确了业务战略定位及科技发展目标后，对于架构有了明确的要求。这里既有来自传统银行模式下，对高可用、安全、规范性的要求；也有来自互联网模式下，对高性能、高弹性、低成本的要求。整体可以将其概括为“四高两低”，即高性能、高弹性、高可用、高规范、低成本、低风险。可概括为下图：

银行需具备处理亿级存量用户及每日千万级交易量的能力。对架构的要求，可分解为：

• 整体容量，弹性可拓展，来支撑海量用户。传统银行的集中式方式显然不太适合，更多是考虑通过分布式技术，形成容量可线性扩展的架构。

• 吞吐能力，满足峰值要求。随着银行业务的互联网化，架构需应对来自大量碎片化的业务需求的冲击，需要考虑到扩展能力。

• 就单个请求而言，虽然相较于纯互联网业务，用户对时长的容忍度相对较高，但也是需要满足客户的直观体现需求。

   

在弹性方面，传统银行的Scale Up方式，显然已经走到了尽头。新一代架构，势必需要依托于分布式架构设计理念，有针对性地解决扩展性的问题。在扩展维度上，可考虑横向和纵向两个方向。

• 横向扩展，解决存量扩容；在控制单点容量下，随着业务发展扩展节点达到扩容。控制单点规模，对于稳定性、可用性等均有好处。

• 纵向扩容，解决单元性能问题，扩展处理能力。当业务出现变化，对单元处理能力要更要要求是，显然通过重新分片(resharding)，代价太大。因此在单元内，必须保留一定余力，可纵向扩容。后面会详细说明。

金融业务对RPO、RTO的严格要求，自不必说，是需要满足国家监管要求。互联网银行，对这一点还有其特殊性。相较于传统银行，互联网银行更强调面向社会提供7X24小时不间断的银行服务，这与其服务群体、服务形式有关。

银行基础架构，是很庞大、繁杂的体系。这需要在架构规划之初，就秉承标准化理念，因此来应对复杂运营维护工作。通过整体的高规范性，也有利于构建自动化、智能化的运维体系。

很多传统银行在IT架构上的投入是巨大的，其严重依赖外部（甚至国外）厂商不仅丧失了技术自主性，甚至连基本的商务议价能力也不具备。那么在新一代银行架构中，应秉承高性价比原则，充分运用低端计算计算和开源技术，有效地降低架构建设和后续运营的相关成本投入。

风险问题，是银行业基础架构的重中之重，在规划指出就应遵循下列原则：

• 依托高可用设计，减低风险发生概率；

• 发生风险时，需采取隔离机制，控制单点影响范围；

• 通过高效自动化的运维体系，快速恢复故障。

模块化是软件解决复杂问题所具备的手段，可降低软件的复杂性，减少开发工作量，从而降低开发成本，提高软件生产率。

"分而治之"的结论，把复杂的问题分解为很多容易解决的小问题，原来的问题也就容易解决，这就是模块化的依据。

当然，我们也要防止过度划分问题。当我们无限制划分软件，那么开发所需要的工作量会变得很小，但是其他因素开始起作用，整体成本不降反升。

如下图所示，开发单个软件模块所需要的工作量(成本)的确随着模块的数量的增加而下降，给定同样的需求，更多的模块意味着每个模块的尺寸更小。然而，随着模块数量的增长，集成模块所需要的工作量(成本)也在增大。这些特征导致其总成本的工作曲线成下述特征。存在一个模块数量M，可以导致最小的开发成本。一般无法预测M的值，但应该在模块化设计时尽量保持在M的附近，避免过高或过低的模块性。

通过上面的模块化设计，每个模块完成一个相对对立的子功能，并且与其他模块之间的关系很简单。模块的独立性是模块化、抽象、信息隐藏和局部化概念的直接结果，具有独立模块的软件容易开发、测试和维护。

模块的独立性通过两项质量标准来衡量：耦合和内聚。其中耦合是指不同模块间相互依赖的紧密程度；内聚是指模块内部各元素彼此结合的紧密程度。这里我们不谈内聚，重点谈谈耦合问题。

概念上来说耦合性是对一个软件结构内不同模块之间互连程度的度量。它取决于各个模块之间接口的复杂程度、进入或访问一个模块的点以及哪些信息通过接口传递。

1）耦合实践

模块的耦合方式从低到高依次是：非直接耦合->数据耦合->标记耦合->控制耦合->外部耦合->公共环境耦合->内容耦合。模块的独立性和耦合性正好是相反的，模块的独立性越低，耦合性越高。

耦合是影响软件复杂程度的一个重要因素。在设计中因采取下述原则：尽量使用数据耦合，少量使用控制耦合和特征耦合，限制公共环境耦合的范围；完全不允许内容耦合，最终降低模块接口的复杂性。

2）紧耦合 vs 松耦合

集中式紧耦合，是指由一台或多台主计算机组成中心节点，将数据集中存储于这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理。这是一种典型的业务集中、计算集中、数据集中的策略。

1）优点

• 部署结构简单；

• 保证数据一致性

2）缺点

• 随着业务复杂度的提高，模块间调用关系变得越来越复杂；

• 受限于单体资源，性能扩展性受局限；

• 可用性有限，风险集中，故障影响面大，单系统故障可能影响全部客户的所有业务。

从上面紧耦合拆分，将全量业务拆分成多个业务，由不同的计算节点分别处理，但每个计算节点处理的仍然是全量客户。集中式松耦合架构在一定程度上降低了集中式紧耦合架构的风险集中度，但是在整体可用性、性能和成本上，依然存在较明显的缺陷。

1）优点

• 精细控制，提升性能。通过把业务逻辑分散到不同计算节点来处理，提高整体性能。

• 可根据应用特性，选择不同的技术平台和技术框架，更好地提升自身的性能。

• 风险分散降低。在大部分情况下，可将单节点故障影响降低，出现故障时仅影响全部客户的部分业务、而非全局性业务影响。

2）缺点

业务之间的高度关联仍可能导致全局故障。

在集中式松耦合架构的基础上，横向切分集中式松耦合架构的部署方式，在每个节点上以客户为单位，部署用于支撑该客户群的全部应用系统。

每个应用系统在保持集中式松耦合架构的特性的同时，在每个客户服务节点中有独立的物理资源。在以客户为单位的分布式松耦合架构下，每个节点成为一个自包含的客户服务节点。

其中，一个客户的全生命周期数据集中的一个节点上；涉及单一客户的交易处理在单一节点上完成，节点间无依赖关系。

1）优点

• 有效降低单节点故障影响面，仅影响部分客户。

• 业务逻辑分散到更多计算节点来处理，系统整体性能进一步提升。

2）缺点

节点数量增加，增加管理难度。

在上述模式的局部处理单元，为了提升单元的数据可用性，可采取多种数据冗余方式。

最初是采用多主设计，这是一种较为“完美”的方式，但面临CAP理论在实现上的挑战。为了简化设计，后面采用单主设计，维护多个从节点，保证每份数据拥有多个副本从而实现架构整体可用性。在保证高可用的前提下，牺牲单节点的处理性能，但这样的设计模型可以规避CAP理论对整体架构的限制。

对于任何一份数据，在保证存储三个副本的前提下，仅由一个主节点对外提供读写服务；所有从节点与主节点之间依托现有网络技术，通过强化后的数据库同步机制实现与主节点间的数据同步，并对外提供只读服务。单主节点确保了在任何一个时间点对外提供数据的唯一性，强同步的多个从副本则确保了数据的高可用性。

1）优点

• 数据高度冗余，实现高可用性；

• 永远以主节点数据为准，有效规避CAP理论的限制。

2）缺点

• 实现主从节点间的强同步机制比较复杂。

• 牺牲了单个集群性能。但分布式架构的精髓就是通过集群效应实现架构整体的高性能而不追求单机、单集群的高性能。因此，可通过进一步扩大集群规模，弥补性能的损失。

在分布式松耦合一主多从多副本强一致的架构下，每个节点承载一个独立客户群体。节点之间的客户群上不重叠，一个客户的整个生命周期只会在一个节点上进行处理和存储。节点之间不共享物理资源，从而实现最大程度的独立性。

每个节点服务全行客户中的一个客户子集，具备服务所承载客户群所需的全部技术支撑能力，能够存储该客户群所有客户的全部数据。所部署的应用系统，在应用层面采用松耦合部署，不同应用域的应用系统不共享物理资源；在数据层面，采用一主两从强同步架构实现数据的高可用性，同时还能规避CAP理论对分布式架构的限制。

新一代架构中分布式的核心理念为去中心化，去除任何可能影响所有业务的所有客户的任何类型节点的存在。即使出现了整个节点不可用，也不会影响整个银行的客户。

1）优点

• 按客群拆分计算节点，有效减低单节点故障影响面，控制运营风险。

• 将业务逻辑分散到多个计算节点来处理，实现高性能要求。

• 一主两从节点实现数据高度冗余，满足高可用要求。

• 以主节点数据为准，有效规避CAP理论的限制。

2）缺点

• 在同等业务复杂度下，为了支持同等规模的客户群，一个有N个节点的新一代分布式松耦合一主多从强一致架构的复杂度有了很大提升，其节点数量是传统银行架构的N倍。这需要配套自动化管理工具来做支撑，降低管理复杂度和提升运维效率。

• 需要健全数据库技术，实现高效率的数据强同步机制。

1）数据高可靠性

相较于传统商用数据库依赖高端存储技术实现数据可靠性，分布式数据库在数据可靠性维度上的核心设计思想是基于数据冗余，并兼顾同步中和同步后的数据一致性状态。一份数据有一个主副本和多个从副本，主从副本之间通过三项主要的技术实现数据的一致性。

2）系统高可用性

分布式数据库系统高可用性的核心设计思想是：基于故障-停止机制优化故障探测时间和故障转移时间。探查方面，故障探测基于"心跳+租约"的方式，同时通过SQL服务质量来发现节点的亚健康状态。故障转移，则通过多种并行方式提升绝大部分场景下应用同步日志的速度，减少目标恢复时间。

3）高性能处理

分布式数据库高性能事务处理能力除了通过多种业务场景下的MySQL参数调优以及定制服务器配置外，还能给予开源版本内核深度定制。分布式数据库通常在SQL层和InnoDB引擎上进行相关优化，从而提升事务处理能力。

4）运维管理

分布式数据库的运维管理主要包括数据库管理、备份回档、弹性扩展、线上调优、安全审计和成本控制六个维度。通过上述建设，可以大大减少DBA的工作压力和面临风险，让他们更加聚集于业务本身，从而提升整个业务链路的质量。

分布式缓存是一种基于内存/高性能SSD介质的数据存储服务，是分布式系统中的重要组件，主要解决高并发、大数据场景下，热点数据访问的性能问题，提供高性能的数据快速访问能力，减轻关系型数据库的压力。

提供分布式的块、文件、对象存储能力。做到灵活扩展、高性能、数据可靠的同时，尽量实现低成本。

提供分布式的消息队列服务，其需保证消息数据的可靠，整体服务高可用，同时具备容量、性能的扩展能力，并可应对跨数据中心的出散户需求。

提供多形式、多层面的分布式负载均衡服务。

银行要认识到核心业务系统技术替代的重要性和必要性；面对新的技术浪潮，要采取积极的应对措施，实施IT战略转型。银行需要 从业务视角出发重新思考IT和业务的关系，提高业务系统的敏捷性，实现业务和IT的融合；在控制风险的同时，尽可能"多、快、好、省"地为业务创造价值。

在很多技术领域，银行已经落后于互联网公司。现在应该放下身段，虚心向互联网公司学习云计算和分布式技术，结合银行业务系统的特点，改造其核心业务系统。

从技术上说，实施替代的难点在于同现有技术体系的融合，是全盘替代还是部分替代。此外，替代项目的实施管理难度也很大。在管理上，需要认识到来自方方面面的组里，既有技术人员和业务人员因循守旧和技术偏好带来的抵触情绪，也有可能来自厂商及其代言人处于商业利益的阻挠、恐吓和游说。因此，替代工作要获得上级主管部门、银行高层领导的大力支持，方能顺利实施。

大胆设想，小心求证。银行既要看到云计算和分布式技术的巨大潜力与优势，也要重视可能存在的弱点和不足，特别是要充分评估业务和客户体验造成的影响。银行要认真对核心业务进行梳理和分析，识别银行业务相对于互联网信息处理在交易一致性、安全性等方面的更高要求。要对各种分布式处理技术进行充分的分析评价和测试验证，做好技术选型和架构设计。

为了有效控制引入新技术的风险，因遵循"先试点，后推广"的过程。在试点过程要完善新平台技术架构，制定实施工艺和规范，形成开发和运行工具；特别是对云计算和分布式处理方面的开源软件进行学习、消化和吸收，组建一支技术过硬的互联网分布式架构开发队伍，为实现技术路线的全面转型做好准备。