更多精彩内容，欢迎观看：
带你读《云上自动化运维宝典》——一文详解云上跨可用区容灾解决方案和异地多活能力建设最佳案例（1）：https://developer.aliyun.com/article/1405312
3. ECS团队在容灾上的实践
该部分以ECS内部某具体的Web服务为例，根据业务不同的发展阶段所经历的不同的容灾架构能力建设。根据Web服务经历的不同业务发展阶段，将其分成了三个阶段：
第一阶段，业务的起步阶段。在该阶段，整体的业务量较小，只有国内较少的Region对外提供了服务，这个阶段的客户也主要以中小客户为主。在该阶段，采用同城双活的容灾架构。
第二个阶段，业务开始快速发展，新Region开始持续不断开服，企业客户开始上云，对服务提出了更高的稳定性诉求。在该阶段，采用单元化的垄断架构。这里的单元化和与前面提到的淘宝天猫的异地多活单元化存在概念上的区分，后面会进行详细的介绍。
第三阶段，业务继续快速发展，Region开始遍布国内外。在该阶段，国内外的客户数量都在快速增加，这也会导致一些体验方面的问题。如跨国访问速度慢，域名切换体验差。在该阶段，为解决相应的问题，满足业务上发展的诉求，又升级到了异地多活的架构，在内部又称之为全球化的架构。
1） 同城双活（跨可用区）
观察图左侧，最上层用户的请求通过DNS解析到公网SLB上，其具备可用区级别的主备的容灾能力，把请求再继续路由到可用区级别的应用级别的负载均衡，而应用级别的负载均衡也具备主备的容灾能力，进而将业务请求再路由到业务层面的应用。而应用无论是部署在主数据中心还是备数据中心，其所有数据的读写操作都会请求到主数据中心，包括中间件、数据库的一些操作，且中间件和数据库的数据采用单向同步机制把数据同步到备数据中心。
在最下层，应用支持操作所有地域的ECS资源。因此，这套容灾架构可以很好地满足现阶段的业务情况，如业务质量较小、开服Region较少、客户以中小客户为主且主要集中在国内的现状。
它可以满足用户在高可用方面的诉求，包括毫秒级别的RPO，因为数据同步是可用区级别的，一般在几毫秒左右。第二，分钟级别的RTO，主要包括最上层的流量切换。为进一步提升应用的性能，在其内部也做了一定的业务改造，主要包括RPC流量在可用区内部封闭处理，目前主流的RPC框架都具备这种能力。
这套容灾架构是的我们具备了同城级别的容灾能力，但由于操作的是所有地域的ECS资源，当出现故障时，其影响面较大。
2） 单元化
这个阶段业务开始快速发展，是因为Region持续不断开服,企业客户开始上云，对服务提出了更高的稳定性的诉求。因此这个阶段在高可用方面除了以上提到的几点，还应新增一点，即在故障时尽量控制影响面，仅影响单个地域，而不影响全网其他地域云资源的操作。
因此，将该阶段的容灾架构升级为了单元化的容灾架构。这里的单元化是指每个Region的操作都在单元内部闭环处理。当Region出现故障时不会影响另外的Region。这里的单元化与淘宝、天猫异地多活的单元化有一定差异。
观察图左侧的架构图，最上层用户请求不同地域时，其对应访问的域名不同，每个域名解析到对应的Region的公网SLB，到单元内部，架构与同城双活的架构基本一致，唯一的差别在于最下方Region A只支持操作Region A的云产品，Region B只支持操作Region B的云产品，进行了单元的隔离。
这样，第一，提供了单元化的服务能力，因此在故障时可尽可能地缩小影响面；第二，单元内部依然进行了同城级别的容灾能力，而不具备异地的容灾能力；第三，每个单元都会对外提供访问的域名，随着Region数量的持续新增，会给用户带来体验较差、跨境访问速度较慢等问题。
3） 异地多活（全球化）
随着业务的发展，进入到了第三个阶段。在业务层面的主要特征包括：
其一，Region开始快速增加，包括国内外的、开服的Region数量很多；
其二，该阶段客户的分布也发生了较大的变化，国内外的客户数量都在快速增加，在进行跨国访问时速度较慢（这里的跨国访问指的说用户在美国，却要操作北京的Region资源，或用户在国内，要操作英国Region的资源，这便涉及到了跨国访问）；
其三，域名切换体验较差，每个Region都对外提供访问域名，当要操作不同Region的云资源时，就要在各域名之间进行反复的切换，体验较差。
在该阶段，用户也提出了更高的可用性诉求，如地域出现故障时，是否可以把请求路由到另外地域进行处理，以那进一步降低故障的影响面。
观察左侧的架构图，最上层是一套DNS，DNS具备就近路由智能解析能力（用户在不同地域发起请求时，会就近解析出来最近的服务提供的地域，如用户在美国发起请求，则会把请求了路由到美国的服务器上面，如果用户在英国发起请求，则会把请求路由到最近的如德国的服务器上。
图片中展示了三个数据中心，而这套架构在线上实际有接近十个左右的数据中心，已基本上实现了全球每个大洲1-2个数据中心的部署，因此，在内部又称之为全球化架构。通过观察图上展示的三个数据中心，可以发现他们之间有一定的差异，数据Region a和Region c所有应用的写操作都回到了Region b的，则一般把Region b称为主数据中心，Region a和Region c称为备数据中心。所有备数据中心应用的写操作都回流到主数据中心，主数据中心把数据更新到数据库之后，数据库又会把数据采用单项同步的方式同步到各个备数据中心。
之所以要进行这样的改造，与自身应用的业务特征是有强关联性，因为该应用是非常典型的“读多写少”的应用，这样改造之后可以大幅降低应用本身的复杂度以及容灾系统部署的复杂度。在最下方，支持操作所有地域的ECS资源，在每个Region内部采用的还是同城双活的容灾架构。
关于容灾的效果，
第一，所有的读操作都具备了异地级别的容灾能力，而写操作依然是同城级别的容灾能力，因为所有的写操作都会回流到主数据中心，主数据中心内部采用了同城双活的容灾架构
第二，单元内部是具备的同城级别的容灾能力；
第三，使用了DNS智能就近解析能力，可以提升用户的访问体验，现在一般云厂商提供的DNS解析服务中都有智能就近解析的能力。如全球洲级别的路由能力或国家级别的路由能力。
这套架构本身有一定的复杂程度，对业务的改造量较大，如刚才提到的所有备数据中心的写操作都要回流对到主数据中心，因为每个数据中心都有缓存中间件，所有的写操作都回到主数据中心之后，数据进行了更新，操作之后如何同步更新备数据中心的缓存也是非常大的挑战。
更多精彩内容，欢迎观看：
带你读《云上自动化运维宝典》——一文详解云上跨可用区容灾解决方案和异地多活能力建设最佳案例（3）：https://developer.aliyun.com/article/1405310
