数字化转型下的银行云单元架构

01

为什么需要云单元架构

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

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

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

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

分布式系统架构演进

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

02

微服务架构下的容灾