10 月 18 日，在 QCon 全球软件开发大会 2024（上海站），火山引擎边缘云网络研发工程师赵彦奇分享了《HTTPDNS 边缘下沉，性能、成本和稳定性之间的取舍与思考》，在一众 AIGC、LLM 等当下热门议题中脱颖而出，通过 QCon 组委会的主观评价及参会者在现场提交的实时数据反馈等维度综合评估，被评选为 QCon 上海 2024 的明星讲师之一。
演讲主要介绍了火山引擎 HTTPDNS 边缘云原生技术实践经验，从火山引擎 HTTPDNS 迁移至边缘的必要性出发，围绕实践过程当中遇到的困难和挑战，打造 HTTPDNS 下沉边缘解决方案，最终实现了性能提升、成本下降的全过程，以及对整体实践的回顾与未来展望。
以下是演讲实录：
大家好，我今天分享的内容主要是火山引擎 HTTPDNS 边缘云原生技术实践。HTTPDNS 是服务于抖音集团几乎 95% 移动端用户的移动端域名解析服务，通过这次改造，HTTPDNS 服务从中心云完全下沉到了边缘，业务上的收获是 20% 的性能提升、 35% 的成本优化。本次分享主要聚焦于 HTTPDNS 服务进行边缘云原生改造的必要性，面临了什么挑战以及解决方案，最后我将分享在工程和技术管理上，用了哪些比较好的方法论保障项目最终落地。
在分享之初，先为大家介绍一下团队。HTTPDNS 作为移动端域名解析服务，是火山引擎 TrafficRoute DNS 套件的重要子产品。火山引擎 TrafficRoute DNS 套件包括了云解析、云调度、移动解析、公共解析等，服务于抖音、头条、飞书、豆包，同时还向 CDN、IaaS 等基础设施提供成套的域名接入、解析和调度的解决方案。通过产品概览图，大家可以看到在整个互联网全链路中，我们的产品是如何提供服务的。
火山引擎 HTTPDNS 是面向多端应用的域名解析服务，适用于移动端 APP、PC 客户端等多种应用场景，在抖音集团内部，服务于抖音、头条、豆包等产品的移动端域名解析服务，支撑起峰值达到千万级的 QPS ，日达万亿次的解析请求量，作为长期部署在中心云的服务，对可靠性和成本要求都比较高，为什么选择做边缘云原生的改造呢？
主要还是基于业务，同时来自外部业务和团队内部的诉求驱动着架构改造：
外部驱动：随着抖音用户越来越多，HTTPDNS 的接入流量也从曾经的百万上涨到了千万级 QPS ，抖音集团业务希望 HTTPDNS 服务可以在缩减成本的基础上，降低解析时延，以此来提高业务收益；
内部痛点：服务部署在中心云，整体架构稳定的同时也限制了性能的优化空间，受限于在中心云机房的部署的，资源、带宽的价格都是固定的，在流量不变的情况下，很难进一步压缩成本、提升性能。业内通常会选择使用 Anycast 来优化网络接入的质量和性能，但国内 Anycast 存在类似于 pop 点吸流不准以及运营商之间 BGP 路由不能完全打通的问题，性能不及预期。
在此基础上，HTTPDNS 团队关注到边缘云架构，边缘云在泛互联网、游戏、智能驾驶等行业实现了很好的支撑，整个边缘云的生态和技术相对比较成熟，可能是 HTTPDNS 服务进一步降低成本、提升性能的好机遇。
作为承载大流量的服务，HTTPDNS 在应用边缘计算的时候会遇到一些挑战。
资源受限：首先，千万级流量的 QPS 需要海量的计算资源，边缘计算自身拥有将服务部署在离用户近的位置、分布广泛、节点多的优势，同时也存在每个节点的容量较小、资源受限的问题，一方面体现在流量需求和资源分布不均的情况，另一方面边缘侧基础设施相对云中心仍在完善中；
稳定性欠缺：其次，随着部署的节点越来越多，比如最早是三个 region 机房，当整体边缘下沉以后，大概会有近百个节点，这种情况会导致整个系统的运维复杂度上升，后期面临版本升级、不定期机房割接和裁撤等情况时，整个系统的可靠性会下降。
收益难评估：最后，由于要从中心云迁移到边缘云，整个架构上需要对云原生的组件重新做适配。相关的可观测能力，包括监控告警、日志分析、运维自动化能力都需要重新建设，整个项目周期比较长，架构改造比较大，对于需要投入很多资源和人力来做的这种项目，如果在前期不能很好地评估风险和收益，那么最终可能会导致项目失败。
基于以上基础，我们最终结合了工程和技术思路来推进实践：在工程上，我们通过可控的稳定性换取收益；在技术上，我们通过架构升级和运维自动化进一步提高稳定性。
HTTPDNS 服务在进行边缘云原生改造过程中遇到了哪些挑战？曾经引以为傲的成熟架构、完善体系，在中心云部署迁移到边缘云的时候，反而成为了很大的约束。因为架构成熟，所以对云组件的依赖特别强，因为体系完善，所以在中心云构建的一整套的运维自动化，以及容灾方案都需要在边缘云架构下重新构建。同时，HTTPDNS 服务是 APP 用户接入互联网的第一跳，一旦发生故障，严重的时候可能会导致抖音用户打开 APP 出现数秒的卡顿、直播推拉流场景下用户访问慢、在 CDN 调度场景可能出现调度不准，最终导致用户体验差等问题。
在 HTTPDNS 边缘云原生改造的实际工程应用中，面对复杂需求场景，存在以下四方面挑战：
实现最优部署难：HTTPDNS 支撑起千万级 QPS 、亿级连接，用户分布在全国各个地域，当资源和流量不对等的时候，需要进行边缘节点的选点和资源部署的规划，基于业务现状，实现最优部署比较困难。
交付速度慢：改造过程中会面临少量热点区域边缘计算客户需求大，资源紧张资源情况，影响整体交付速度。
运维复杂度提升：随着部署的边缘节点越来越多，分布式系统控制面需要重构，这个过程中会带来运维复杂度提升，此外，由于使用公网做控制面管控，系统的安全风险会变高，还需要重建可观测系统；
精准流量调度难：边缘计算节点的容量从数万到百万 QPS 不等，面对多数量节点、复杂流量分布，以及运营商跨省限流，使得实现精准流量调度难度上升。
为了论证项目的可行性，HTTPDNS 团队针对自身服务特征及技术架构优势，进行了详细分析。
在服务特性方面，HTTPDNS 为用户提供域名解析服务，支持将解析缓存到本地，按照 TTL 间隔更新，这种服务形态天然具备了无状态、可缓存的优势，基于这个优势，可以将无状态的部分优先下沉到边缘，释放无状态这部分的就近接入能力。
在配置编排方面，随着边缘云操作系统的完善，资源编排能力越来越强，同时高可靠的云边通道，也为 HTTPDNS 构建统一的分布式控制面，提供了通信可靠的保障。
在现有架构的优势方面，在中心机房部署服务时对云组件产生了强依赖，使用容器进行部署，将架构进行了模块化、解耦和分层，在模块之间的跨服务通信上，优化了通信协议的支持、质量保障，这些会为云原生技术改造带来架构上的优势。
以上是从技术角度进行分析，接下来从这个工程视角分析复杂度。
从 STACEY 矩阵来看，第一需要分析需求的明确性，第二需要分析技术的风险性。结合上面的讨论，我们知道边缘云原生实践的需求极其明确，是为了满足抖音等业务对成本和性能的追求，希望通过性能的提升给用户带来更好的体验，让用户在线时间更长，从而获得业务收益。既然需求已经明确，主要看技术上的风险，主要困难可以归纳成两点，一是服务的部署困难，二是流量的调度困难。虽然在中心云模式下，不管是流量的接入调度，还是服务部署、架构设计，都经过了很长时间的沉淀，但这种模式和解决方案应用在边缘到底能不能达到预期，是具有不确定性的。因此从 STACEY 矩阵来看，项目类型属于模糊型，应该选择敏捷式项目管理方式和开发模式，得出的结论是后续需要按照快速迭代、快速验证、快速交付的思路推进工程执行。
除了看自身的风险和优势以外，我们也参考了行业内 DNS 相关产品边缘化部署的案例。在海外，Akamai 的 Edge DNS 和 Cloudflare 的 DNS 利用自身基础设施建设的优势，充分发挥 Anycast 的骨干网能力，构建了一套完整、分布式的、边缘接入的权威 DNS 。虽然国内没有这么好用的 Anycast，但 Akamai 的 Edge DNS 为我们在做租户级别的隔离、设计高可靠的容灾方案等方面提供了很好的参考思路，Cloudflare 的 DNS 产品性能很好、安全性很高，也为我们在流量特别大的业务场景下实现性能优化提供了参考思路。
讨论完为什么要做这个项目，以及项目前期做的调研分析，下面和大家分享整个项目具体是怎么做的，以及项目过程中遇到了哪些有难度的技术问题和相关的解法。
回顾一下整个项目的过程，我们选择了敏捷式交付模式，这种模式的好处在于，首先我们可以尽快地把边缘云原生改造后的 HTTPDNS 产品露出给用户，优先让弱网地区、偏远地区的抖音用户享受到低成本的、高性能的 HTTPDNS 服务；其次，我们可以在每一阶段验证架构、收益，进一步优化容灾体系、运维体系，以确保整个项目是平稳、分阶段交付的，每个阶段的风险都是可控的。
第一阶段，主要是对最小概念模型加以验证。我们开设了客户端的 AB 实验，真实地采集抖音相关用户在体验侧的性能数据，判断是否有优化。在贵州地区进行的 AB 实验数据证明，首先，将缓存先下沉的模式没有问题，其次，整体的性能、成本上的收益符合预期。在此结论上，我们才能放心地推进项目。
第二阶段，主要是在西南地区，通过构建一个区域内的小集群来验证区域内的自动化容灾能力，目标是想在边缘节点之间，通过流量调度实现区域自治。
第三阶段，主要是进一步优化多级容灾方案，以及深度融合边缘云组件。举例来说，我们做到了无损升级，当我们通过容器发布新版本时，使用 K8s 的底层组件感知到这个事件，容器会和上游的 LB 进行路由联动，提前拆除路由转发路径，卸载用户流量，实现了整个升级过程的无损。
最后，当边缘云原生改造完成之后，我们既有中心机房提供简单地、可靠的 Anycast 的接入能力，又有边缘机房提供离用户很近的、低成本的 IP 接入能力，同时，我们需要进一步打磨统一的资源管控能力和统一的流量接入调度能力。
整个架构的演进模式也分为四个阶段，从最早的单体服务模式到无状态、有状态非离的模式，再到为了适应边缘云原生改造，将缓存优先下沉的模式，到最终形成了云边共存的架构模式。
第一阶段，简单的单体模式。比如，早期我们的流量只有百万级的 QPS ，但是抖音业务发展特别快，为了满足业务快速增长的需求，我们选择了比较简单的架构模式，短平快地交付产品来满足业务发展。
第二阶段，随着业务发展，我们对系统进行了架构分层、内部解耦的模块化改造。经过多轮改造，我们将系统分为了协议、缓存、接入、递归四个层次，这四个层次有的无状态，有的有状态，比如缓存层能够做到完全无状态，接入层能感知到任意一个用户的请求，从中获取用户的设备类型、地理位置、请求的内容等，递归层聚焦在 DNS 服务基础上，把 DNS 解析做得更好，同时，我们将有状态和无状态的层次分离出来。
第三、第四阶段，是推进边缘云原生改造工程实践过程中做的事情，先将已经分离的无状态的服务层下沉到边缘，优先发挥性能和成本的优势，最后形成云边共存的架构，进一步打磨流量调度和资源统一管理的能力。
在这个过程中有两个核心问题。一个是流量和资源的冲突，一个是性能与稳定性的冲突。
第一个核心问题是资源和流量的冲突。
我们的流量比较大，同时用户分布在全国各地，分布十分广泛，右边上面的图基本上代表了我们的服务在全国各个运营商、各个省份接受到的请求的分布，可以看到基本上能和省份的人口对齐。下面的图是当前每个省份和运营商对应的用户，访问服务的网络接入耗时情况，整体还是不错的，但有极个别地区的访问延时比较大，我们在进行边缘云原生改造的时候，会优先用户规模大、接入耗时较高的省份。
流量的广泛分布会对资源提出要求。假设贵州地区大概需要 100 万的 QPS 来满足用户的接入需求，但是边缘节点在这个地域只有 30 万的容量，就会导致无法让所有用户都就近接入；又比如广东有 300 万的 QPS 需求，但由于这是一个大省，省内的资源非常丰富，而我们不需要这么多资源，因为我们通过中心节点实现了服务稳定成型，这时只需要将 20% 用户的流量调度到边缘，就能达到所有用户就近接入的目标。
我们想将所有用户就近接入到边缘节点，但是边缘节点的资源不能满足这么大流量的服务时，就会衍生出资源和流量冲突的问题。
第二个问题是性能与稳定性的冲突。
从性能方面来看，当我们把用户组的调度力度分得很粗的时候，用户的流量都统一调度到某一个大的节点，整个流量的分配拓扑是简单的，但是为了追求极致的性能，我们将用户分得越来越细，调度力度也会越来越细，每一个省份的用户访问同省的边缘节点，这样每个用户访问服务时的性能都很好，但是节点会越来越多，导致运维、容灾难度越来越大。
从流量波动方面来说，现有的针对边缘计算服务放置的研究，主要聚焦在三个方面，第一是面向性能，第二是面向成本，第三是面向质量。但对于流量规模特别大、用户接入设备特别多，用户的设备又是移动的服务来说，会产生一个新的流量迁移，会存在比如说 A 省的边缘节点原来能够按照 60% 的安全水位去服务该地区用户，但春节的时候，B 省的用户大量流入到 A 省，用户变多了，节点容量就不够了，就会导致 A 省的节点流量被打超的风险。
针对以上两个核心问题的解决方案在不断迭代。
前期，为了满足边缘部署的快速接入、项目的快速推进，我们选择了人工的方式，通过文档来规划每一个节点的资源和它需要服务地域的流量之间的关系，但随着节点从几个变成近百个，人工规划就变得不实际了，因此我们选择平台化的方式来处理。
现在，引入了火山引擎 GTM ，帮助完成统一的资源和流量接入的调度，通过它实现了现阶段的流量调度需求的管理。
未来，由于 HTTPDNS 服务拥有大流量规模，实现边缘云原生改造的过程中，涉及到的节点非常多，积累的调度经验也可以沉淀出来，因此未来我们打算做基于强化学习，通过拨测以及真实流量作为训练环境，把经验和在边缘分布式调度上的策略进行积累，以模型的形式提供给客户。
现阶段，我们主要采取智能调度平衡容量、性能、可靠性之间的关系。
细分来看，具体怎么解决流量与资源的冲突问题？之前不能很好地把资源和流量联系起来，主要是因为只能根据地理位置及经验判断用户和节点的距离关系，现在通过智能调度平台，构建起全国几千个边缘计算节点的拨测服务，通过节点之间的互 PING 打造出全国的网络质量地图。有了质量地图以后，我们就能做到边缘节点应用尽用，只要看到机房有资源就去部署服务，按照质量地图把距离最近、预期最好的流量调度过来，依次迭代，最终形成全局综合最优、时延最低的调度方案。
怎么解决性能和稳定性的冲突呢？首先，影响机房稳定性的主要因素是流量会不会打超，我们通过负载实时反馈节点质量和容量感知的方式，上报到调度中心，最终实现基于负载反馈的调度模式，保证机房容量是永远安全的。其次，通过 7 × 24 小时拨测服务，对每个节点进行分钟级的服务状态测试，能够保障在一分钟内发现故障失效，从而实现自动切流，保障服务可靠性。最后，因为 HTTPDNS 是云边共存架构，架构的好处在于突发流量时，可以通过实时状态感知到节点的容量是不是存在风险，从而形成预警，按照策略把突发流量调度到中心机房，以此来应对突发流量。
基于上述能力，我们打造了云边端全链路的流量调度解决方案，涵盖端边调度、边边调度、云边调度。调度的本质究竟是什么，实际上在于流量是什么、能够服务流量的资源是什么以及需求是什么，通过这些输入并结合需求，形成的策略便被称作调度。我们需要明确各种定义，在图中，流量包含终端、网络特征，转发链路包括多种，有加速网络、公网、专网，每一种链路都有质量、成本、性能方面的预期，对服务端来说，不管是边缘服务还是中心服务，最重要的指标就是容量、可用性、地理位置，这决定了它能够服务哪个地域的流量。
通过定制模型，采用云边端全链路流量调度，HTTPDNS 服务在边缘云原生改造获得性能提升的基础上，进一步提升了系统能力，包括新建连成功率提升 1.7% ；晚高峰的总耗时平均值下降了 5.9%；边缘节点因为流量调度导致的流量波动，标准差也从 5% 下降到 1%；由于按照流量特征进行调度，所以每个节点的流量分布更均匀，带来的好处是缓存命中率更高，边缘节点回源量更小。
同时，通过工程实践，不管是软件架构还是系统架构，都发生了比较大的变化。
在软件架构上，从用户侧看，客户端和服务端有自己的 SDK ，为了保障边缘下沉过程中服务的可靠，每个 SDK 都有自动化容灾和兜底机制，以及和中心联动的能力，还拥有通过云侧控制客户端进行多协议选择的方式；从接入侧看，包含中心的四七层负载均衡、数仓监控等套件及边缘套件；从应用服务侧看，将递归层、缓存层分离，打造出独立的云边分布式控制系统，以及采集边缘和中心节点质量和容量的系统。
通过以上架构优化，在控制面，可以在两秒内实现全国范围内的配置同步；在数据面，能够做到一分钟内感知节点容量的风险，并通过云端联动的方式在一分钟内实现流量 95% 的迁移；在业务侧，深度融合边缘云组件，实现业务无损升级。
在系统架构上，整个系统从客户端接入到网络链路、边缘缓冲层、边缘递归层、调度中心层，形成了具备多链路、多服务、多层次的容灾机制，同时，通过工程实践，做到了数据面的任意节点可插拔，进一步提升了系统的自愈能力；还有我们仍在投入的综合调度，通过客户端及每个边缘节点的 SDK 上报节点的质量和容量信息，未来我们会致力于基于用户体验和服务质量的调度。
在这个过程中，我们发现了新的问题，大家可以看图，图上是一个边缘节点接入流量时的流量抖动情况，抖动比较大，这是为什么呢？因为 Local DNS 的调度力度是一个运营商加一个省份，一般来说这种 DNS 体系基于 IP 以及 IP 的权重来控制流量接入，由于节点变多，需要做权重轮转的 IP 越多，流量分布得越离散，所以抖动就变大了。
为了解决这个问题，我们构建出云边端联动的控制模型，使用 Anycast 作为数据面的控制通道，为每一个接入的客户端分配它应该访问的边缘节点 IP 。通过云端调度，首先实现了设备级粒度的控制，机房的抖动粒度也从原来的 5% 下降了 1% 。其次是支持多协议接入，以前客户端接入只能在 DNS 53、HTTPDNS 中选择一个，现在通过联动，可以按照用户所处地域及设备类型，分配最优接入协议。最后是摆脱了对 Anycast 的强依赖，以前如果想保证整个系统不依赖域名，全部使用 IP 访问，就得通过 Anycast，但国内 Anycast 性能不及预期，在新的解决方案里，除了第一跳分配 IP 的过程依赖 Anycast 之外，其他场景完全不依赖，形成了一套轻量 Anycast 接入方案。
接下来总结一下工程实践的相关收益。
在成本上，实现了 35% 的成本优化。左边的图是项目周期内成本单价的曲线，在实验阶段，成本确实有所下降，验证是符合预期的，才开始灰度上线直至最终完成。
在性能上，实现了 20% 性能提升。右边的图是通过 920 多个拨测节点，对比原来的中心架构、只使用边缘部署的架构，以及既使用智能调度又使用边缘部署的混合架构，三种架构的 AB 实验的测试数据，其中黄橘色，也就是混合架构的数据性能最好，比原架构领先了大概 20% ，目前性能处于国内 TOP 梯队。
应用边缘计算性能变好，是因为离用户更近了，那成本为什么能优化呢？主要看服务的成本构成。首先，HTTPDNS 作为网络 IO 型服务，带宽的成本占比很高，其次，因为 HTTPDNS 是缓存型服务，对四七层资源及计算资源内存的消耗都是很高的。
对比中心和边缘，在网络带宽上，中心一般使用 BGP 带宽，边缘一般使用某地运营商的单线带宽，二者价格相差接近 5 倍；在四七层负载均衡上，理论上中心和边缘的计算资源价格一致，我们能优化成本是因为通过调度把一个地域的流量分配到一个地方节点，不像以前，一个中心机房承载了全国各地域的流量，会导致中心机房的流量模型特别复杂，每个节点的缓存数量特别多，进而导致每单核 CPU 的性能下降，通过把缓存做类似哈希桶的切割以后，性能自然就提升了，最终计算资源也节约了差不多 0.5 倍。
除了前述提到的性能提升 ，我们在别的性能方面也实现了进一步提升，比如平均时延下降 5% ，首包建链平均时延下降 4.1% ，通过使用智能调度的模式进行故障运维和风险处置，自动容灾率达到 100% ，保障全流程是完全平稳的，以至于业务侧对于我们进行了这么大的项目毫无感知，只是感知到成本变低了，性能变好了。
除了服务上的切实收益，在工程角度我们也通过实践获得了一些思考结论。前期做可行性调研的时候，我们同时在思考对于边缘云原生改造之后的服务，系统的核心评价指标是什么，以及整个工程实践会涉及的技术方案有哪些？基于 AHP 层次分析法，我们做了一次建模，在内部通过问卷调查、多次讨论，最终确定了以下几项：
首先是优先级。整个改造过程中，第一优先级是稳定性，第二优先级是成本，第三优先级是性能，因为性能天然就有保障，但是稳定性可能会丢失，成本不一定，具体取决于边缘的用法。
其次是方案排序。在边缘部署的方案设计、流量接入调度的设计以及需不需要做深度的边缘云原生改造的讨论上，我们确定了优先进行部署，在部署的基础上才能进一步实现流量调度。
展望未来，产品还将持续迭代，有以下 3 个演进方向：
首先是安全 DNS ，保障全链路的安全解析，可以为用户提供免费、高性能、安全的公共 DNS 服务；
其次是进一步实现边缘接入精细调度，深度打磨云边端全链路调度系统。实现设备级的精细接入控制，把机房流量误差控制到 1% ，以及通过云端联动实现预警式故障流量主动迁移；
最后是海外递归服务下沉。海外的 Anycast 性能相对较好，但海外用户比较喜欢用公共 DNS ，8.8.8.8 在全球的流量占比大概是 40% ，未来希望在海外通过边缘下沉的方式解决 Anycast 在南美洲、中亚地区等覆盖不足的问题，进一步提升产品服务能力和用户体验。