多活容灾解决方案
引言
- 在2018年，某个创业公司在腾讯云上丢失了所有数据而无法找回，给企业带来的巨大的损失。
- 在2015年，杭州萧山区某地光纤被挖断，导致支付宝部分用户无法正常使用。
- 在2016年，暴雪公司遭遇DDos攻击，包括《星际争霸2》、《魔兽世界》、《暗黑破坏神3》等中重要的游戏离线宕机，玩家无法登陆。
- 在百度上搜索关键字：IDC失火，则有55W条以上的记录。
从以上的种种例子来看，在面对内外环境的复杂因素的条件下，对于企业来说信息化系统的建设必须将容灾这个课题考虑进去，以此来保证业务连续性和数据的完整性。
容灾的定义和衡量标准
我们可以对容灾的概念先下一个定义：
容灾（Disaster Tolerance）
通常是在相隔两地，建立两套或者多套功能相同的IT系统，互相之间能够进行健康检查和功能切换，在面对自然灾害、设备故障、人为破坏或者误操作时，整个应用系统可以切换到另一处，在保证业务数据不丢失或者少丢失情况下，业务系统可以快速恢复或者依然不间断的运行。
因此对于容灾而言，有两个重要的指标作为衡量标准：
- rpo - 数据恢复点目标(recovery point object) ，是指数据丢失后离最近一次备份的时间点。rpo时间越小，代表容灾系统数据完整性保证能力越强。
- rto - 恢复时间目标(recovery time object)，是指故障后需要多久恢复到业务正常状态。rto时间越小，代表容灾系统业务恢复能力越强。
- nro - 网络恢复目标(network recovery object)，是指需要多长时间才能完成备用网络的切换。nro 时间越小，代表容灾系统网络恢复能力越强。
- 容灾半径 － 主数据中心和灾备数据中心之间的距离
- roi - 容灾系统的投入产出比（return on investment），是指为系统投入和产生的回报比值
容灾的级别
从一般而言，可以将容灾以下几个级别：
1. 本地高可用
本地高可用即通过在单点数据中心通过数据库、中间件、业务应用进行高可用集群部署、以本地冗余的方式实现容灾。 - 优点：实施成本低，相对技术简单； - 缺点：不具备机房容灾能力。
2. 数据级
数据级容灾是最基础的手段，通过建立主备数据中心实现数据的冗余备份（数据库、文件等），在灾难发生后确保原有数据不丢失或者少丢失，但是应用是中断的，需要人工重新部署发布，RTO时间较长。 - 优点：费用低、构建实施简单； - 缺点：数据级容灾恢复时间长。
3. 应用级
在数据集容灾的基础上，通过在备数据中心完整构建一套相同的应用系统，在面对灾难后，快速将流量切换到备数据中心上。例如杭州、成都两地作为主备数据中心，当主数据中心无法对外提供服务后，在完成测试验证备数据中心的数据和应用都正常，进行主备切换，备数据中心承载业务。 - 优点：相对数据级容灾，RTO时间短； - 缺点：费用成本高，有资源浪费的情况，备数据中心启动前需要验证。
4. 业务级别
在应用级别容灾的基础上，业务级别的容灾有更高的要求。它要求RTO、RPO、NRO接近0。当面对灾难时，可以迅速进行准备切换，对用户层面无感知。 - 优点：保障业务连续性； - 缺点：费用成本高，需要对业务进行单元化设计，需要专业公司咨询指导。
容灾架构递进式演进
为应对容灾场景所面对的问题，系统需要采用高可用的架构，通过软硬件冗余、数据服务备份、跨机房同步、流量控制等方面进行考虑。
在阐述架构之前，我们需要引入几个定义： * 同城 - 指同一城市或者相近的区域，范围<200公里 * 异地 - 指跨区域，范围>200公里以上，例如1000公里左右
结合容灾级别，一般有以下架构设计方案：
1. 同城同机房
这种情况下，容灾能力是最弱的，属于单点架构，无法应对灾难风险，如果机房一旦出现任何问题，就会对业务造成影响，或者数据无法挽回。 但是这种模式也往往是不少中小企业采用的方式。优势在于部署简单，网络延时低，如果在云服务厂商提供的环境下进行部署更加容易。 例如企业可以将业务应用部署在同一可用区（可以理解为同一机房），以减少应用之间的网络访问延时，通过云数据库产品自身的备份机制来保证数据的不丢失。 该模式能够应对简单场景下应用级别的故障，例如某个应用运行异常，可以通过healthcheck的方式将其自动摘除，而数据则依赖本身的本分机制或者云厂商的机制。
2. 同城跨机房
同城跨机房是才是容灾的起步条件。基于同城跨机房也有几个架构方案：
2.1 同城冷/热备
冷备是将主数据中心的数据定时同步备份，当机房故障时，需要人工切换到备数据中心，显然这种方式会存在业务中断，一般来说主要针对企业内部办公或者管理类的应用，具备业务中断的实际窗口，所以不会有太大问题。但是该方案最大的问题是：在容灾切换之前，备数据中心一直搁置，存在资源浪费，同时如果真要切换，备数据中心是否可以保证正常运行（由于之前没有实际流量跑过） 热备是在主数据中心的数据实时同步备份，其面对的问题和同城冷备一样，这个方式需要对主备数据中心的数据同步有较大的要求。当然只用考虑单向同步。
2.2 同城多活
同城多活可以解决以上两种方式的缺点。第一，因为是多活所以备数据中心也会有实际流量，第二因为有实际业务流程，备数据中心的资源自然可以利用起来，不存在浪费。但是多活方案对于系统设计来说会更加复杂，需要考虑主备数据中心的数据高效同步。当主数据中心故障瘫痪后，将流量直接切换到备数据中心，确保业务无影响。同城多活的优势在于部署简单，业务侵入少，可以减少客户的实施成本。缺点在于由于主备数据中心仍然在同一区域，对于区域内的自然灾害没有抵御能力。
3. 异地不同机房
影响异地进行容灾设计的最大因素就是网络延时。一般来说，在100公里范围内，网络延时可以控制在5ms，在1000公里左右则是30ms。所以对于如果要实现异地多活，则不能按照同城多活的方式来考虑，假如杭州和成都，相距1000公里以上，一个服务调用需要50ms，那么如果某个业务请求涉及到10个以上服务掉哟给你，那么就至少需要500ms以上的时延，如果更多的请求，那么对于用户的体验必然下降。所以对于传统的金融行业来说，一般会采用两地三中心的方式，而对于淘宝这样的企业，则是从技术手段来实现异地多活。
3.1 两地三中心
两地三中心是将同城多活和冷备模式进行结合。本地建设可以独立承担业务系统运行的数据中心，双数据中心具备等同的业务处理能力并能实现数据同步，日常情况可以分担业务运行，并能灵活切换，同时在异地建设一个异地灾备数据中心，当双中心出现灾难故障时，可以通过备份数据进行业务的恢复。
3.2 异地多活
异地多活在同城多活的基础上进行了升级，具备同一区域内灾难的抵抗能力，如果 按照同城双活的方式进行部署，由于物理距离较远，网络延时会对业务系统造成较大的影响。为解决这个问题，可以将业务系统进行单元化设计，每个单元服务于本区域的业务，业务在单元内完成封闭处理，保障本地的快速响应，当故障产生时可以在不同的单元间进行切换。优点在于业务应用分布在多地并能同时对外提供服务，不仅解决了容灾本身的问题，同时保障了业务连续性，并实现业务容量的扩展。缺点在于改造成本高，需要梳理业务进行单元化改造。
多活容灾方案建设难点
对于数据中心如何实现完备的容灾建设有以下难点
1. 数据同步
要具备同步能力，包括数据库、缓存、消息、有状态服务、文件等数据 要支持单向同步或双向同步策略 对于异地（远距离），同步的性能和带宽保证
2. 流量控制
流量是多活容灾的核心。需要对接入层、应用层、数据层都做到流量可控，才能保障业务柔性抵御灾难。因此需要具备多层级多维度的流控规则策略，动态的流量调配能力，面对错误流量的纠错和保护能力。
3. 应用控制
需要应用能够支持业务闭环的机制（单元化），同时能够支撑灾难发生后面对新增流量的承载机制。对于业务闭环最直观的就是同一用户，session如何在异地实现共享，而对于新增流量的承载，基于现在的云计算和容器技术可以很好的实现弹性伸缩，但是对于本地IDC就要考虑是否需要增加资源冗余了。
4. 多数据中心的统一管控平台
由于基于多数据中心支撑多活容灾，那么对于各个数据中心需要有一个一站式管控平台，降低用户的运维和使用门槛，通过平台可以了解数据中心详情、流量详情、同时在面对灾难问题时可以一键切流。
5. 容灾切换质量保障
从流量、应用、数据三个维度如何对容灾切换进行状态检查与衡量，也需要可以直观体现，以便持续的优化和演进。
阿里多活容灾解决方案
从现有网上可以看到的资料来看，阿里是通过三个阶段来实现的，单元化、异地双活、异地多活。
1. 单元化
单元化的核心目标就是解决对于某个用户来说，能够让他的全部操作都在同一机房内完成。因为是同一机房，所以应用间相互调用不存在延时的挑战，同时单元化内的应用是核心业务应用，确保买家从浏览商品到买完东西，全流程都可以在单元化内最大限度完成。
单元又可以分为以下核心业务单元与中心单元。核心业务单元用来保证上述业务的封闭，而中心单元则是部署核心业务单元共享、数据要求强一致的应用，以及一些长尾应用。例如另外对于其他非交易类型的应用，由于买家用的不多，这部分流量相对较小，可以将这类应用部署在中心单元中。
这样的好处是兼顾应用的高可用以及成本。在异地部署时，并非全站，而是一组业务，这组业务就是单元，在淘宝就是交易单元。
2. 路由一致性
在进行单元化后，接着要面对的就是路由一致性问题。对于一个业务流量，必须保证能够数据的写操作必须进入到正确单元里，而不能跑到另一个单元去了，否则就会出现数据不一致的情况。所以需要有一套路由规则来保证。
3. 网络低延时
另外就是数据时延问题，阿里通过在每个城市的数据中心之间，以一个点作为自己的骨干网，以保障不同城市之间的网络质量，同是通过自研数据库层、中间件层等同步工具来确保在一秒以内数据同步完成。
4. 数据完整性和一致性
接下来就是数据的完整性和一致性。这些就需要多维度进行保障。例如切流后的写保护机制、中心化单元保障强一致，及最终一致性等。