网络传输的容灾及优化方案

作为运维，你是否遇到过一些用户域名解析异常，你是否又遇到过某些区域云商加速节点异常导致业务不可用，此时的你一脸茫然，不知所措？作为运维，你是否被最后一公里问题搞得焦头烂额？

那么今天我们就来探讨一下最后一公里网络传输上的容灾以及优化方案。

目前大多数公司为解决最后一公里问题基本都是选择云商的各种加速服务，但是它的稳定性也直接影响到业务的可用性，如何优雅的做容灾以及如何提高最后一公里的接入成功率，是亟待解决的问题。

本文将结合 ZEGO 业务中的具体实践，介绍一种在 SDK 侧感知异常并进行自动容灾切换的方案。通过该方案可有效降低业务对云商加速异常的敏感，提高业务的可用性，同时可以提高用户在弱网环境下接入的成功率。该方案能有效提升用户体验和系统高可用，也希望我们的经验能够帮助到更多的技术团队。

问题与弊端

首先来介绍下当最后一公里接入质量不好时，终端用户的接入服务通常会遇到的问题：

• 弱网环境接入失败或者时延较大
• 协议被禁
• DNS解析失败
• 域名被劫持

大多数公司会采用的云商加速，这确实能解决较多最后一公里的一些问题，特别是全球化业务的情况下，云商有更多的边缘节点去覆盖最后一公里的用户，云商加速已经成为很多公司不可或缺的一部分。在实际业务生产中，我们通常会将较多的 Http、WebSocket 等请求走云商加速，以享受其边缘节点缓存和就近接入的加速。但是在享用云商加速服务带来更好体验的同时，也经常会被云商故障所影响，比如因加速边缘节点异常，导致访问失败。

每一次的云商加速故障，我们往往没有较快的方式恢复，只能手动去掉加速选择直连或者更换加速的云商或者寄希望于云商快速解决。但始终有几个问题无法很好解决：

• 时效性：当云商加速出现问题时，运维人员会手动进行域名切换，因为需要人为操作，响应时长就很难保证。另外，切换后故障恢复时间也无法准确保障；
• 有效性：切换至直连或者备份云商后，因为 Local DNS 缓存，无法及时生效等问题；
• 风险性：切换整个集群的域名，本身是个较大变更风险。

针对以上问题 ZEGO 自研统一接入服务，通过 SDK 配合统一接入服务进行容灾容错。该方案不仅能够有效降低云商加速异常对业务的影响，还能提高终端用户的接入成功率，现在 ZEGO 官网最新版本 SDK 默认支持统一接入。

ZEGO 统一接入方案的设计思路与效果

在正式介绍实现原理之前，先给大家看下优化前后 SDK 第一次接入后端服务方式（后续的请求过程不再依赖 DNS）的对比：

优化前的接入方式：

优化前的端侧 SDK 接入后端服务主要步骤有 4 部分组成：

• 初始化 SDK：主要负责 SDK 就绪前的一个初始化动作，加载配置等一些关键信息
• DNS域名解析：SDK 初始化之后，拿到柔性配置中的域名开始进行域名解析
• 云商加速域名：DNS 解析云商的加速域名正常可以得到一个加速节点进行访问
• 回源服务域名：这个域名是回源域名，直接 A 记录到后端服务

此方案的不足之处就是，当 DNS 解析失败或者云商加速节点故障，就会失败。

优化后的接入方式：

新增统一接入服务后，我们在原有流程上新增统一接入流程，此流程弥补了 DNS 解析失败和云商加速失败的不足，整体流程如下：

1、方案设计思路

为更好的接入终端用户，降低云商异常对业务的影响，提高业务可用性，同时降低运维同学在运维方面的压力，在方案设计之初，我们确定了以下目标：

• SDK 自动切换主备域名：在主域名异常时，端侧能第一时间感知并自动切换备用域名进行加载重试，减少对人为操作的依赖；
• 统一接入支持多协议接入：支持 QUIC、TCP 等多协议接入，避免协议被封情况；
• 域名解析失败无影响：支持在公共 DNS 故障无法解析的情况下依然能够正常获得接入点节点;
• 兜底 IP：在所有的容灾策略都失效的情况下，可以直接访问兜底的 IP。

一直以来，弱网环境下的接入成功率都是比较低的，但仅仅依靠链路层面上的保障，很难处理局部问题和实现快速止损。用户终端作为业务的最终投放载体，对资源接入有着天然的独立性和敏感性。如果将容灾前置到终端侧，无论从时效性，精准性，都是传统的直接访问域名的方式无法比拟的。

在端侧进行容灾，就需要感知服务的可用性，然后实现端侧自动切换和自愈的能力。

2、实现原理

统一接入层在全球范围内提供面向端侧 SDK、支持多种协议接入方式（如 QUIC、TCP 单流和 TCP 多路复用协议），提供 HTTP 类请求、TCP 长连接的代理服务。统一接入充分利用 ZEGO 全球 200+ 机房的优势就近接入用户，实现丝滑接入。

统一接入整体方案简易图：

此方案主要包括 3 个主要模块：

• ZNS：主要提供域名解析能力，当公共 DNS 出现问题的时候，ZNS 能够依然保障域名能解析出节点；
• access-ctrl：主要提供统一调度的能力，根据端侧的客户端 IP 调度返回符合客户端最佳接入的统一接入节点。
• access-node：统一接入节点，能够提供多协议接入的节点，转发后端服务。

3、容灾逻辑

• 当 SDK 初始化成功之后，会优先使用公共 DNS 进行域名解析(可配置或者优先 ZNS 解析)；
• 当公共 DNS 解析失败时，ZNS 使用首先使用 UDP 协议进行请求解析，当时 UDP 协议失败时，会再次同时发起 UDP 和 TCP 协议再次发起请求；
• 域名解析成功后，会进行统一调度请求，当统一调度请求失败时，SDK 会同时使用 QUIC 和 HTTP 协议再次发起调度请求；
• 统一调度请求成功后，SDK 会发起统一接入请求，统一接入连接失败时，会尝试使用QUIC，TCP 等不同协议再次请求；
• 当统一接入请求失败时，会走云商加速的逻辑进行尝试连接。云商加速也有不同云商的加速容灾进行切换；
• 走云商加速依然失败，会走到兜底 IP 的逻辑；通过直连服务端负载均衡 IP。

4、优化效果

• 业务成功率
  以使用统一接入方案前后业务成功率对比，某 App 在 2022.03.14 开启统一接入之后，登录成功率由 96% 提升到 99%。

• 容灾优化
  2021-12-07：A 云商域名解析服务异常，导致大面积域名无法解析，故障 49 分钟。
  使用了支持开启了统一接入的 SDK 版本的客户避免了故障，大大提高了服务的可用性。

5、适用场景

适用所有依赖 CDN 全站加速，域名解析等服务，希望降低异常网络环境对业务影响的端侧场景，包括 Web、SSR Web、Native 等技术场景。

总结

经过不断的建设与发展，统一接入方案日趋成熟，在最后一公里的接入上容灾优化明显，现已成为 ZEGO 默认接入使用的公共服务。在多次域名解析故障，云商加速故障中发挥了巨大的作用。

在端侧，当前该方案日均容灾 10万+次；在运维侧，实现了精准告警，同时丰富了异常信息，大大提高了运维问题排查效率。

自从方案大规模落地以来，云商加速异常时鲜有手动切换操作，极大减轻了运维同学的运维压力。