接入层的新思考：一文看懂接入层高可用设计

1. 背景

接触多家客户后，发现大家的接入层架构大都如下图所示，WAF/DDoS组件客户要么选其中之一，要么都不选或自建。CLB后面挂CVM，CVM上面部署Nginx或者Kong等组件。

从这个架构图可以看出，客户有考虑高可用，但仅关注自己的组件层面，没有关注外部基础设施(如DNS)、政策法规的影响、运营商链路的不稳定性等，所以往往并不不全面。要分析优化这个问题，就要先搞清楚接入层定义、接入层故障域和经典接入层架构的不足。

2. 什么是接入层

2.1 狭义接入层

我们通常理解的接入层，是直面用户的系统组件，具有公网IP的设备，如负载均衡器、公网Nginx、自研gateway等，从实践经验来看，大家讨论比较多的接入层高可用、稳定性往往是这个层面。(参考上面接入层架构图)

2.2 广义接入层

思考一下用户的请求是怎么到业务系统的？用户首先打开终端(浏览器、APP等)，然后需要经过dns服务器解析出来域名的目标IP，然后经过公网，访问到了我们业务系统的公网组件；隐藏在其中的还有DNS的递归解析、运营商网络设备、国家管局的管控等。所有这些事项，都跟用户访问成功有关，我称它为广义接入层。如下图：

2.3 结论

那我们讨论接入层建设时，应该采用广义视角还是狭义视角？

试想，如果运营商网络拥塞、路由绕行，用户访问你业务的请求没办法达成或延迟升高、此时你能说自己业务的可用性好么？所以，为了保证可用性，我倾向于从广义接入层角度来考虑稳定性建设。

3. 接入层的故障域与应对方案

定义清楚我们要解决的接入层问题后，先看看接入层都会遇到什么样的故障以及潜在的应对方式。从下表(当然还有其他故障)可以看出，接入层的故障来源是多维度的，就需要我们针对每个维度做特定的设计。

4. 接入层实战

如果要实现上面故障域的解决，需要投入大量成本，比如自建接入点+自建专线；引入更多的故障点，比如访问链路上增加了DDoS/WAF；相应的运维成本也有极大的增加。

通过调研，发现了腾讯云的一款宝藏产品：EdgeOne，可以作为统一接入网关，一站式解决上面的问题。

跟EdgeOne sre沟通后得知，这款产品的未来重要发展方向之一就是统一接入网关和一站式高可用解决方案平台。

从高可用建设角度来看，产品本身支持接入层全链路的高可用配置项、无需引入多组件、自研运维平台等工作，非常值得试用和钻研。

下面我就以腾讯云的EdgeOne为例，展示通过这个组件实现我们接入层高可用实战。

开始下面的文章之前，要先将域名接入EO，具体步骤参考官网(已经很清晰了)边缘安全加速平台 EO 从零开始快速接入 EdgeOne-快速入门，这里不再赘述

4.1 DNS故障和政策法规

4.1.1 单域名被封禁

域名被封禁，如果有备用域名，业务就不会立马中断，有时间去争取尽快解封。

大概的流程是：

1、 先创建加速域名

2、 将备用域名解析到加速域名。这里可以接入test.xx.com和test2.xx.com做测试

具体操作参考边缘安全加速平台 EO 通过别称域名批量接入

4.1.2 Local DNS被劫持

可以借助HttpDNS，把备用域名通过CNAME解析到目标加速域名上，加速域名不对外提供服务，就可以规避Local DNS被劫持的问题。

4.2 接入层组件

采用EO后，接入层变成了如下架构：

从架构图可以看出，潜在风险在于EO集群可用性、源站可用性，这里EO产品也给出了高可用解决方案

4.2.1 源站高可用

从EO角度，源站高可用主要是指EO回源的冗余。EO提供了源站组的功能实现冗余。

1、新建源站组

2、添加域名

3、加速API

4、 配置成功

5、 验证

访问加速域名，结果在0、1两个页面轮流出现

把0对应的设备关机够，页面就仅出现1了。ps：第一次需要等0对应的设备超时后，后面才会一直到1对应的设备。

由此可见，EO本身可以作为负载均衡器使用，用于后端配置多源站，实现源站高可用。

4.2.2 跨云调度实现EO灾备

从系统角度，EO本身也会出问题。EO提供了跨云调度的功能，实现EO本身的冗余。

与源站高可用类似，可以将加速域名分配多加速服务上，按地域实现调度。当某个服务商故障时，可修改策略或走默认策略，实现跨云间调度

具体操作参考：边缘安全加速平台 EO 通过流量调度至多厂商服务-最佳实践-文档中心-腾讯云

4.3 运营商

传统经过运营商的网络，对用户来讲是一个黑盒；采用EO后，我们就可以通过智能路由动态选路，如下图

4.3.1 CNAME加速

传统业务采用CDN时，大都采用CNAME方式，解析耗时相对于A记录，会有N倍的增加。原理如下：

传统解析路径，一个CNAME解析会有多次交互

经过CNAME加速后，一次交互即可拿到结果，与A记录一致。

验证过程

1、 准备加速域名

2、 准备别称域名

3、 验证方式

通过dig命令，来测试加速域名的目标域名及别称域名，如下图：

4、 验证结果

从上表可见，加速生效了

4.3.2 静态内容加速

大家都比较熟悉了，边缘节点更贴近用户，有效降低了数据访问时间延迟，避免数据传输抖动，保障大量数据传输的稳定性和有效性。

4.3.3 对于动态内容加速

原本用户访问是走公网传输，具体路径不可控导致延时不可控。从上面访问链路图可以见，EO产品借助自建专线提供了动态数据加速，跨国加速，智能路由优化等加速特性，保证高效支撑对时延敏感的相关业务。

EO边缘节点到源站速度，经过专线加速后，相当于走了高速公路，避免路由绕行、拥塞的烦恼。

1、启用智能加速

2、配置加速域名

3、配置动态加速引擎

4、测试结果

通过下面测试，可以看出，相比于直通源站，加速后的域名离用户更近；然后加速节点走内网到达源站

4.4 安全提升

4.4.1 DDoS

分布式拒绝服务攻击（Distributed Denial of Service，DDoS）是指攻击者通过网络远程控制大量僵尸主机向一个或多个目标发送大量攻击请求，堵塞目标服务器的网络带宽或耗尽目标服务器的系统资源，导致其无法响应正常的服务请求。

传统的防御方式，是在单一入口，提供更高的带宽+清洗能力来硬扛。但单一地域的带宽总有上限，而EO可以借助多地能力，最高支撑T级的防护带宽，安全感十足。防护种类也比较丰富，可以对SYN、ACK、ICMP等数据包做防护。

4.4.2 Web攻击

对于大部分互联网人员来说，SQL 注入、CC攻击、XSS 攻击、开源组件漏洞等多种攻击方式都不陌生，要么是自研WAF进行防御，要么是借助云厂商的WAF。现在EO默认集成了这些功能，运维成本、组件成本大大降低。

5. 其他

本文仅从基础设施角度展开接入层该有的样子，并没有讨论接入层的业务属性，比如降级、限流、熔断、统一认证等功能，预计后面展开聊聊。

从整体功能来看，EO可以做到一站式的实现接入层的稳定性建设，值得尝试。但是也有一些小瑕疵，比如不能做到全局的WAF，当前的安全规则阈值是针对单节点的，我们不知道EO有多少节点，所以规则阈值有不准确的风险；对于特殊协议不支持；动态加速效果呈现方面，没有直观的工具等

对内容有任何疑问，可以在评论区找我留言讨论。

我正在参与2023腾讯技术创作特训营第二期有奖征文，瓜分万元奖池和键盘手表