共计 2643 个字符，预计需要花费 7 分钟才能阅读完成。
随着企业一直推动数字化过程，高并发业务和海量数据的挑战也随之而来。在现实生活中，除了地震、台风、挖光纤这种小概率事件，还有很多人为造成的高概率数据失落事件，比方人为操作失误、硬件故障、网络攻击等等，故障容灾能力的重要性也因而逐步凸显进去。依据地理位置的不同，灾备计划往往分为同城和异地，明天重点介绍的就是 GTM 在互联网服务“同城容灾”和“异地多活”场景下的实际利用。
本文带你理解火山引擎边缘云 TrafficRoute DNS 套件——云调度 GTM，它是火山引擎 TrafficRoute 解析调度套件中的全局流量治理服务，基于 DNS 进行流量治理。如果你的业务须要就近接入、负载平衡、流量调度和故障容灾能力，那么火山引擎云调度 GTM 能够帮忙到你。
云调度 GTM
对照以下表格，咱们先来了解 GTM 的根本能力，再看这些能力在实现过程中如何应答不同的调度和故障场景。
互联网服务的“同城容灾”
当用户服务部署在同一个区域的多个机房时，如私有云的 XX 云在华东某个城市蕴含两个可用区机房 1 / 机房 2，一旦其中某个机房产生故障，将基于预案进行主动或手动故障转移，确保服务不中断或疾速复原。
同城容灾有以下 3 种参考模式：
冷备：同区域的 2 个机房采纳“主 - 备”模式，即主机房平时承载流量，备机房不承载流量，当主机房故障时，流量迁徙到备机房。该模式部署简略，但有两个毛病：第一是平时状态下的资源节约；第二是主机房故障时，因为平时没有流量，备机房的后端配置、容量、各零碎状态等是否“Ready”是不可知的。
热备：同区域的两个机房采纳“主 - 备”模式，主机房平时承载次要流量，备机房承载大量流量，这部分流量用来验证备机房的性能是否可用。这个模式解决了故障产生时备机房没有筹备好的问题，但还是无奈解决常态下一半资源的节约和备用机房有可能呈现容量有余的问题。
双活：同区域的两个机房在常态下同时进行工作，当一个机房故障时，流量切换到另一个机房。因为常态下的同时工作，所以不存在是否“Ready”的问题，只须要关注故障时另一个机房是否承载流量即可。这个模式下，同一个区域多个机房也是可行的，冗余会更高，对非故障机房承载故障机房流量时，要保留“残余容量”的要求就更低了，当然多个机房也可能带来数据 / 配置一致性等问题。实用场景同城容灾实用于间隔较近的场景，包含同城多个机房、几个相邻的自建机房通过流量转发组成“同城 / 区域”等状况，反对通过主备（冷、热备）、双活（多活）等模式实现同城状况下的容灾，典型例子就是私有云同城外部的若干机房之间的容灾。
注：上述“冷备”，“热备”等名词定义并不谨严，文内只为解释不同模式之间的区别。
参考架构
架构图中，将私有云的 Region 替换成“同城”，AZ 换成一般机房也同样实用。这种状况下，机房入口（例如一个 Region）应用一个负载平衡的 CNAME 标记集群是能够的，同时集群外部，如多个 AZ 之间也反对流量互相转发，负载平衡层面对用户会屏蔽 AZ 的细节。
劣势介绍
低成本：建设成本低、架构入侵小、适配性强；配置和治理简略；确保多 IDC 环境下服务不中断或者疾速复原；
按需抉择：可依据须要实现“冷备”、“热备”和“双活（多活）”；
灵便配置：反对健康检查和主动容灾，也反对手动模式和多个预案的配置（联合在多个 PoolSet 间切换）；
方便管理：便于进行流量灰度和 AB 测试、流量机房间迁徙等。
计划实际
互联网服务的“异地多活”
在同城容灾的根底上，流量的调度容灾能够扩大到更大的范畴。为了在性能、冗余（数据备份）和容灾上有更多的余地，全国 / 全球性的互联网服务通常采纳多核心场景，蕴含多云、混合云，这要求咱们不仅要做到同城一个机房 / 单个 AZ 故障时的容灾，也要做到多个地区部署服务时，地区级别故障下的异地灾备，确保服务的间断工作。当然，这须要解决多个地区、机房之间的流量平衡问题，确保每个机房的水位平安。这就波及到了异地灾备计划，因为异地的 IDC 转发延时较同城大，Region 间的流量转发通常存在性能、老本等问题，能够通过做异地多活架构来代替流量转发，多个私有云的 Region 大体属于此类情况。
因为异地多活是一个绝对简单的话题，例如如何保持数据的一致性等，所以咱们更关注从公网流量角度登程，进行容灾“多活”的动作。实用场景机房位于全国 / 寰球多个地位，须要实现按地区的流量调度 / 平衡、跨地区的备份和流量灾备。例如，私有云多个区域之间的“多活”，或者间隔较远的几个自建外围机房之间的灾备和服务多活。
参考架构
上图是参考架构示意图，更关注内部流量的容灾计划。机房外部服务有多种抉择，VM、容器、微服务等，而 DB、MQ、缓存等的异地容灾也应该独自思考。
劣势介绍
部署简略：建设成本低、架构入侵小、适配性强；配置和治理简略；同时具备区域内多个机房（AZ）和跨区域的容灾能力；AZ 故障时由 LB 进行同 Region 其余 AZ 转发，能够实现大家常说的“两地三核心”+“同城容灾 / 异地多活”；
多种模式：反对健康检查、主动容灾和手动模式，手动模式便于配置多个供选择的容灾预案；
多区可用：实用于多机房、多 Region 流量平衡、灰度和 AB 测试；
对立治理：可实现多地区、多机房、运营商、IP 流量的对立治理和调度。计划实际
写在最初
欠缺的灾备计划在保障业务的持续性上不可或缺，火山引擎云调度 GTM 基于解析进行流量调度，能够实现流量的就近接入（地理位置 / 性能）、负载平衡。GTM 借助分布式、多协定健康检查能力来实现故障容灾（Failover），诸如上文说到的“同城容灾”、“异地多活”等场景。此外 GTM 还提供了多云环境下的流量编排、资源粘合能力，可视化的健康检查数据分析、操作日志等性能帮忙排查定位问题，便于日常运维。
以后，TrafficRoute DNS 套件下的各个产品，包含云调度 GTM、私网解析 PrivateZone、挪动解析 HTTPDNS 和公共解析 PublicDNS，服务了抖音，头条，飞书和火山引擎 ALB、CDN、动静减速、存储等各类 APP 和云产品，具备重要产品稳固服务的能力，在技术、老本、性能和产品成熟度方面领有深厚积攒。
TrafficRoute DNS 套件已正式上线火山引擎官网，欢送拜访【火山引擎官网】，理解更多 TrafficRoute DNS 套件相干信息。
对于火山引擎边缘云：
火山引擎边缘云，以云原生技术为根底底座，交融异构算力和边缘网络，构建在大规模边缘基础设施之上的云计算服务，造成以边缘地位的计算、网络、存储、平安、智能为外围能力的新一代分布式云计算解决方案。
