集中式架构与分布式架构比较

短命女 2022-01-09 15:29 227阅读 0赞

**应用现状比较**

由于历史原因，集中式架构多用于传统银行、电信等行业。主机资源集中在大型主机或小型机上。集中式架构下，包括操作系统，中间件，数据库等“基础软件” 均为闭源商用系统。集中式架构的典型案例是 IOE（IBM， Oracle，EMC）提供的计算设备、数据库技术和存储设备共同组成的系统。

近年来，分布式架构在 Google、 Amazon、Facebook、阿里巴巴、腾讯等互联网公司广泛应用基础上、也越来越多被金融行业关注和应用。分布式架构一般采用性价比更高的 PC 服务器、分布式数据库和大量 PC 内存闪存，程序同时运行在众多 PC 服务器上。

![Image 1][]

图 1 集中式和分布式系统示意图

**核心要素比较**

以下是两种架构的核心要素的对比分析：

![Image 1][]

表 1 集中式和分布式架构核心要素对比

**业务支撑能力比较**

客观讲，分布式架构在价格成本、自主研发、灵活兼容、伸缩扩展方面有比较显著的优势。互联网行业具有请求量大，数据量大的特点，业务上又可能在集中的时间段出现高于日常流量数倍的业务高峰，这些特征对架构的可扩展性提出了极高的要求。

在集中式架构下，为了应对更高的性能，更大的数据量，往往只能向上升级到更高配置的机器，如升级更强的 CPU，升级多核，升级内存，升级存储等，一般这种方式被称为 Scale Up，但单机的性能永远都有瓶颈,随着业务量的增长，只能通过 Scale Out 的方式来支持，即横向扩展出同样架构的服务器。在集中式架构下，由于单个服务器的造价昂贵，所以 Scale Out 的方式成本非常高，无法做到按需扩展。而分布式架构的解决方案是基于廉价的 PC Server 来做 Scale Out, 借助高速网络组建的 PC 集群在整体上提供的计算能力已大幅高于传统主机，并且成本很低，横向的扩展性还可带来系统良好的成长性。

蚂蚁金服通过几年架构演进，已经从初级的服务器可扩展、数据层可扩展发展到 IDC 层面的可扩展。一旦采用了分布式架构，天然支持按需扩展，唯一的要求是在设计上保持每个应用节点不保存状态信息。随着业务量从几百笔/秒到几万笔/秒级别时，需要更多的服务器来支撑，数据库单表的性能会成为瓶颈。数据量也会从 GB 迅速飙升到 TB、PB，单数据库实例的容量也会成为瓶颈。数据层会采用分库分表的策略来支持业务量的增长,具体策略根据业务场景可分为垂直拆分（按业务）、水平拆分（按请求/用户做哈希，或者做区间拆分）、读写拆分等。最后会通过统一分布式数据访问组件来屏蔽数据扩展的复杂性。下图简单描绘了服务器扩展性（应用层）和数据层可扩展（持久层）的形态：

![Image 1][]

图 2 应用层和数据层弹性伸缩架构示意图

随着业务的发展，应用和数据层弹性伸缩也会受限于到单个机房的电力、面积、散热等物理条件的制约而无法 Scale Out，同城的机房个数也是有限的，所以势必要从机房层面支持弹性的可伸缩。蚂蚁的业务规模早在两年前就已突破这个规模， 因此进行了机房单元化改造，其架构核心思想是把数据水平拆分的思路向上提升到接入层、终端层。从接入层开始，把原来部署在一个 IDC 中的系统集群，进一步分成多个更细粒度的部署单元，从而达到机房级别的扩展。这种机房架构在容灾方面的优势会在第五个小节中展开说明。下面为这种架构的示意图：

![Image 1][]

图 3 单元化架构示意图

下表总结了两种架构模式在业务支撑的几个方面的比较：

![Image 1][]

表 2 集中式和分布式架构业务支撑能力对比

**两种架构的可用性和一致性比较**

从架构设计来看，集中式系统的计算、存储都在一套硬件体系内，无需面对网络分区（网络无法连接）问题，能很容易实现高一致性，并通过存储的冗余和软硬件结合的高度优化，达到了较高的可靠性。但在可用性方面，由于集中式架构在设计上是一个单点，单机不可用即全部不可用，所以集中式的系统只能在停机维护时暂停业务，这一点在很多互联网场景下是难以接受的。分布式架构设计，天然就有多个节点，很容易通过主备（HA）、冗余、哈希等手段实现计算和存储冗余备份，从而实现高可用。

当然，软件领域没有银弹，分布式架构多个节点的设计也带来了保持一致性和高可靠性上的巨大挑战。2000 年，加州大学伯克利分校计算机教授 Eric Brewer 提出了著名的 CAP 理论，任何基于网络的数据共享系统（即分布式系统）最多只能满足数据一致性（Consistency）、可用性（Availability）和网络分区容忍（Partition Tolerance）三个特性中的两个。在大规模的分布式环境下，网络故障是常态，所以网络分区是必须容忍的现实，只能在可用性和一致性两者间做出选择，即 CP 模型或者 AP 模型，实际的选择需要通过业务场景来权衡。

对于一些离线的应用，或者对可用率不敏感的业务，可以适当牺牲可用性来保证强一致，即采用 CP 模型，这样会大大简化设计，系统具备不可用的发现和恢复机制就能让系统保持正常的运转，纯粹的 CP 模型还是比较简单，但适用场景也非常有限，真正复杂的还是 AP 模型。

在金融行业中，尤其是互联网金融系统，保证提供连续可靠的服务尤为重要，长时间的业务中断会引发各种社会问题，影响到生活的方方面面，所以，必须考虑如何在采用 AP 模型的时候尽可能保证一致性（Consistency）。关于一致性，不是只有 0 或者 1，是可以有程度的细分，一般可分为强一致性、弱一致性和最终一致性。达成什么程度的一致性，可以从客户端和服务端两个视角来分析。从客户端来看，一致性主要指的是多并发访问时更新过的数据如何获取的问题。在支付宝系统中，为保证性能，业务数据被垂直和水平拆分到多个数据源中，一次典型的转账操作，会在借贷双方的数据库中分别进行存入和扣除操作，蚂蚁技术团队借鉴了BASE理论（Basically Available, Soft State, Eventual Consistency 基本可用、软状态、最终一致性），设计了基于 TCC（Try Confirm Cancel）模型的两阶段的柔性事务框架，在保证单机事务的 ACID 原则的前提下，确保全局分布式事务的最终一致性，在保证用户体验（性能）的前提下，让客户感受到了一致性，并向用户屏蔽了短暂不一致（故障或者延迟）的恢复细节，满足了业务上对一致性的要求。以下为分布式事务框架的模型示意图：

![Image 1][]

图 4 柔性事务框架原理图

为了保证高可用和业务连续性，分布式系统的存储往往会设计成多份冗余，并尽可能在机架、机房甚至城市维度将冗余的数据分散在多处。所以从服务端角度看，最关心一致性问题是如何尽快将更新后的数据分布到整个系统，降低达到最终一致性的时间窗口。Paxos 协议就是一种在保证强一致性前提下把可用性优化到极限的算法。蚂蚁金服自主研发设计的 OceanBase 数据库就将数据存在多份存储上，每个存储都分布在不同机房，任何一份存储出问题，都不影响全局的可用性。为保证这种高可用架构下的一致性， OceanBase 在多份存储的写入过程中，就用到了 Paxos 协议，并针对各种具体场景，对协议做了优化和改进。详细的设计和说明可参考 OB 的资料。

下表列出了两种架构的具体案例和相关的技术产品，支付宝的架构体系也经历了从集中式到分布式的演进。

![Image 1][]

表 3 集中式和分布式可用性、一致性和可靠性对比

**两种架构的运维复杂度和故障恢复能力比较**

集中式架构部署结构简单，设备数量少，在运维复杂度上较分布式架构有天然的优势。分布式架构随着机器数量的线性增长，复杂性也随之增长，无法通过简单的工具和脚本来支撑。这个复杂度包含了发布部署、系统监控和故障恢复等几个方面，下面会逐一对比。

集中式的发布部署一般只需应对百台内规模的代码/配置更新，通过简单的脚本或者平台就可以自动化完成，发布时间一般也能控制在小时级别。而且采用集中式架构的系统一般比较稳定，发布周期也不会太频繁。在分布式环境下，千台甚至万台服务器的规模很常见，如果按照传统的串行操作和自动化脚本，整个发布周期会非常长，一旦出现问题，回滚也会非常慢。在分布式架构下，往往需要提供 P2P 分发或类似的技术手段来加速发布过程，同时通过 beta 发布、分组发布、蓝绿发布等手段来解决大规模集群下的发布验证、灰度引流和快速回滚等问题。蚂蚁金服在发展过程中，整个运维体系也随着业务规模的增长而升级演进，逐步形成了一套完整的运维管控平台，支持单人运维千台服务器，避免了分布式架构下运维复杂度的增长。

在系统监控方面，集中式架构比较简单。而在分布式环境下做监控，主要挑战在于海量日志的实时分析和秒级展示。系统运行的状态分散在上万台规模的集群中，每时每刻都在产生新的状态。监控系统需要通过日志或者消息的方式采集整个集群的数据做各种统计分析。在巨大的业务量下，每晚一秒钟发现问题就会带来大量的业务异常，在极端情况下还会产生不可估量的损失。因此，也需要监控体系具备秒级的实时计算能力。蚂蚁金服也逐步沉淀这样一套监控平台，很好的弥补了分布式环境下监控的劣势，是整个平台稳定运行的基石。

在系统的容灾机制和故障恢复方面，集中式架构一般会采用主备复制和主备切换的方式来实现，几种典型设计原则包括一主多备，同城双活，两地三中心等。集中式的容灾方案比较成熟，也沉淀了数据复制、镜像快照、一体化迁移等一系列容灾相关的技术，可以从容应对各种场景，但仍然在以下几个方面存在不足：

**成本较高**：在集中式架构下，经典的灾备方案一般会做全量备份，在一些改进方案中会通过余量空间做交叉互备等方式来降低成本，但整体上看还成本还是较高。为 1% 甚至概率更低的灾难场景，而付出与支撑当前业务量相等的成本，这对需要承载海量业务的互联网业务来说更是一个巨大的负担；

**恢复时间较长**：灾备方案中大量用到数据复制技术，但由于网络带宽或者异地延迟等问题，在恢复时，需要等待数据完全一致后才能切换，而且无论备份数据是冷备还是热备，切换都有一个预热的过程。综合切换复杂度和上述的技术限制等因素，很难缩短恢复时间。

**业务影响面较大**：由于集中式架构本身扩展性的不足，所有业务都跑在一个单点上，一旦发生故障就可能影响到所有用户。在承载海量业务的系统上，这种影响更容易被放大，尤其在金融系统上，更有可能引发一些社会事件。

虽然在运维和监控复杂度方面在分布式系统需要通过技术手段来弥补天然的不足，但在容灾恢复方面却有着天然的优势。数据天然分布在不同的存储、机房和城市，而且架构上容易按合适的容量进行水平拆分。随着这几年互联网的高速发展，各家互联网公司都遇到了集中式架构下灾备方案的几个痛点，并进行了类似的架构改造，一般业界称之为单元化改造，其本质是将分布式下可扩展的特性运用到灾备场景，这个在第四章节中有提到。这种架构能将业务影响面控制在一定的范围内（取决于单元的大小），并通过交叉互备降低灾备成本，这种机房架构下的逻辑单元具备以下三个特征：

1. 每个单元在业务处理能力上自包含，对外承载一定业务分片的业务流量，内部的系统调用链路和各类存储访问是局部化在本单元内的；

2. 每个单元的实时数据是独立不共享的，配置类数据或读多写少且对延时性要求不高的数据全局共享；

3. 单元间的通信统一管控，尽量以异步化消息进行通信，同步调用则通过单元间代理方案实现，实现网络上的收敛，便于监控和管控。

**该架构解决了以下四个关键问题：**

1. 由于尽量减少了跨单元交互和使用异步化，使得异地部署成为可能。整个系统的水平可伸缩性大大提高，不再依赖同城 IDC ，真正实现异地多活架构；

2. 可以实现 N+1 的异地灾备策略，大大缩减灾备成本，同时确保灾备设施真实可用；

3. 整个系统已无单点存在，大大提升了整体的高可用性；同城和异地部署的多个单元可用作互备的容灾设施，通过运维管控平台进行快速切换，有机会实现 100% 的持续可用率；

4. 该架构下业务级别的流量入口和出口形成了统一的可管控、可路由的控制点，整体系统的可管控能力得到很大提升。基于该架构，线上压测、流量管控、灰度发布等以前难以实现的运维管控模式，现在能够十分轻松地实现。

下图为该架构的示意图，表格中则总结了两种架构在运维和容灾方面的对比。

![Image 1][]

图 5 单元化架构灾备切换示意图

![Image 1][]

表 4 集中式和分布式运维复杂度和故障恢复能力比较

**小结**

通过上述对集中式和分布式架构在业务支撑、一致性/可用性、运维成本/故障恢复三个方面的分析发现，分布式架构在经济性、安全自主、灵活性、可伸缩性等方面有明显优势，随着金融系统需要处理的交易量与数据量越来越大，分布式架构在这方面的优势也会越来越明显。集中式系统在可维护性、一致性方面有优势，而分布式系统需要达到同等或更高的可维护性与高一致性，需要通过先进的分布式中间件与大规模运维平台来支持。蚂蚁金服的通过自身的实践，证明分布式系统是能够实现金融业务所需要的高一致性与可维护性的，并且将这种技术沉淀到了蚂蚁金融云计算平台上，支撑合作伙伴更好地运用分布式架构和云计算的能力，共同用新技术的力量推进普惠金融的发展。

[Image 1]: