摘要：本文介绍了HTTPDNS服务从中心迁移至边缘详细的落地过程。主要内容为：
HTTPDNS下沉边缘实践遇到的挑战，包括服务放置、流量调度 HTTPDNS下沉边缘解决方案 从性能、成本出发，谈谈HTTPDNS下沉边缘后的收益
传统的DNS流程中，客户端基于UDP协议向Local DNS服务器发送DNS查询请求，这个过程中会存在缓存刷新不可控、DNS劫持、解析结果跨网、解析超时等风险，近年来，HTTPDNS解决方案逐渐兴起。HTTPDNS是面向多端应用（移动端APP，PC客户端应用）的域名解析服务，通过使用HTTP或HTTPS协议替代传统的UDP协议，客户端的域名解析请求直接由HTTPDNS服务器接收和响应，实现了域名防劫持、精准调度、解析结果及时生效。
以字节跳动内部业务为例，如抖音、今日头条、西瓜视频和番茄小说等，QPS峰值达千万级，解析请求量日达万亿次，日常流量极大，为保障业务稳定运行，应用了火山引擎移动解析HTTPDNS（以下简称HTTPDNS）为域名提供递归DNS服务，支撑起超大解析请求量。
由于HTTPDNS服务全面覆盖字节跳动头部APP，在节约成本以及性能优化上存在强烈诉求，在此背景下HTTPDNS团队经过调研，决定将HTTPDNS服务从中心迁移至边缘，以下将从实践难点、解决方案和收益多个维度分享详细落地过程。
一、HTTPDNS下沉边缘实践挑战
1.服务放置
由于边缘计算节点分散、基础设施异构等原因，边缘服务放置一度成为下沉边缘过程中的研究热点，现有方案在处理边缘放置问题时，会将其转化为指定场景下资源约束的目标优化问题，针对成本、质量、流量方向，行业内均有对应研究：
针对成本，有研究通过多云的模式进行最小冗余成本建模，来实现资源动态分配。
针对质量，有研究通过构建服务依赖模型、最佳冗余动态算法保障可靠性，以及成本和质量均衡模型，来实现质量保障。
针对流量，有研究从流量迁移、设备移动、时空轨迹以及资源预部署等，实现流量稳定迁移。
在实际应用过程中，流量及设备迁移特征显著、边缘节点性能差异、稳定性波动大等因素，会干扰现有放置问题模型，因此需要进一步探索基于流量特征和边缘节点资源质量的放置问题。
2.流量调度
边缘计算的流量调度场景主要分为端边调度和云边调度，部分场景会出现边边调度。不同调度阶段拥有相对成熟的调度技术，包括基于DNS的端边调度、基于BGP ANYCAST的骨干网路由调度以及云网络下的云原生流量调度。
实践过程中面临的流量调度挑战，主要围绕着端边调度和云边调度：
端边调度挑战：5G和工业互联网接入的大量异构设备，以及设备迁移导致的流量波动，是端边调度需要应对的主要挑战。解决这一问题可借助云边协同作业与全局分布式调度的策略。然而，实际操作遇到的难题主要在于缺乏精确的调度手段，并且未能充分利用客户端与边缘节点之间协同联动的潜力。尽管通过实时流量感知配合机器学习进行训练是一种可行的方法，但这种方案处理的数据量巨大，导致应用成本过高，难以满足现实需求。
云边调度挑战：边缘计算由于其固有特性，在处理大规模集中式数据方面相较于传统中心化架构存在一定局限性。因此，云边协同的流量处理和计算模式采纳了业界广泛认可的计算架构，云边调度发挥了云计算与边缘计算各自的优势，达成数据和流量的更高效处理。然而，边缘计算在资源分配上仍面临局部不足与全局分散的挑战。举例来说，在约束优化路由模型中，评价指标有时与实际业务场景不符，未能充分考虑用户体验。此外，行业内某些区域分层调度模型在实际应用中遇到了边缘基础设施不统一的问题，同时区域内及区域间的容灾问题也尤为突出。
二、HTTPDNS下沉边缘解决方案
1.可视化评价模型指导服务放置
针对基于流量特征和边缘节点资源质量的放置问题，在实践过程方案，HTTPDNS团队不断进行尝试优化，最终选择通过使用全链路的拨测和数据采集方法，基于实时数据驱动的模式，进行在线的放置算法仿真训练，形成可视化的评价模型，以指导HTTPDNS服务在边缘机房的节点选择和服务放置。基本流程如下图：
2.接入GTM打造调度解决方案
针对流量调度挑战，由于内部服务采用域名（配合兜底策略）的接入方式，接入域名配置DNS智能解析实现用户就近访问边缘接入节点。考虑到边缘接入节点IP的网络服务可靠性和质量对比IDC机房优势不明显，因此HTTPDNS团队最终决定引入云调度GTM解决调度问题。
火山引擎云调度GTM基于解析进行流量调度，可以实现流量的就近接入（地理位置/性能）、负载均衡。GTM借助分布式、多协议健康检查能力来实现故障容灾（Failover），诸如“同城容灾”、“异地多活”等场景。此外GTM还提供了多云环境下的流量编排、资源粘合能力，可视化的健康检查数据分析、操作日志等功能帮助排查定位问题，便于日常运维。
前期公众号介绍过云调度GTM，想了解更多的小伙伴可以点击这里：
重点应用：
智能调度：通过云调度GTM的「智能调度-容量优先」模式实现基于机房容量的智能调度，在满足机房容量的前提下生成全局时延最低的DNS调度规则，从而能够在边缘节点割接/故障时实现自动容灾；
故障容灾：支持边缘节点通过控制台、API接口和Agent的方式上报节点容量等信息，基于节点的数据上报情况和健康检查探测的情况，云调度GTM作为策略中心更新和下发调度策略，实现边缘节点的故障容灾。
调度解决方案优势：
建设成本低：部署轻量，架构侵入较小，建设成本较低；整体配置和管理简单；
动态调度保障性能最优：在边缘多节点、多机房的场景下，能够基于性能和容量进行动态调度，在确保机房水位低于目标水位的前提下实现全局性能最优；
支持可视化：支持调度配置和结果的可视化展示、健康检查可视化查询。
应用火山引擎云调度GTM来实现容量调度是一次新的尝试，在全面接入云调度GTM之后，对比传统域名智能解析调度模式，边缘节点容量调度模式能从性能、容灾、成本等方面带来收益，也验证了云调度GTM在方案中不可或缺的重要性。
调度解决方案收益：
| 指标类型 | 指标 | 收益 | 总结 |
| 性能 | 请求时延 | 平均接入时延 -5.01%（-11ms） | 整体延时优化5% 流量调度漂移减少 15% |
| 请求成功率 | 持平 | ||
| TTFB | 平均 TTFB -4.1%（-3.5ms） | ||
| 流量波动 | cpu负载波动标准差：5%->1%，优化80% | ||
| 容灾 | 自动容灾成功率 | 100% | 智能解析线路级故障感知 60 秒自动容灾 |
| 边缘故障感知耗时 | 60s | ||
| 流量收敛时长 | 3min 90%+收敛 | ||
| 成本 | 带宽成本 | 回源带宽降低 10% | 运维：配置、切流管理，完全自动托管 容灾：从预案模式10分钟， 到自动容灾1 分钟 资源成本：cpu冗余量可减少 20% |
| 成本 | 运维成本 | 易用：基于容量&性能矩阵，均匀分流。仅需要用户维护机房容量信息。 好用：火山控制台一键完成调度策略计算，流量调度结果支持可视化。机房故障自动重调度，机房裁撤一键完成流量重分配。 复杂场景支持：新建机房快速完成接入调度。大面积故障场景容灾自动化高。 |
三、更强大的解析调度，性能提升20%+
实践过程持续了六个月时间，在成本优化与性能提升方面均取得显著效果。
1.成本优化
总成本优化约35%，其中负载均衡资源优化约50%，计算资源优化约30%，带宽成本优化约70%，且最终实现了边缘集群总容量千万 QPS 级别，与中心机房完全互备。
2.性能提升
完成从中心到边缘的迁移后，火山引擎移动解析HTTPDNS服务性能出现显著提升，对比同类服务出现显著优势。
在边缘服务建设完成后，我们逐步将原中心机房承载的千万 QPS 级别流量迁移到边缘服务集群上。根据实际的性能提升情况， 先后将全国大部分区域的三大运营商接入流量迁移到边缘。在这个过程中，我们关注并采集流量的网络指标变化数据，各个区域均有性能收益，详见下表：
| 下沉区域 | 总耗时-平均值-差异百分比(%) | 总耗时-50分位-差异百分比(%) | TTFB-平均值-差异百分比(%) | TTFB-50分位-差异百分比(%) |
| 西南 | -15 | -44 | -38 | -64 |
| 西北 | -16 | -36 | -36 | -47 |
| 东北 | -10 | -14 | -15 | -23 |
| 华北 | -16 | -41 | -29 | -63 |
| 华中 | -23 | -50 | -37 | -70 |
| 华南 | -7 | -15 | -11 | -36 |
为了能够更直观感受火山引擎移动解析HTTPDNS服务与其他HTTPDNS服务的性能数据对比，我们使用国内主流的第三方拨测平台，进行了近千个拨测节点、覆盖全国的拨测对比。从拨测结果可以看出，不论是从地理位置上，还是分运营商讨论，火山引擎移动解析HTTPDNS都在首屏时间、建立连接时间、首包时间和内容下载时间上表现优异，最终实现总下载时间实现领先。
全国：
| 厂商 | 总下载时间(s) | 首屏时间(s) | 建立连接时间(s) | 首包时间(s) | 内容下载时间(s) |
| 火山 HTTPDNS | 0.252 | 0.254 | 0.024 | 0.026 | 0.037 |
| 其他-1 HTTPDNS | 0.279 | 0.282 | 0.035 | 0.04 | 0.039 |
| 其他-2 HTTPDNS | 0.327 | 0.329 | 0.05 | 0.063 | 0.039 |
分运营商:
| 运营商 | 厂商 | 总下载时间(s) | 首屏时间(s) | 建立连接时间(s) | 首包时间(s) | 内容下载时间(s) |
| 中国电信 | 火山 HTTPDNS | 0.26 | 0.263 | 0.023 | 0.027 | 0.031 |
| 中国联通 | 火山 HTTPDNS | 0.242 | 0.244 | 0.024 | 0.026 | 0.04 |
| 中国移动 | 火山 HTTPDNS | 0.256 | 0.257 | 0.024 | 0.026 | 0.038 |
| 中国电信 | 其他-1 HTTPDNS | 0.287 | 0.291 | 0.034 | 0.04 | 0.034 |
| 中国联通 | 其他-1 HTTPDNS | 0.272 | 0.275 | 0.036 | 0.041 | 0.043 |
| 中国移动 | 其他-1 HTTPDNS | 0.279 | 0.28 | 0.036 | 0.038 | 0.041 |
| 中国电信 | 其他-2 HTTPDNS | 0.33 | 0.333 | 0.049 | 0.061 | 0.033 |
| 中国联通 | 其他-2 HTTPDNS | 0.33 | 0.332 | 0.053 | 0.068 | 0.043 |
| 中国移动 | 其他-2 HTTPDNS | 0.32 | 0.321 | 0.049 | 0.06 | 0.041 |
总结
整体下沉实践方案中，HTTPDNS团队不断进行新尝试，探索并应用了基于GTM的反馈式调度模型，更好地应对了边缘计算资源局部紧张、全局分散以及稳定性抖动频繁的挑战，从而弱化边缘放置问题带来的资源开销，并提升流量调度效率、资源利用率以及降低容灾和运维难度。
通过下沉边缘，HTTPDNS进一步优化使用成本，提升服务性能，而此次实践通过将HTTPDNS服务从中心云架构迁移至边缘云架构模式，使边缘计算在互联网传统业务场景中得到应用，也是边缘云云原生的一次工程探索实践。
本项目应用了火山引擎边缘计算多个产品服务，不仅使用了边缘网络提供的四、七层负载均衡产品，还将HTTPDNS服务全部运行在边缘容器上，通过弹性公网IP完成边缘服务的回源以及控制。HTTPDNS联动边缘计算打造的下沉边缘实践案例，作为行业实践，希望为同行业提供一些有益参考。
未来，HTTPDNS团队将持续探索边缘计算容器化弹性调度技术的应用，应对亿级接入、千万QPS流量所带来的流量迁移、接入抖动问题，并进一步提升设备利用率并节约成本。
如有侵权请联系:admin#unsafe.sh