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

应用现状比较

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

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

 

核心对比

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

 

业务支撑能力

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

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

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

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

 

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

 

 

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

从架构设计来看，集中式系统的计算、存储都在一套硬件体系内，无需面对网络分区（网络无法连接）问题，能很容易实现高一致性，并通过存储的冗余和软硬件结合的高度优化，达到了较高的可靠性。但在可用性方面，由于集中式架构在设计上是一个单点，单机不可用即全部不可用，所以集中式的系统只能在停机维护时暂停业务，这一点在很多互联网场景下是难以接受的。分布式架构设计，天然就有多个节点，很容易通过主备（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 原则的前提下，确保全局分布式事务的最终一致性，在保证用户体验（性能）的前提下，让客户感受到了一致性，并向用户屏蔽了短暂不一致（故障或者延迟）的恢复细节，满足了业务上对一致性的要求。以下为分布式事务框架的模型示意图：

 

图 4 柔性事务框架原理图

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

小结

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

分布式系统数据层设计模式

支付宝最后一台小型机下线，去 “IOE” 取得里程碑进展。支付宝（以及后来的蚂蚁金服）走的是一条跟传统金融行业不同的分布式架构之路。要基于普通硬件资源实现金融级的性能和可靠性，有不少难题要解决。应用层是无状态的，借助 SOA 架构还可以比较方便地扩展。而数据层就没那么简单了，蚂蚁金服在探索的过程中，积累了一些有用的数据层架构设计经验，还是非常模式化的，可以分享出来供参考。

传统银行使用的高端硬件资源和商业数据库，单机的性能和稳定性肯定占有绝对的优势。互联网分布式架构，则需要从架构设计上做文章，提高系统整体的并发处理能力和容灾能力，其中容灾能力又主要有两个指标：

RTO，Recovery Time Objective，恢复时间目标。表示能容忍的从故障发生到系统恢复正常运转的时间，这个时间越短，容灾要求越高。

RPO，Recovery Point Objective，数据恢复点目标。表示能容忍故障造成过去多长时间的数据丢失，RPO 为 0 表示不允许数据丢失。

分布式领域 CAP 理论告诉我们，一致性、可用性、分区容忍性三者无法同时满足。我们不要奢望寻找能解决所有问题的万能方案，而应该根据不同的场景作出取舍。虽然业务场景五花八门，但是根据实际经验，往往可以归到有限的几种模式中，处理策略也是相对固定的。

我们抽象一个简化的支付系统模型来帮助理解，为了叙述方便，不一定跟支付宝的实际业务情况完全一致。它采用 SOA 架构，主要划分了交易、账务、用户、运营支撑这几个子系统，各自有各自的数据库。另外还有一个全局的配置库，存放一些会被各处用到的配置数据。

 

这几个子系统涵盖了几种常见的模式，先简要介绍它们的主要业务：

账务：金融/支付系统中最核心的业务，简化后姑且认为只保存每个账户的余额，主要操作是增减余额。它的特点是要求数据强一致，每一次对余额的增减必须基于一个绝对正确的当前值，否则就会造成资损。

交易：负责记录每笔交易的状态和上下文。在电商系统中，它可能是商品订单；在银行系统中可能是转账流水。交易类的数据有生命周期，可能有创建、付款、发货、确认收货、退款等状态变迁。这些都不重要，重要的是它的业务特点：每一笔交易的创建是独立的，不需要依赖其他交易的数据；推进一笔交易状态的时候，要求这条数据是强一致的，但跟其他交易数据无关。

用户：维护用户的用户名、密码、邮箱、手机等非账务信息，提供注册、登录、查询业务。在执行核心业务的时候，有多处需要读用户的基本信息，关键业务链路对其有读强依赖。

运营支撑：供内部工作人员用的后台系统，包括但不限于工作流、客服等功能。

配置数据：这里是个宽泛的说法，笼统地表示各类变更不频繁，但是在主业务流程中需要频繁读取的数据，例如交易类目、机构代码、汇率。它们实际可能是散在各个业务系统中的，为了方便描述，单独用一个配置数据库来表示。

把数据库按业务模块进行拆分，是典型的垂直扩展思路，突破了单库的能力限制，使得系统可以支撑更多的业务量。当然这也引入了分布式事务的问题，另有专题介绍暂且不表。拆分开后，就方便不同的业务采取不同的架构设计了。

账务系统
与垂直拆分对应的，自然就是水平拆分。分库分表已经是一种非常成熟的数据水平拆分方法。例如可以将账号对 10 取模，将数据分散到 10 个逻辑分表中。这 10 个分表又映射到 10 个物理数据库。分库分表中间件可以屏蔽掉底层部署结构和路由逻辑，应用层仍然像使用普通单库一样写 SQL。

 

拆分开后，“有数据库出故障”的概率其实是大大增加的。假设其中一个账务库故障了，就意味着有至少 10% 的核心业务受影响了，实际还不止，因为一笔交易涉及双方账号。这种情况怎么办，立即切换到备库？不行的，前面说过账务要求数据强一致，即 RPO=0。数据库的主备复制一般有延时，不能保证数据无丢失。即使用 Oracle+ 共享存储的方式保证不丢数据，回放 Redo Log、检查数据一致性、切换备库，通常要花费数十分钟，足够用户在社交网络炸锅的了。怎么办？早期其实没什么好办法，情愿牺牲一些 RTO，也要保证 RPO。当然可以做一些体验上的优化，例如界面展示余额时，可以使用只读备库，减少用户恐慌，但不允许基于此余额做实际业务，聊胜于无吧。

后来逐渐探索出了一套账务容灾方案，需要业务层参与，还挺复杂的。这个话题足够单独成文，本文先不详细介绍，只说一下基本思路：主备库数据不一致无法避免，但可以想办法锁定有哪些账号的数据是最近刚刚在主库有过变更的，我们没法确定这个变更是否已经同步到备库了，就把这些账户全部加入黑名单，数据库恢复前不允许他们再做业务，避免发生资损。可以采取一些手段，让黑名单范围尽量小，并且确保黑名单以外的账户一定是主备库一致的，实践中可以缩小到几十几百个账户。这样，不可用范围就从库粒度一下子降到账号粒度，不在黑名单中的账户，就可以基于备库余额正常开展业务。

这套基于黑名单的容灾方案一直运行了好几年，效果还不错，缺点就是比较复杂，这是账务类业务本身的特点决定的。直到自研数据库 OceanBase 的诞生，情况有了改观。OceanBase 是基于 Paxos 协议的分布式强一致数据库，对于单节点故障，它提供 RPO=0，RTO<30 秒的容灾能力，致力于从数据库层屏蔽容灾细节，为应用层提供简单的使用方式。

交易系统
交易数据也是非常适合水平拆分的，可以将交易单据号取模，做分库分表。除此之外，根据交易类业务的特点，还有更有意思的玩法。除了正常的交易主库之外，另外再准备一组表结构完全相同的空库，称为 Failover 库（注意不是备库，跟主库没有数据同步关系）。交易系统在创建一笔交易的时候，首先要生成交易单据号，其中有一位叫做弹性位，正常情况下它的值是 1，代表这笔数据应该写入主库。后续根据交易单据号读写该条数据的时候，一看弹性位是 1，就知道到主库找这条数据。

 

假设 3 号主库突然故障了，这时就需要自动或手动给交易系统推送一个指令，告诉它以后第 3 分片的新数据应该插入 Failover 库。以后生成的第 3 分片的交易单据号，弹性位就是 2，代表 Failover 库，后续读写这条数据，也可以根据这一位自动找到 Failover 库。这时候主库的存量数据是无法修改的，已创建未付款的交易，用户可以放弃，重新创建一笔，就会落到 Failover 库正常处理。已经付款的交易，就暂时不能做发货、确认收货等状态推进了，但这不是关键业务，迟一点做也问题不大。当主备库数据一致性检查通过，主备切换完成，落在主库的老数据又可以继续处理了。这时再推送指令给交易系统：3 号库恢复正常状态，以后新数据落主库。Failover 机制让主业务（创建交易、付款）在很短的时间内恢复可用，放弃非关键业务（存量数据的状态推进），为主备切换争取了时间。分库分表、Failover 的逻辑，都可以由数据访问层封装，业务层并不用感知。

这期间在 Failover 3 号库创建的、弹性位为 2 的数据怎么处理？答案是不用特殊处理，根据弹性位 2，以后仍然可以在 Failover 库访问到这条数据，经过一段时间后，主库、弹性库的数据最终都会迁移到历史库去。Failover 库主要用于临时接管主库的新增数据，只要保持表结构一致即可，容量可以低于主库。当然弹性位也可以启用 3、4、5 更多编号，来灵活切换更多存储，这也是“弹性”的含义所在。

配置数据
配置数据很好理解，读多写少，读可靠性要求高，非常适合采用读写分离方案。根据具体业务，可以采用读从库、分布式缓存、内存缓存等方式。

用户系统
用户数据跟账务数据有紧密的对应关系，直观地想，也应该跟账务数据采用同样的处理策略，甚至合并到账务库中。这的确也是可行的，但在实践中，我们根据它的业务特性，采取的却是跟配置数据类似的处理策略，没有做水平拆分，而是做全量复制、读写分离。理由有如下这些： 用户数据更新较少，写操作不在关键路径，读操作在关键路径，跟配置数据的特性非常相似 对数据一致性要求没那么高，可以接受少量延迟同步，没有必要用账务数据那么强的一致性保障，账户余额不可信时，希望至少不影响登录 不全是按账号精确查找，可能有邮箱、手机号等维度的查询，按账号水平拆分后，难以路由

所以用户系统实际采用的方案是：一个写库，全量异步复制到多个读库，再加上分布式缓存。如果写库故障，则不能注册新用户、更新个人信息；个别读库故障，不影响业务。

运营支撑系统
这里用运营支撑系统举例子，实际上是想代表这么一类业务数据：读写比差不多，业务流程依赖写操作，也不适合做水平拆分。这种称之为全局状态型数据。全局状态型数据一般是辅助型的非关键业务，一旦数据库故障，“要么等，要么忍”——牺牲 RTO 等待数据库主备切换，或者牺牲 RPO 立即强切备库。在做架构设计时，需要尽量避免关键业务强依赖全局状态型数据。如果真的有关键业务是全局状态型的，只能依靠 OceanBase 这样的多副本强一致数据库产品了。

归纳一下，业务数据主要可以归为三大类：

状态型：读写比相当，必须保证可写才有意义，每一次写操作必须基于前一个正确的状态。这是最棘手的一种数据，难以完美兼顾 PTO 和 RPO 。关键业务的状态型数据，应尽量想办法把维度拆细，一是提高并发处理能力，二是方便隔离故障影响。

流水型：不断产生新的数据，各条数据间是独立的，可以随时切换新数据的存储位置，每条数据的主键自包含存储位置信息。单条数据的更新需要保证强一致性。流水型数据很方便做水平扩展。

配置型：读写比大，强依赖读，弱依赖写，不要求严格的读一致性。可以采用读写分离、一写多读的方式保证读操作的性能和高可靠。

在做架构设计的时候，如果能准确地识别出业务数据的“模式”，可以帮助更合理地划分业务模块，更方便套用特定模式的性能扩展和可靠性保障策略，乃至将公共逻辑抽象成通用组件。一个没有经过数据类型拆分的系统，可以先当成最坏的情况：全是全局状态型数据。然后识别出其中的流水型数据、配置型数据，逐渐分离出去，状态型数据尽量做水平拆分。最后肯定还是会存在无法规避的全局状态型数据，则要想办法尽量降低它的重要性，避免关键链路对它的强依赖。

金融/支付系统中，最重要的往往就是类似账务的这种状态型数据，是必须要面对的难题。蚂蚁金服的经验是将所有“类账务”的业务（例如余额、余额宝、花呗）做抽象化、平台化，封装黑名单容灾等固定的业务逻辑，减少重复开发。当然，OceanBase 数据库上线后，把复杂度封装在数据库层内部，在性能和容灾能力（RTO/RPO）上达到了业务期望的平衡，对业务开发是一个不小的福音。目前支付宝的核心系统已经 100% 运行在 OceanBase 数据库上。

本文介绍的几种数据模式，基本可以覆盖常见的业务，可以作为架构设计的参考。但也不必过于拘泥，业务本身是复杂多样的，不一定是单纯的某种模式。举两个例子：

我们日常在支付宝界面上看到的消费记录，并不是直接查询交易系统，而是从一个专门的消费记录系统查询的。交易系统会通过异步消息把数据复制到消费记录系统。双 11 高峰期消费记录展示可能会有少许延迟，就是这个道理。交易是典型的流水型业务，但交易系统和消费记录系统组成的体系，用的却是读写分离思想。

账务系统的余额是状态型数据，但每个账户的变更明细，却是流水型数据，可以适用流水型 Failover 容灾方案。

本文只讨论了节点级的水平扩展以及容灾能力，没有提及访问距离带来的延时问题。金融系统往往要求机房级甚至城市级的扩展能力和容灾能力，蚂蚁金服就运行在异地多活架构上。这时候数据访问延时就无法忽略了，会冒出很多原本不是问题的问题，架构设计将更加复杂。对数据类型的分类，其实是一个重要的基础，不同类型的数据在异地架构下也有相应的处理模式