同城双活概述

1. 引言
   同城双活，是年度最大的架构变更。同城容灾，对于生产的高可用保障，重大的意义和价值是不言而喻的。
   用储总的话说，这么重要的架构工作，所有架构师都应该重点主导和参与。
   同城双活，表面看是生产增加了一套环境，从架构上看，这个改变影响是巨大的，它对数据一致性保障、应用高可用管理、请求流量管理、版本发布管理、网络架构管理提升了不少的复杂度。
   以往，我们生产只有一套环境，现在变成二套环境，研发团队在这方面的认知和应对经验，也是相对缺乏的。
   同城双活如此重要，挑战这么大，那么，它的目标是什么，怎么达成？方案是什么，怎么落地？这些挑战和问题，我们如何应对？
   我们将发布同城双活系列文章，希望可以帮助大家找到答案。
2. 同城双活目标
   同城双活是一个长期，不断持续改进的事情，我们需要长短结合，分阶段分步骤来落实。

2.1 短期（2020年）目标

说明：

    1.  短期来讲，最重要的是把双活环境构建起来，支持同城容灾。只有所有应用系统都做了双活，双活环境才完整。

    2.  双活环境，需要确保是“活”的，也就是常规情况下，必须有流量进入。它的目的是保证双活环境的版本与生产主环境的版本一致，保持常规情况下，是可用状态。

    3.  当主环境故障时，存储进行主从切换，换到双活环境，流量100%导入双活环境，30分钟内完成恢复，实现同城容灾。

    4.  为避免出现“数据一致性问题”及双活架构过于复杂，短期同城双活的目标是：应用双活，存储跨IDC同步（热备）。

    5.  “同城双活”的主要目的是：同城容灾，提升生产的高可用。

2.2 长期（2021年）目标

说明：

1. 同城跨IDC存在时延和带宽问题，问题影响有多大？应用系统能否接受？目前还没有大规模生产实践、论证过，暂时是没有答案的。

如何改进或者规避，暂时也是没有很具体答案的。

短期，我只导入极小部分流量进行双活环境，以及容灾切换时存储切换到双活环境的方式，尽量避免跨IDC请求的发生，来规避这个问题。

长期，我们需要逐步增加导入双活的流量，逐步增加跨IDC的请求，持续监控观察，持续改进；在实践过程中，逐步把这个问题解决掉或规避掉，直至双活环境能稳定承担一半（50%）的流量。

1. 短期，各类中间件、运维工具对容灾切换的支持尚不完善，也缺少生产演练和实践，容灾切换过程中，必然有比较多的手工操作，甚至有些小复杂。所以，短期的同城容灾切换，每个子系统需要根据自身实际情况，建立”容灾切换操作手册”，给到运维使用。

长期，我们需要通过工具、中间件、应用改造，实现操作的界面化、一键化，达到运维变更和验证自助自动化，并尽量降低RTO恢复时间。

所以，容灾切换过程，是一个需要不断打磨的过程，我们需要先学会”走路”，慢慢跑起来，越跑越顺。

1. 长期来看，如果条件允许，可以对存储进行分区改造，实现真正意义上的存储双活。
2. 整体方案
   接下来，我们介绍一下整体方案。

3.1 双活环境

说明：

1. Redis所有请求回主环境，双活环境热备，默认不进行跨IDC数据主从同步；跨IDC数据同步目前还没有通过验证，不具备投产条件。
   更详细内容，参见：同城双活-Redis篇。
2. Job同时只能一个环境跑，默认主环境跑，双活环境关闭。QuartzJob、SpringJob建议改造迁移到Horae。
3. DB跨IDC主从同步，主环境为主，双活环境为从。两边应用默认都连”主环境DB”。DB包括Mysql、Oracle、Mongodb。
   更详细内容，参见：同城双活-DB篇。
4. NAS存储：NAS不推荐使用，建议改造使用分布式存储替代。短期过渡，双边环境连接主环境NAS，不做主从同步。
5. NAS、Redis、DB属于”存储”，短期目标是应用双活，应用双活不包括”存储”，双活环境访问存储，默认跨IDC回主环境。
6. 短期，以支持口袋App这个渠道的关键业务场景双活为主。口袋App端在渠道入口采用HTTP-DNS方式，导入”白名单或1%”的流量进入双活环境。
   应用系统，依据”同IDC优先”的策略，应用请求尽量不跨IDC，全链路双活。
   更详细内容，参见：同城双活-流量分流篇。
7. 在业务场景双活的全链路上，如果某些应用系统暂时未做双活，进行双活环境的流量，需要跨IDC调回”主环境”，例如示意图中的”应用B”。
8. 依据”同IDC优先”的策略，双活环境的应用请求尽量不跨IDC回”主环境”，尽量避免”跨IDC”调用。
9. 双活环境为独立一套环境，基础设施也是独立的，包括Pafa5配置中心、Dubbo注册中心、Apollo配置中心、内网F5、ESB等等。
10. 双活环境资源配置对等原则：即双活环境的资源配置须与主环境的资源配置完全一样，包括应用、MQ、存储。确保这套环境能承担生产100%的流量。
11. 双活环境的配置文件为独立一套，包括Pafa5配置中心、Apollo配置中心。双活环境的配置，有可能部分配置与生产主环境不一样，虽然部署的应用版本是一样的。
    更详细内容，参见：同城双活-发布篇。
12. 双活环境Dubbo服务注册中心为独立一套，双边环境注册中心数据会进行同步，没做双活应用Dubbo请求，都会跨IDC调回主环境（观澜IDC）。
    Dubbo支持”同IDC优先”请求分流，需要升级Pafa5版本到5.4.9及以上。
    更详细内容，参见：同城双活-Dubbo篇。
13. MQ短期默认方案是：单边生产单边消费，即消息生产投递回到主环境的Topic，消费默认在主环境消费；MQ双活环境热备；MQ包括ISC、RocketMQ、Kafka。
    更详细内容，参见：同城双活-MQ篇。
    3.2 容灾切换
    

说明：

1. 容灾切换，假设主环境（观澜IDC）不可用，需要把所有（100%）用户请求导入双活环境，进行故障恢复。
   因为主环境的存储也不可用，需要启用双活环境的存储。
   因为主环境的存储不可用，所以双活跨IDC的应用请求，都会失败。
2. Redis切换到双活环境的热备。在未做数据跨IDC同步的情况下，Redis数据是丢失的。
   需要研发团队，逐一分析Redis中的数据和使用场景，评估是否容忍数据丢失，降级措施是什么？
   更详细内容，参见：同城双活-Redis篇
3. DB需要DBA进行主从切换，双活环境DB需要切换为主，双活应用也需要变更连接配置。
4. Job只在单边环境跑，主环境不可用即已关闭跑Job，所以双活环境需要修改配置，启用双活环境Job跑批。
5. NAS存储将不可用，需要分析、评估影响范围，并做好容错降级措施。
   6.未做双活的关联方应用，将不可用，注意做好容错降级措施，避免”雪崩”。
   7.MQ主环境Topic将不可用，生产者需要修改配置切换到双活环境的Topic。
   做了双活的消费者，则在双活环境消费；未做双活的消费者，消息将在双活MQ积压，消息可能丢失。
   更详细内容，参见：同城双活-MQ篇。
   8.Dubbo主环境的服务注册中心将不可用，则双活环境的服务注册中心会侦测到不可用，并剔除主环境的服务提供者。
   更详细内容，参见：同城双活-Dubbo篇。
   3.3 容灾切换操作手册
   通过切换启用双活环境进行容灾恢复，每个应用系统需要根据自身实际情况，制定详细的切换操作手册，确保安全、高效、有序切换。

说明：

1. 切换特别要注意的是数据一致性，存储不是双活的，双边环境只能连同一存储。
2. 应用中，还有一些降级配置需要启用的，需要在操作手册中说清楚。
3. 确保主环境是关闭的，如果未关闭，确保与双活环境连接的是同一存储，JOB单边跑的配置是正确的。
4. 为确保双活环境在故障时，能起到容灾作用。常规情况下，需要定期容灾演练，确保方案可执行性。
   建议每季度一次，由运维决定。
5. 操作手册，需要有详细的回滚步骤，意外情况说明及应对措施。
6. 长期来看，我们需要将操作手册中的手工操作内容，界面化，一键式自动化，自适应自验证，干掉操作手册。
7. 主要挑战和问题
   同城双活带来的架构复杂度，是空前的。

4.1 跨IDC时延和带宽
观澜IDC与福田IDC是通过专线连接的，并且多层防火墙，网络吞吐能力、丢包率、网路效率肯定比不上IDC内部（目前，通过一些已经完成双活应用的实践，时延在8ms左右）。
这些问题对应用系统影响有多大？应用系统能否接受？应用需要在哪些地方，做什么样的改造或规避措施？这些暂时还没有具体答案，因为没有实践，是很难想象出来的。
如果所有应用系统都做了双活，且10%以上的流量导入双活环境，因为存储单活存在大量的跨IDC访问，这种情况下，IDC的间网络能力能否支撑？
这个目前也是估不出来的。
解决这个问题，短期就是尽量避免尽量减少跨IDC访问；双活环境在常规情况下，只导入极小部分流量进入双活环境（白名单/1%）；应用调用则按照”同IDC优先”的原则，避免跨IDC应用调用；容灾切换时，进行”存储切换”，完全避免跨IDC访问。
长期，在常规情况下逐步加大导入双活环境的流量，持续监控观察，持续应用优化改造，把这个问题解决掉或规避掉。
4.2 数据一致性
数据一致性是同城双活的主要挑战。为了确保数据一致性，我们只能做”应用双活，存储跨IDC同步(热备)”。
存储包括DB（mysql、Oracle、mongodb）、NAS、Redis、Zookeeper、ES、Hive等有数据存取能力的中间件。
每个存储中间件，都需要对存入数据进行分析，分析数据丢失、数据不一致的容忍度，来决定它的双活方案。
双活方案中，也一定要把数据一致性的保障机制，描述情楚，执行到位。
在后续的一些同城双活文章中，对各存储中间件进行详细剖析。
4.3 关联应用未完成双活
双活环境的最终目标之一，是所有应用系统都做了双活，双活是一套完整的环境。
但受制于短期资源不足和团队协同成本，必然有些应用先做双活，有些应用后做双活，就会存在应用做双活时，部分关联方不支持双活。
这种情况下，进行入双活环境的请求，在调用链路上，是需要调回观澜IDC(主环境)的。当容灾切换，假定关联方不可用，需要调用方评估并落实容错降级机制。
关联方调用存在同步（Dubbo、ESB）和异步（MQ）两种方式。在同城双活-Dubbo篇，同城双活-MQ篇，我们会做详细的阐述。
4.4 防火墙问题
存储会跨IDC访问，应用会跨IDC调用，原本没有防火墙的调用，现在可能有防火墙了。
需要对所有跨IDC的情况进行识别和整理，提前开通防火墙，并做好验证。
4.5 版本发布问题
双活环境构建后，意味着生产有二套环境，双活环境也要求与主环境（观澜IDC）的版本保持一致。
也就意味着应用包要发布2次，先发默认环境（观澜IDC），再先发双活环境（福田IDC）。
双活环境的Pafa5配置中心、Apollo配置中心是独立的。双活环境的一些环境配置，容错降级配置与主环境也不一样，
所以，双活环境是独立一套配置文件 ，意味着两套配置文件需要分别发布到两套环境。
这里就需要发布平台(CD平台)支持，我们将在”同城双活-发布篇”进行阐述。
4.6 福田IDC资源不足
双活环境（福田IDC）短期资源不足，不足以支持所有应用系统立即全面展开双活建设。如果小部分应用先做双活，也很难起到业务容灾的作用，也没法全链路验证。
但生产容灾这个事，无论从监管要求，还是生产高可用，存在紧迫性，已经到了不可容忍的程度。这是个关键矛盾。
依据关键渠道的关键业务场景来驱动双活建设的策略，有效解决了这个矛盾。
把关键渠道的关键业务场景（比如：口袋App的转账）识别出来，形成优先级。再全链路识别涉及的强依赖（不可降级）应用系统，优先进行双活建设。
这样，即保障了关键业务的高可用，也有效推进行双活建设。
4.7 架构复杂度问题
同城双活提升了生产的高可用，但有得有失，它同时提升了架构复杂度。
架构复杂度增加是有成本的，运维成本、研发成本、架构管理成本、一致性高可用等技术保障成本，对研发团队要求也就越高。
对高可用、一致性的要求，对业务的支撑，要与架构复杂度取得平衡。
所以，在支撑业务、高可用、一致性得到保障的前提下，架构能简单则尽量简单，不要搞一些花哨的东西。
各技术组件，也尽量选择简单的方案。
4.8 应用改造问题
为了支持双活，应用可能需要进行一些代码改造来支持，比如：升级Pafa5版本，去NAS，MQ跨IDC消费、JOB改造迁到Horae等。
改造需要提需求、排期、开发、测试、上线，时间和投入成本不小。而且这类需求属于技术改造类需求，取得业务方认可及取得较高优先级，都不容易。
有些改造是致命且必须的，阻碍双活建设的，有些则非必须的，所以需要区分开来，有策略有节奏地进行改造。
有个原则： 短期，尽量避免代码改造；能不改造，就不改造；非必须改造的，也不纳入项目范围。
长期，排优先级，有策略有节奏地进行改造。
4.9 容灾切换可执行
容灾切换是一个很复杂的过程，涉及流量切换，也涉及存储切换。包括”主环境切到双活环境”，也包括”双活环境切换到主环境”。
当故障发生，能不能很快完成：发现故障，切换决策，执行切换，恢复可用的整个过程，是个很大考验。这个过程，任何环节出问题，都将达不到”容灾恢复”的目的。
所以，生产切换演练，是确保切换可执行的最为重要一环，确保故障发生时，知道切，敢切，能切。
应该至少每个季度执行一次演练。
测试环境FAT102，作为容灾切换演练的测试环境，至关重要。一定要在测试环境全链路模拟生产环境，演练清楚，问题整理清楚。
所以，大家要尽快构建好测试环境，进行全链路切换演练，把一些细节问题发现出来，并解决掉。
5. 总结
通过本文解读，相信大家对同城双活的目标、方案、挑战已经有了基本的认识，后续我们会发布系列文章，进行更深入的解读。
这里，我们再强调一下：

1. 同城双活建设是一个长期持续建设的事情，长短结合，拆分目标，分阶段实施。
2. 每个应用系统，都要根据自身实际情况，制定可落地可执行双活架构和方案。
3. 最大的挑战在：容灾切换，一定要在测试环境先演练清楚，确保生产可安全执行。
4. 在达成目标的前提下，尽量保持架构简单，不要过渡设计。
   本文转载至：https://www.modb.pro/db/52908

Original: https://www.cnblogs.com/zbzSH/p/15916885.html
Author: zbzSH
Title: 同城双活概述