微众银行 IT 架构治理实践与思考

作者 | 董小峰 微众银行应用架构管理团队负责人
来源 | 微众银行

在当今数字化时代，各行各业都面临着运营事件和生产故障的挑战，如何保障系统的高可用性成为亟待解决的问题。在 6 月举办的 ArchSummit 全球架构师峰会·深圳站上，微众银行应用架构管理团队负责人董小峰分享了微众银行整体的 IT 架构与架构管理的实践成果，以及保障系统架构高可用性的实践经验，洞察行业发展趋势，帮助企业构建更加稳定、可靠、灵活的 IT 架构，应对数字化时代的新挑战。

据了解，微众银行是国内首家实现核心系统“去 IOE”的银行，从成立之初便基于“开放蜂巢 Openhive”技术，利用标准化硬件和开源软件，构建了国内首个基于安全可控技术的全分布式银行系统架构，成功建立了同城多中心多活架构。其高可用、高弹性、高扩展的特点使得微众银行能够支持海量客户规模及高并发的交易量。

微众银行的架构治理体系

 行业洞察与背景

各位行业专家不断努力，技术不断演进。从单体应用到远程调用，再到序列化 RPC、RPC 治理，逐渐发展出 SOA 架构和微服务架构，后来又有虚拟化技术、容器化技术，随后诞生了 Kubernetes（简称 K8S）。有了 K8S，如何有效管理容器集群、监控系统的可观测性成为新的关注点，相应的开源工具也日益丰富，极大地便利了监控工作。正所谓“八仙过海，各显神通”。

然而，去年下半年一直到年底，业界更加广泛地关注如何降低成本，然而也出现了各种各样的生产问题。尽管行业专家众多，系统问题仍频繁出现，有种“常在河边走，怎能不湿鞋”的感觉。金融行业同样面临这些挑战。那么，我们该如何解决这些难题呢？

 微众银行所面临的挑战

从一件小事说起，客户对银行最基本的期望是，当客户今天存入 100 块钱时，几天后在银行 APP 或到柜台查看时，这 100 块钱依然在账户里，并且利息也有所增加。客户不希望存入两天后资金减少。客户还希望随时可以取出这笔钱，无论是在 APP 还是在柜台都能立即办理。

在互联网时代，这种即时性需求更为强烈。例如，在 520 或 618 大促期间，如果银行提示客户“现在是业务高峰期，请稍后再试”；春节期间，客户本该能立即发送的红包却无法成功发送，那么客户必然会感到不满。所以银行必须确保客户能够即时完成这些操作。

从客户对银行最基本的期望来看，已经涵盖了银行所面临的挑战。这些挑战对银行有如下要求：

1. RPO 等于零：数据不能丢失，无论是账务数据还是交易数据。
2. RTO 接近于零：客户期望银行的服务能够做到 7 x 24 小时在线，随时可用，即使在业务高峰期也能立即完成交易，并实时查看资金情况。
3. 不可忽视的硬件故障率：自十年前成立以来，微众银行经过持续发展，有效客户数量接近 4 亿，客户数据增长速度惊人。服务器数量和数据库容量也呈爆炸式增长。
4. 变更频繁：微众银行每年都要进行上万次的生产变更，涉及版本、配置、网络等多个方面，主要来自于业务需求的变化。随着客户数量的不断增加，客户的要求也越来越高，对于业务方面的需求也在不断变化。

架构治理体系的构成

微众银行为了确保其架构系统稳定运行，建立了完善的架构治理体系。

首先，架构管理委员会负责制定架构规范，各团队架构师需遵循这些规范或最佳实践来设计架构方案。设计完成后，方案会提交评审，架构管理委员会依据既定原则进行审查和校验，以确保架构资产遵守相应原则。方案符合要求，便会被定版并正式发布到架构资产库中。

在实施阶段，无论是申请资源还是申请服务调用，都需要验证架构资产的设计态是否与所申请的资源信息相符。若验证通过，即可将其发布到生产环境运行，还会对比运行态与设计态的架构数据，进行一致性校验。

在与各个产品部门沟通的过程中，可能会遇到一些特殊情况，若不采用特定的架构方案，成本可能会激增。针对这类情况，即使某些方案不完全符合既定的架构原则，为了控制成本上涨、加速业务上线，也可以通过登记架构例外的方式，允许特定场景下的系统搭建实施，以此避免成本上涨或加速业务上线的需求。

 组织架构：基于集中管控的分布式

在微众银行科技团队的组织架构下，设立了架构管理委员会。该委员会由科技团队的 CIO 以及各部门领导组成。架构管理办公室下还有来自各部门的架构师团队，包括基础架构师、应用架构师和系统架构师。

基础架构师主要归属于基础科技团队，负责提供 IaaS 层和 PaaS 层的组件。系统架构师则来自各部门，负责各自部门的设计和开发工作。应用架构师通常是各部门中经验丰富的架构师，对自己本部门和所负责领域的应用系统技术架构有深入了解。

在评审流程中，系统架构师会提出某个系统或产品的架构方案。这个方案会先经过应用架构师的初步审核，然后再提交给架构管理办公室进一步审核。架构管理办公室负责组织和发起架构评审，接着评审团队的成员根据各自领域的管理要求来审核架构方案。

每个科技产品部门（包括财富、贷款、存款业务等不同科技产品部门）都设有自己的科技产品经理、开发团队、测试团队和运维团队。每个部门对其所有的信息系统的设计、开发、测试和运维质量负责。

职能型的横向管理部门（包括信息安全团队、合规管理团队和架构管理团队等）都会向所有的科技产品部门提出自己的管理要求，同时也作为服务团队，提供必要的支持工具，帮助各科技产品部门满足管理要求。例如，科技运营团队会要求所有发布都通过指定的发布工具进行，并确保所有系统都具备标准的启动和停止脚本。启停脚本的应用并不局限于特定场景，而是广泛应用于各种场景。

 架构设计的指导原则

微众银行在架构设计过程中遵循六大核心指导原则：

1. 高性能：微众银行作为一家互联网银行，既具备金融属性又具备互联网属性，必须具备高性能以支持庞大的客户群体和高并发交易量。
2. 高弹性：系统容量必须具备高弹性，包括横向和纵向扩容能力，以适应业务增长。
3. 低成本：高弹性的根本出发点也是出于成本考虑，架构设计时要兼顾成本。
4. 高可用：银行的服务必须是高可用的，确保系统局部故障时对用户的影响微乎其微。
5. 低风险：必须有效控制银行系统的风险，确保维持绝对的低风险。
6. 高标准：所有系统必须遵循统一的高标准，以实现运维的标准化和管理的规模化。

为了确保行内系统的可靠性，微众银行内部制定了一系列架构规范、标准和原则，并整理了最佳架构实践案例和反面案例以供参考。

 架构设计资产

架构设计资产涵盖多个关键组成部分，如子系统、数据中心 (IDC)、网络区域、数据中心节点（DCN）、上下文图、逻辑部署图等。子系统是最小的部署单元，也是架构管理的最小单元。通过有效管理每个子系统，并通过服务互联，构建整个架构资产的大框架，建立以子系统为核心的架构管理体系。

出于安全和架构规划的考虑，数据中心被划分为多个网络区域，这些网络区域也是架构资产的一部分。同时，为了方便架构管理、清晰展示架构图，以及帮助开发人员和测试人员更好理解架构工作，将一个网络区域划分为多个逻辑部署区域。DCN（data center node），是一个逻辑部署单元，不同的 DCN 用于放置不同产品的业务系统。

 架构的实施与监控

当架构方案通过评审后，架构图会被上传到我们的 DE（架构设计平台，用来管理绘制架构图的系统），其它架构资产都会被录入到 CMDB（配置管理平台） 中。微众银行对 CMDB 的应用非常深入，我们要求 CMDB 记录所有 IT 配置信息，包括 IDC、网络区域、DCN、系统、子系统，还有服务治理调用关系、防火墙策略以及创建的应用实例等。

将系统部署到生产环境的过程中，需要申请服务器、防火墙和其他 IT 资源工具系统会基于 DE 和 CMDB 上的数据验证设计是否符合要求，申请的信息是否准确。验证过程并不只是简单地核对填写的信息。如果提交的方案与上下文图不匹配，将无法提交相关网络策略申请。工具系统需要确保选择正确的上下文图，然后才能申请相应的访问策略。

工具系统是否能自动申请资源，这是一个值得探索的方向。目前安全团队和网络团队都有自己的顾虑，安全团队可能会担心自动开通策略存在安全风险，而网络团队则担心直接在生产环境中自动进行变更可能带来风险，目前还在逐步探索中。

还有一些规范内化到工具系统的代码逻辑中，实现无感管控。如申请服务器资源时物理上的分散性规则：在申请 10 台虚拟资源或者容器的时候，系统会自动将这些资源分散配置，不会让它们集中在同一个物理机、机架或者网络交换机，更不会让它们集中在同一个 IDC，会确保每个 IT 资源单元至少有 50% 的资源不会集中到任何一个物理单元上去。

内部开源共建

微众银行内部建立了一个完善的全生命周期架构管控体系。管控体系也离不开工具系统的支持，而建设这些工具同样需要投入大量的人力。

关于如何解决这个问题，微众银行积累了一些经验。在 Apache 项目中，微众银行贡献了两个顶级开源项目——Linkis 和 Event Mesh，这一过程中培养了内部的开源文化。借鉴在 Apache 开源项目上的操作经验，微众银行开始积极推动内部的开源工作。

例如，在设计 API 协议时，我们使用 OS 3.0 的工具来描述协议，将协议设计工具集成到内部工具平台中。如果出现人手短缺的情况，B 部门可以选择自行下载代码进行定制开发，以满足他们的紧迫需求。A 部门也可能会基于 B 部门的代码进行二次开发，或者多个部门进行合作，共同开发、改进工具系统。这种做法有助于不同部门更好地协作和资源共享。管理部门负责全部工具系统的开发，各个部门都主动承建了一部分。这不仅解决了人力不足的问题，还解决了管理部门开发的系统不被其他部门接受的问题，也解决了各部门之间协调冲突的问题。

微众银行的运营现状与核心技术解析

微众银行在当前架构管理体系下的运营情况：目前微众银行的服务器支持大约 3000 个子系统，在数万台服务器上运行，截至 2023 年 11 月，微众银行的有效客户数量已接近 4 亿。而在交易方面，我们日交易峰值约 10 亿笔。 这些数据显示出微众银行在处理大量交易方面的能力。在这种高交易量的背景下，微众银行关键产品的综合可用率达到了持续超过五个 9 的电信级高可用水平。

接下来，简要介绍微众银行几个核心技术关键点：

• 首先是数据库方面。采用的是腾讯的 TDSQL 数据库。微众银行会选择三个数据中心部署一套数据库，每份数据的三个副本分别存放在不同的数据中心中，确保即使一个数据中心出现故障，数据也不会丢失。数据中心之间采用强同步机制来保持数据的一致性。主节点故障时大约是 30 秒的切换时间。如果是由运维人员主动关闭主节点进行逐步漂移，大约只需要 15 秒钟就可以完成切换。

第二个是消息中间件，所有业务系统都通过一条虚拟的总线进行通信。微众银行基于 RocketMQ 进行二次开发，自研了 WEMQ，现在又自研了一套 MASA 服务网格架构。不论使用何种方式，其目的都是处理系统间的交互任务。开发人员只需编写简单的代码，系统就能自动找到所需的服务，无论这些服务被部署了多少个实例，无论它们被部署在何处。即使部分服务实例出现故障或挂掉，系统也能通过自动发现、负载均衡、容错和熔断等机制找到所需的服务，确保整体服务的可靠性和稳定性。这种架构极大地降低了分布式系统的复杂性和维护成本，让用户能够更专注于业务逻辑的开发和创新。

最后一个是 DCN。数据库的三副本和应用的多活部署，确保服务能跨两个集群保证高可用性。DCN 之间采用单元化架构，以微众银行的微粒贷产品为例子，每个 DCN 负责数百万客户，当一个 DCN 故障时，另一个 DCN 的客户不受影响。这种架构实现了故障隔离，减少了潜在的影响。DCN 的隔离不仅仅局限于客户级别，外联区域如 DMZ、ECN 和 BDP 也被视为一个 DCN，并按照相似的架构进行管理。

总结与展望

微众银行目前正在积极探索一项颇具挑战性的课题：异地多活。与常见的异地容灾项目不同，我们不是在距离一两百公里的地方建立备份，而是尝试在大约 1000 公里左右的距离进行异地多活部署。更进一步的是，我 们现在所追求的目标不仅仅是简单的异地备份和启动，而是希望能够在两个间距 1000 公里左右的数据中心同时提供客户服务。

微众银行一直在不断地探索和尝试，致力于突破其中的技术难题，为客户提供更加稳定、可靠的服务。