金融机构达到一定业务量之后，比如银行资产规模在1000亿元以上，必须建立两地三中心的容灾架构，保证金融服务可以连续提供，避免业务连续性风险。但是同城数据中心和异地灾备数据中心的资源只是提供查询甚至只支持测试，资源浪费很大。同城双活可以提升资源利用率、保证数据中心级别的灾难恢复，但不能满足城市级灾备需要。异地灾备中心由于缺乏演练，真正发生灾难时是否切得过去也是个问题。要真正做到异地灾备，得要求异地数据中心也是活跃的，要做到异地多活。

但是由于异地数据中心之间相距在1000公里以上，单程通信就要20ms以上，一个来回往往需要60ms。在分布式架构下，一次业务交易往往涉及几十次服务调用，如果存在跨机房调用，用户可能要等待几分钟时间才能获得交易结果，这也是不可接受的。

那么可行的模式是将一次业务交易的调用限制在一个数据中心，尽量避免跨城市、跨数据中心的调用。这就要求在每个数据中心中都部署完整的系统，同时将流量按一定规则分配到不同的数据中心。这样就出现了单元化架构，或者叫Set化架构。每个单元都可以处理完整的业务。不论是微众银行、还是网商银行，都已经实现了单元化架构。

单元化架构还有一个好处是容易扩展、能够支持海量用户。如果业务大幅增长后当前架构支持不了新增流量，就再扩展出一个或几个单元，将流量分配过去就行了。甚至对于双十一、春节红包等场景，可以按单元进行弹性扩展和弹性缩回。

事实上，单元式架构不是新鲜事物，也可以在历史上找到原型。比如，大的互联网厂商往往按照区域建立多个数据中心，服务于不同区域的用户。还有大型银行和运营商在刚刚完整数据大集中时，往往为不同的省分行或省公司提供单独的资源。但是单元式架构与这种方式可谓形似神不似，在技术架构上已经不可同日而语。

阿里是这样定义单元和单元式架构的：

所谓单元，是指一个能完成所有业务操作的自包含集合，在这个集合中包含了所有业务所需的所有服务，以及分配给这个单元的数据。

单元化架构就是把单元作为系统部署的基本单位，在全站所有机房中部署数个单元，每个机房里的单元数目不定，任意一个单元都部署了系统所需的所有的应用，数据则是全量数据按照某种维度划分后的一部分。

数据一般是按照用户ID维度来划分的，本质上就是采用了数据分片技术。而单元化架构不仅是数据分片，还实现了在路由接入、应用、缓存等方面的分片。

单元式架构如下图所示，有三个机房，其中机房1和机房2位于同一个城市，机房3位于另一个城市。每个机房中部署了数量不同的单元。业务流量按某种维度（UserID）进行路由进入不同的业务单元。

单元化架构有很多的好处，但是搭建单元化架构的成本也非常高。单元式架构搭建需要以下四个步骤：

1）业务系统需要改造，能够按照统一的维度进行数据分片和流量路由。而且肯定会存在部分数据是无法按这些维度进行划分的，方案中要考虑到。

2）需要搭建一套单元化技术支持平台，将单元化架构搭建和运维的复杂性对业务开发人员进行屏蔽。

单元化支持平台至少应该包括三方面的功能：

支持单元化的中间件包括微服务框架、消息中间件、数据访问层中间件，保证服务调用在某个单元内能够完成。

规则管理和流量调拨系统则负责管理业务流量在业务单元间的分配、单元与数据分库之间的匹配和跨单元的访问规则等，好比一个交通警察。在发生灾难时，如何将某些单元的流量迁移到其他单元。

单元化部署平台能保证能够以单元为维度进行发布，单元间互不影响。还可以实现基于单元的灰度发布。监控系统可以按单元监控其运行健康程度，以便在事故或灾难发生时快速进行流量切换。

3）要设计一整套单元式架构方案，划分各类单元，并明确各类流量的路由处理。

4）有了上述工作基础之后，在实施单元化架构迁移时，可以先保留现有的Center集群，逐步增加业务单元，并将流量切换过去。