探索 IT 架构治理之道：微众银行的实践与思考
在当今数字化时代，各行各业都面临着运营事件和生产故障的挑战，如何保障系统的高可用性成为亟待解决的问题。在 6 月举办的 ArchSummit 全球架构师峰会·深圳站上，微众银行应用架构管理团队负责人董小峰分享了微众银行整体的 IT 架构与架构管理的实践成果，以及保障系统架构高可用性的实践经验，洞察行业发展趋势，帮助企业构建更加稳定、可靠、灵活的 IT 架构，应对数字化时代的新挑战。 据了解，微众银行是国内首家实现核心系统“去 IOE”的银行，从成立之初便基于“开放蜂巢 Openhive”技术，利用标准化硬件和开源软件，构建了国内首个基于安全可控技术的全分布式银行系统架构，成功建立了同城多中心多活架构。其高可用、高弹性、高扩展的特点使得微众银行能够支持海量客户规模及高并发的交易量。 以下是分享内容（经 InfoQ 进行不改变原意的编辑整理）微众银行的架构治理体系 行业洞察与背景各位行业专家不断努力，技术不断演进。从单体应用到远程调用，再到序列化 RPC、RPC 治理，逐渐发展出 SOA 架构和微服务架构，后来又有虚拟化技术、容器化技术，随后诞生了 Kubernetes（简称 K8S）。有了 K8S，如何有效管理容器集群、监控系统的可观测性成为新的关注点，相应的开源工具也日益丰富，极大地便利了监控工作。正所谓“八仙过海，各显神通”。 然而，去年下半年一直到年底，业界更加广泛地关注如何降低成本，然而也出现了各种各样的生产问题。尽管行业专家众多，系统问题仍频繁出现，有种“常在河边走，怎能不湿鞋”的感觉。金融行业同样面临这些挑战。那么，我们该如何解决这些难题呢？ 微众银行所面临的挑战从一件小事说起，客户对银行最基本的期望是，当客户今天存入 100 块钱时，几天后在银行 APP 或到柜台查看时，这 100 块钱依然在账户里，并且利息也有所增加。客户不希望存入两天后资金减少。客户还希望随时可以取出这笔钱，无论是在 APP 还是在柜台都能立即办理。 在互联网时代，这种即时性需求更为强烈。例如，在 520 或 618 大促期间，如果银行提示客户“现在是业务高峰期，请稍后再试”；春节期间，客户本该能立即发送的红包却无法成功发送，那么客户必然会感到不满。所以银行必须确保客户能够即时完成这些操作。 从客户对银行最基本的期望来看，已经涵盖了银行所面临的挑战。这些挑战对银行有如下要求： RPO 等于零：数据不能丢失，无论是账务数据还是交易数据。 RTO 接近于零：客户期望银行的服务能够做到 7 x 24 小时在线，随时可用，即使在业务高峰期也能立即完成交易，并实时查看资金情况。 不可忽视的硬件故障率：自十年前成立以来，微众银行经过持续发展，有效客户数量接近 4 亿，客户数据增长速度惊人。服务器数量和数据库容量也呈爆炸式增长。 变更频繁：微众银行每年都要进行上万次的生产变更，涉及版本、配置、网络等多个方面，主要来自于业务需求的变化。随着客户数量的不断增加，客户的要求也越来越高，对于业务方面的需求也在不断变化。 架构治理体系的构成微众银行为了确保其架构系统稳定运行，建立了完善的架构治理体系。 首先，架构管理委员会负责制定架构规范，各团队架构师需遵循这些规范或最佳实践来设计架构方案。设计完成后，方案会提交评审，架构管理委员会依据既定原则进行审查和校验，以确保架构资产遵守相应原则。方案符合要求，便会被定版并正式发布到架构资产库中。 在实施阶段，无论是申请资源还是申请服务调用，都需要验证架构资产的设计态是否与所申请的资源信息相符。若验证通过，即可将其发布到生产环境运行，还会对比运行态与设计态的架构数据，进行一致性校验。 在与各个产品部门沟通的过程中，可能会遇到一些特殊情况，若不采用特定的架构方案，成本可能会激增。针对这类情况，即使某些方案不完全符合既定的架构原则，为了控制成本上涨、加速业务上线，也可以通过登记架构例外的方式，允许特定场景下的系统搭建实施，以此避免成本上涨或加速业务上线的需求。 组织架构：基于集中管控的分布式图片在微众银行科技团队的组织架构下，设立了架构管理委员会。该委员会由科技团队的 CIO 以及各部门领导组成。架构管理办公室下还有来自各部门的架构师团队，包括基础架构师、应用架构师和系统架构师。 基础架构师主要归属于基础科技团队，负责提供 IaaS 层和 PaaS 层的组件。系统架构师则来自各部门，负责各自部门的设计和开发工作。应用架构师通常是各部门中经验丰富的架构师，对自己本部门和所负责领域的应用系统技术架构有深入了解。 在评审流程中，系统架构师会提出某个系统或产品的架构方案。这个方案会先经过应用架构师的初步审核，然后再提交给架构管理办公室进一步审核。架构管理办公室负责组织和发起架构评审，接着评审团队的成员根据各自领域的管理要求来审核架构方案。
页:
[1]