云单元架构，如何赋能数字化转型呢？

2022 年 1 月 10 日
本文字数：3960 字
阅读完需：约 13 分钟

为什么需要云单元架构

云单元架构是在微服务架构上发展起来的解决 IT 系统扩展性及业务连续性的技术架构，它并不是随着微服务架构一起诞生的，而是 IT 系统发展到一定规模且对业务连续性有高要求的情况下需要具备的技术能力。

从集中式架构到分布式架构

传统的集中式 IT 系统架构如下图所示，由小型机（比如 IBM 的 P 系列等）、存储设备（EMC 的 VNX 系列等）、硬件负载均衡设备（典型的比如 F5）等基础设施构成，这些硬件设备具备很强的稳定性，因此在金融行业这些产品具有很高的市场占用率。

随着金融行业新业务的不断扩展，集中式架构的弊端逐渐显现出来，比如小型机虽然性能足够强大，但是面对突增的业务，处理能力往往很难快速提升。F5 这类硬件负载均衡设备，虽然单机处理能力足够强大，但是成本高昂，无法进行大规模冗余化配备以保障其可用能力。此外，类似 EMC 这样的高端存储设备，在面向海量数据的情况下，单位存储成本巨大，在扩展性上也无法与采用 PC 的分布式存储相比。因此，在金融行业的一些新业务场景甚至部分非核心系统上，原有的架构已经开始尝试向分布式架构演进，如下图所示。在分布式系统架构下，普通的 PC 机取代了小型机，用来部署应用系统，通过多机部署，应用系统的冗余能力大幅提升，单机故障的影响也随之大幅降低。在流量负载上，分布式架构往往会引入软负载能力，通过软件实现流量的负载均衡，确保在流量路由层面也具备更好的冗余能力。在数据库层面，随着 MySQL 这类开源数据库的广泛使用，在金融行业分布式系统架构演进过程中，这种类型的数据库也逐渐取代了一部分 Oracle 数据库，成为应用系统数据存储的关键组件。

分布式系统架构演进

分布式系统架构的演进并不是一蹴而就的，根据业务在不同发展阶段的需求，分布式系统的架构需要根据实际情况做出相应的变化。通常，一个分布式系统架构的演进往往会经历这些历史阶段：单体架构、应用与数据库服务器拆分、缓存/搜索的能力引入、数据库读写分离、数据库水平/垂直拆分、应用拆分、微服务化等。当然，并不是所有的系统都会经历全部这些阶段，一些较为核心的系统可能会跳过前面几个阶段，直接用已经成熟的微服务架构来搭建服务。

微服务架构下的容灾和容量问题

容灾问题

分布式架构在一定程度上将业务系统的计算能力和数据进行拆分，并通过负载均衡系统将流量按照一定规则路由到不同的节点进行处理，因此，在分布式架构下系统的处理能力不再是“单点”的。随着微服务架构的升级，应用变得更加轻量化，系统的单机“自愈”能力能够得到充分的利用，应用在出现一些单机问题时往往可以通过快速重启等手段迅速恢复业务。但是，单机恢复能力并不一定在任何故障场景中都能适用，在出现城市级断电或者网络故障等极端场景中，应用系统往往不是一台机器出现问题，而是这个区域的所有服务都出现问题。这个时候，如果没有一种灾备恢复机制，保障所有服务可快速切换到新的服务区域，业务系统的恢复时长将会变得非常不可控。因此，核心系统的同城/异地灾备能力建设显得尤为重要。为了使业务系统具备更高的风险抵抗能力，在进行机房选址时，往往会选择一个距离较远（超过 1000 千米）的机房作为其中的一个灾备机房，如下图所示。当发生城市级故障时，业务系统需要具备随时可切换至城市二机房的能力。但现实情况是，由于城市二机房长时间没有流量进行常态化验证，业务流量切换过去以后并不能百分之百保障业务处理没有问题，因此，这种情况下的容灾切换往往需要冒着较大的风险。

容量问题

在分布式系统架构下，应用服务的服务器随着用户需求的增长不断进行横向扩展，单个应用的机器数变得越来越多，由于用户流量是通过负载均衡随机分配给每台机器的，因此这个应用的每台机器都会跟数据库建立起一定数量的连接，这就导致随着应用容器的增长，终有一天应用访问会达到数据库的连接数上限。如下图所示，单个 DB 承载的连接数通常跟操作系统的线程数上限有一定关系，假设每台机器增加 100 个连接，单个 DB 的连接总数总有一天会被占满。

云单元架构的诞生

云单元架构是指在多机房部署架构下，对业务处理能力进行逻辑上的单元划分，使业务流量按照一定规则分配到各个单元中，同时尽量确保用户流量始终收敛在一个单元内完成的架构。在云单元架构下，每个单元的流量会按照特定的规则分配到不同的应用容器中，同时通过分库分表规则路由到不同的数据库分库，如下图所示。由于每个单元的容器数量有限，因此，单元内的服务器扩容不会导致数据库达到连接数上限。同时，通过单元的新增，又可以保障系统容量可以进行理论上的无限扩展。

云单元架构总览

云单元架构的核心是通过单元化部署使整体架构具备异地多数据中心并行计算能力，同时基于金融级的分布式关系型数据库，通过多机房部署实现城市级故障下数据无损容灾切换。通过云单元架构扩展能力，业务可以在不同地域的 IDC（Internet Data Center，互联网数据中心）中部署多个 LDC（Logic Data Center，逻辑数据中心），且每个 LDC 单元都是“活”的，日常承接线上真实业务流量，以确保每个逻辑单元的稳定性与业务正确性。当故障发生时，可以进行 LDC 单元之间的快速切换，一个 LDC 单元对应的灾备 LDC 单元也是一个“活”的单元。为确保异地机房能日常承载业务流量，实现了跨机房的服务注册与发现能力，提供了跨机房的服务调用路由逻辑，从入口流量到分布式服务、中间件和底层数据库，全链路消除了单点，使整体服务都具备了跨机房、跨地域的扩展能力。网商银行总体架构如下图所示。

云单元架构目标

云单元架构的设计目标主要包含以下几个方面：（1）具备系统跨地域、快速弹性部署的能力；（2）具备流量可随时动态调配的全业务“多地多活”的能力；（3）具备一体化研发运维能力；（4）具备海量业务并行处理的能力。

跨地域弹性部署

在分布式服务设计领域，一个云单元就是满足某个分区所有业务操作的自包含集合体。这个集合体可以按照用户、地域、业务类型等不同维度进行单元化的数据拆分和独立部署。基于这种单元化的部署能力，可以灵活地进行多地、多数据中心的建设，如下图所示。

有了对逻辑单元的快速搭建和部署以及一键单元建站能力，在未来面临大容量需求时，可以通过在云计算平台上快速进行资源调度，构建新的处理单元来部署应用与数据库，然后将流量与数据“弹出”到新的单元，快速提升系统容量。当流量消失后，再将流量与数据“弹回”，释放云计算平台上的资源，动态地扩充单机房容量。当单机房容量不够时，通过增加新的异地 IDC 机房扩充总体容量，总体容量不受距离、地域以及物理资源的限制，真正实现了弹性、单元化的部署能力。多机房流量分布如下图所示。

全业务“多地多活”

云单元架构的核心目标之一是保障银行在多个城市（不同城市之间距离超过 1000 千米）的逻辑单元都具备处理全量业务的能力，只有这样才能充分利用各城市的存储、计算等资源，同时又能在出现城市级故障时，某个逻辑单元的用户可以被其他城市的 IDC 所接管，继续为用户提供服务。

在形成单元化弹性部署的能力的基础上，不同逻辑单元之间可以将分区对应的流量根据逻辑单元资源的负载情况灵活调整，通过流量调拨，将不同用户的请求分发到不同的数据中心进行处理，所有数据中心同时承载业务流量，达到全业务“多地多活”服务模式。这种模式结合异地机房的资金清算专线链路的打通，可以保证任一机房级故障均不影响银行业务的整体对外服务。全业务“异地多活”模式如下图所示。

一体化研发运维

在建设“多地多活”技术架构体系的过程中，原有研发平台已经不能适应新的架构体系，需要建设新研发协作平台来支持架构升级，同时显著提升需求迭代效率，以及质量、风险控制水平和产能。通过打造全新的一站式研发协作平台，实现了端到端的全流程、全角色的持续交付管理，将需求迭代、代码开发、发布管控等流程并行处理，并在关键节点上建立了同步机制，业务需求方、产品设计人员、项目管理人员、开发测试人员能够统一在一个研发协作流程中，完成高效协同工作。研发人员在平台上可以灵活地获取测试需要的服务器资源，平台提供一键部署研发服务器的能力，支持快速搭建项目环境，高效地在多个环境中完成基础配置变更（主要是中间件的一些配置），在完成流程审批后，可以将该版本发布到多个环境中，从线下到线上全流程无缝对接，构建一站式持续交付能力，减小“异地多活”技术架构体系在配置修改、环境构建和发布部署等方面带来的复杂度。

海量交易处理能力

随着 IoT（物联网）技术的迅猛发展，未来将从互联网时代步入万物互联时代，无处不在的交易终端和无数新的交易场景，会继续带来金融交易量的指数级增长。什么样的架构与技术可以处理万物互联时代的海量交易，是需要未雨绸缪的。

云单元架构要解决的一个核心问题是海量交易的处理能力问题，大多数业务并不是一诞生就具备海量用户的，交易量是逐渐增长的，那么在架构上我们既需要具备一定的前瞻性，又需要具备针对不同量级的业务进行分级实施。比如在设计上要支持全行单日百亿笔以上的处理量，实现上会支持 10 亿笔处理量，部署上会支持 3 亿～5 亿笔处理量。