互联网金融科技一直存在着传统金融属性（高可用、高标准、大风控）和互联网属性（高性能、弹性伸缩、低成本）看似矛盾的特点。新一代互联网金融弹性架构基于云计算技术，通过单元化拆分，LDC 级别的自封闭，金融级数据库可靠性，分布式服务的解决方案，实现金融业务弹性伸缩，灵活、高效、低成本的应对应用的脉冲流量。

在 2019 年 12 月 7 日 ArchSummit 全球架构师峰会（北京站）专题演讲中，来自蚂蚁金服网商银行的高级技术专家王恒（花名子谅），分享了《新一代互联网金融弹性架构实践》话题。

王恒老师 2013 年加入阿里巴巴，先后在阿里巴巴数据库事业部，参与了多年双 11 大促以及阿里巴巴单元化异地多活等重大事件。后来加入阿里云，负责阿里云 IaaS 产品的硬件规划、设计、研发、定制化等硬件服务工作，致力于做好云计算基础设施。2019 年加入蚂蚁金服网商银行，从云计算用户角度，重新思考和设计应用系统，致力于推动金融行业的技术发展。

演讲主要从四个方面进行，首先介绍网商银行的价值观和使命，然后根据金融行业的技术挑战，引出今天的主题“弹性架构设计”，最后一起探讨未来智能化架构想法。（以下是演讲内容整理）

网商银行简介

网商银行，是普惠金融的践行者，这是 4 年前成立时就赋予的使命。希望通过互联网技术、大数据和渠道创新，帮助小微企业和个人创业者解决容灾难、融资贵，以及农村金融服务匮乏的问题。网商银行基于云计算基础设施，大数据驱动的风控管控能力，打造轻资产、平台化、交易型的金融平台，同时联合金融和非金融的生态合作伙伴，持续推进和践行普惠金融。

网商银行成立初期，马老师曾把网商银行服务小微企业比喻为打造一架直升飞机。如果传统金融机构是飞机，那么网商银行作为一家银行，要做的是“直升机”。直升机和飞机虽然都能飞，但却有完全不同的飞行原理，直升机不比飞得高，比的却是飞得低，可以完成超低空飞行。网商银行要做的正是贴地服务，这样才能有速度且有覆盖面，更灵活地服务更多小微企业。

2019 年双 11 期间，这架“直升机”采用 310 模式，即 3 分钟申请、1 秒钟放贷、0 人工干预，累计贷款 3000 亿、户均贷款频次 7 次、15 万小商家贷款笔数 100 次，切实解决中小微商家“小频短急”的金融服务需求。

互联网金融的挑战

互联网金融有别于传统金融系统，但却需要具备金融高可用、高标准、低风险的技术基础，同时必须兼具互联网规模化的服务能力，让所有能够使用互联网的客户都有机会使用普惠的金融服务，因此也需要具备高性能、弹性伸缩以及低成本特点。两者结合在一起，形成了新一代互联网金融的技术架构需求。

同时，金融行业一直以来面临的容量扩缩容和城市级容灾能力，一直是困扰金融服务高可用的一道难以跨越的鸿沟。容量弹性伸缩方面，经常遇到单台服务器计算能力受限、IDC 资源受限（如电力、机架位等）等问题，导致金融系统常常无法快速应对业务的高峰请求。城市级的容灾，同城冗余备份或跨城远程备份，都无法在机房或数据中心级别故障时，具备快速支撑金融服务的能力。

面对新一代互联网金融的技术架构需求，以及金融行业容量和容灾的技术挑战，在 2019 年双 11 之前，我们只能新增加 30% 的计算单元，却要支撑住 3 万笔 / 秒的能力。这样的交易峰值，是 2018 年双 11 的 3 倍还要多，这些巨大的挑战，需要我们在已有的条件上进行突破，进行一系列的技术架构升级改造。

弹性架构设计实践

首先，来看一下弹性架构的演进路径，从集中式架构模式，到分布式微服务的架构，应用经历垂直、水平的拆分，实现分布式架构，以及升级到单元化、多活、弹性的技术架构体系，最后到越来越多的智能化应用的发展路径上。在金融行业落地过程中，这条道路异常艰辛，但却是实践的指导思想。

设计弹性架构的体系，需要先从宏观上来看，系统上需要具备什么能力，需要哪些功能组件，然后逐个模块进行详细处理。否则“头痛医头脚痛医脚”，无法做好技术架构的优化。

设计弹性架构到底需要哪些能力的建设（如上图）：云计算基础设施作为技术底层服务，这已经成为必然；分布式关系型数据库，解决数据库的高性能、高可用、弹性伸缩的能力；单元化分布式中间件平台，屏蔽分布式架构、单元化架构带来的复杂度；顶层的单元化流量调拨平台，让单元化的流量流到对应的单元，避免跨域调用；配备上研发协同平台和运维管控平台，保障研发效率和生产稳定性，构建起完整的金融架构体系。接下来将分别从这些方面来详细介绍网商银行的实践过程，中间也会穿插一些“故事”，便于读者更清晰的了解这条路。

如何做弹性，重点是数据拆分，这是让应用具备细粒度弹性的必然之路。数据拆分包括垂直拆分和水平拆分两方面：垂直拆分层面非常容易理解，就是将不同的应用系统从同一个数据源中拆分出来，一方面可以避免资源的互相争抢，另一方面也让应用系统具备独立弹性的能力。同时，当年不靠谱的“前任”还挖了一些坑，在数据表设计层面，没有遵循数据库设计原则，应用系统运行起来越来越臃肿，这个时候就要根据数据的亲和性进行垂直拆分，这是个大动作。具体的方法大多数需要配合应用侧一起，进行数据拆分。

水平拆分一直是数据拆分的一个难题，也因此滋生了大量数据中间件服务和创业公司的出现，但这里我们专注于一些指导策略的说明。拆库的数量设计，按照未来业务峰值能力，跟单库容量上限进行拆分。拆表的数量设计，按照业务量和存储时长的乘积，以及单表容量上限来决定。原则只是指导方针，实际过程中该如何进行拆分呢？首先根据业务属性进行分析，从业务系统入口来看，如何进行分类，如果是 toC 业务，那么流量入口就是用户 ID，那么数据水平拆分就按照用户 ID 进行拆分；如果是 toB 的业务，那么流量入口就是商家 ID，那么数据水平拆分就按照商家 ID 进行拆分。toB 和 toC 系统之间怎么办呢？那是数据交互的另外一层问题。

接下来从流量入口说起，首先对流量负载按权重进行调度调配，同时根据底层的压力进行动态调整（如上图）。在接入层将根据数据拆分的逻辑，或者单元化的逻辑，进行数据流量的转发，使得应用处理落在服务注册的单元内。之后的应用处理，所有的请求调用和处理都会在一个机房或一个单元内完成。在应用层，也会根据应用集群的设置进行路由和权重的刷新，确保集群流量的动态调配。中间件层同样根据底层数据库的压力，进行动态的路由和权重刷新。存储层为了解决请求的处理，以及存储服务的可用性，提供高可用的容灾能力。

在接入层将流量按照用户维度进行调拨，将用户的请求调拨到封闭的单元内完成，具备单元级别的服务自包含。这样彻底解决用户请求跨单元、跨机房的调用关系，使应用系统具备高度内聚、单元化、可扩展的能力，看起来似乎是最完美的状态。也许有人会疑虑，实际生产上肯定做不到这样干净的切分，一定也无法完全避免跨单元、跨机房的服务调用，所以认为这个方案实施起来是不现实的。而网商银行实际落地的时候，也面临了同样的问题，一部分系统无法做到完全单元内封闭，还需要跨单元、跨机房调用。

为了解决这个问题，我们进行了一些规则的定义，按数据访问的类型进行划分，将应用系统分为 RZone、CZone、GZone。RZone 是核心业务系统，即按照流量接入维度进行拆分，承担用户请求和处理的核心业务单元，这些应用可以做到单元内的自包含。CZone 是共享业务单元，会被核心系统高频调用的系统，无法按照统一的维度进行拆分的业务系统。GZone 是指全局访问的业务系统，无法按照统一的维度进行访问，同时业务系统也不会被频繁调用，否则会成为业务的瓶颈。这样系统分类后，可以让每一个核心应用的单元内做到应用系统、中间件、数据等服务的自包含，同时每个数据中心至少包含一个 CZone 提供共享的服务调用，且包含零个或若干个 GZone 或 RZone。由于 RZone 调用 GZone 可能存在跨机房调用，延时会增大，因此会尽可能减少 GZone 的服务调用，而确保频繁的服务调用在本机房内完成。

如果按照 IDC 的方式来建业务系统，会陷入一个盲区，就是不断的向同一个 IDC 里添加东西，会撑爆这个数据中心。经过系统的分类设计，形成了一个逻辑数据中心的概念（LDC），打破了 IDC 的容量限制，将核心业务单元进行细粒度部署，一方面实现异地多活，提供并行计算的能力，另一方面也将容灾的风险粒度降低，避免 IDC 故障引起的大面积系统瘫痪。然而这样设计之后，也遇到了巨大的挑战：

一方面，业务系统开发的复杂度变高了，数据分片后，如何知道应用写入那个数据库，这是个非常复杂的问题；
第二方面，系统出现问题的时候，问题分析和排查非常复杂，很难立即识别并解决系统的问题；
第三方面，产生大量的分布式事务，系统的复杂度更高，尤其是在金融领域；
第四方面，微服务的流控、熔断、批处理、变更等，都成为非常复杂的一件事情，运维工程师非常痛苦。

为了解决这个问题，蚂蚁金服开发了一套金融级分布式中间件平台 SOFA，是一套云原生的技术栈体系，将基础框架（对应开源的 Spring Boot）、微服务框架（对应开源的 Dubbo）、数据访问代理（对应开源的各种 Proxy、数据传输平台）、分布式事务（对应开源的多种 TCC 框架）、消息队列（对应开源的 RocketMQ、ZeroMQ 等）、分布式链路跟踪（对应开源的 OpenTrace）等服务开发框架打包，整体提升了技术栈的水位，用于解决因为数据拆分、单元化、分布式带来的一系列问题。当然还需要配套的研发交付平台和运维监控平台来配合，形成一个完整的技术栈体系。

在实际应用过程中，中间件可以说是业务系统的中枢神经。在接入层转发后，根据微服务注册平台进行服务路由，微服务的流控、熔断、批处理、变更等，都在微服务域产品中处理完成，针对服务网格（Service Mesh）在下面详细说。应用间的异步调用，通过分布式消息队列进行交互。应用数据库的访问，通过数据访问代理进行路由转发，同时通过数据同步服务将生产系统的数据传输到大数据平台进行处理。应用系统的日志数据，进行实施的链路追踪和业务系统健康状况的实时监控。

Service Mesh 和 Severless 这两年比较热，大多数情况下技术人是看热闹的多，实际参与者少。在这件事情上，网商银行 2019 年双 11 就进行了服务网格的尝试，并取得了不错的效果。服务网格是让应用和服务调用分离，让应用更专注于应用逻辑的开发，让服务网格专注于服务化。于是，将 RPC、缓存、消息等强相关的服务调用形成为统一的 MOSN SideCar，数据库访问形成 DBMesh SideCar，安全服务模块形成 MIST SideCar，这样就将应用逻辑跟服务调用剥离，让应用开发专注于处理应用逻辑的设计和开发，服务层专注做好服务层高可用、流控、流量转发等能力建设，而运维工程师也从“救火员”转变为系统风险和架构师，专注于应用的系统风险控制，而云原生产品专注于满足产品优化和功能完善。

服务网格的经验告诉我们，释放应用开发工程师对复杂基础服务架构的学习成本和依赖，可以快速提高研发效能，同时也有利于服务的独立升级和演进，而不涉及应用系统的改造。研发迭代效率的快速提升，也加速了业务的创新。

另一个要解决的难题就是金融数据库，网商银行采用了最近热度高涨的 OceanBase 分布式数据库，选择的初衷是经过了蚂蚁金服近 10 年的金融场景打磨，并经受住了高性能、高可用、稳定性、扩展性等一系列考验。当然，从我对数据库领域的感受来看，数据库是最热门、最活跃、最多样化的一个领域，而经过金融考验的数据库也有几个，大家可以自己找对应的产品。这里也给大家几个提醒：

数据一致性，这是金融的底线，所以一定要经过大量的验证，尤其是在容灾切换的瞬间，是否能保障数据的一致性，才是最关键的因素；
弹性可扩展性，无论是 scaleout 还是 scaleup，只按业务需求进行弹性，解决业务峰值的压力，都是一些必备的能力；
高可用，保证系统连续性和可用性的保障，说起来容易，做起来确实非常困难，这也是实践的过程。

说到高可用，可以回想一下前面讲到金融容灾、容量的挑战，如何做到同城、异地容灾，是网商银行一直以来探索的问题。在解决单机房故障时，需要快速进行跨机房的容灾切换，尤其是当前的写数据库，需要在保障数据一致性的前提下，进行快速切换。而面对城市级故障时，同样需要在保障数据一致性的前提下，快速切换到第二个城市。因此，我们形成了三地五中心的数据架构，借助 OceanBase 的 Paxos 能力，解决了 IDC 和城市级的容灾能力。

肯定有人会说，成本太高了，一份数据写 5 个副本，这个成本有点高。的确，我们也遇到了这样的挑战。于是将城市三做了一下优化，为了保障 Paxos 协议的正常选主逻辑，因此将城市三节点只需要写 redo log，而不需要完整的数据库节点，这样节省了数据的存储空间成本。为了保障数据库的持续服务，RPO=0 的技术目标，我们没有继续进行成本优化。此外，为了提高数据库的计算能力，数据库单元化使得内部服务正常调用均为单元内封闭，因此多单元可以提供并行计算的能力，真正实现了业务的异地多活能力。

经过上述一系列的单元化、分布式改造，加上中间件服务、分布式数据库的支持能力，以及运维平台和研发效率平台的配合，实现了按照业务需求，以单元为粒度，进行动态的弹性。应对今年双 11 大促 3 倍以上交易峰值的增加，我们动态弹性扩容到金融行业云环境，云计算为网商提供了弹性伸缩的能力，应对了应用的“脉冲”流量，让网商银行经受住了双 11 的考验。此外，今年的云单元技术架构体系，还获得了中国人民银行科技司的“科技进步二等奖”。

未来智能化架构

对于未来的架构演进，网商银行将不断往智能化的架构体系演进。

首先从技术层面上，计算的动态弹性能力方面，需要逐步根据业务的流量预测、资源预测等维度，实现快速在金融行业云上部署金融单元，既保障弹性能力，又要保障金融业务的稳定性和低成本，这在其他领域可能是一个常态，但在金融领域却极其困难；同时网商银行在 Service Mesh 和 Serverless 的计算形态落地和实践，将进一步扩大到全域，增强计算的灵活性，应用的计算配置化目标。

在数据和算法层面，基于大量的系统运行时数据，继续提高数据链路的故障诊断和自愈率，让数据真的有价值，让算法更加智能化，提高问题处理效率；此外网商银行在风控、营销、体验、资产负债管理等各个方面都进行了智能化的实践，尤其在智能风控方面，当前信贷不良率降低到 1.5% 以下，已经远远低于行业水平，但这远远不够。我们正致力于研究和实践多方安全计算，打破数据孤岛，让数据进行安全的计算，持续提高金融风控水位，例如联邦学习、共享学习、多方安全计算等技术。

在金融业务方面，目前网商银行启动了“凡星计划”，一个人可以走得很快，一群人会走得更远，网商银行这一架直升机肯定不够，需要一个直升机机群才能覆盖全球广大的中小微企业。因此，开放金融基础能力和金融风控能力，赋能行业合作伙伴，一起为中小微企业提供普惠的金融服务。

希望经过我们一起的努力，让每一个平凡的小微个体拥有平等的金融服务机会，成为闪亮的明星。网商银行，无微不至。

活动推荐：

目前，ArchSummit 全球架构师峰会（深圳站 2020.7）已启动，会议上会分享架构、算法、前端、产品等方面的话题，如果你感兴趣参与到 ArchSummit 会议中，欢迎点击“议题提交”自荐 / 推荐。

创作场景

蚂蚁金服网商银行新一代互联网金融弹性架构实践