探索 IT 架构治理之道：微众银行的实践与思考_AI阅读总结 — 包阅AI

以下是分享内容（经 InfoQ 进行不改变原意的编辑整理）

各位行业专家不断努力，技术不断演进。从单体应用到远程调用，再到序列化 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 的电信级高可用水平。

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

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

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

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

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