更快、更稳、更优,揭秘火山引擎全站加速 DCDN 规模容器化最佳实践

在数字化转型的浪潮与5G技术快速进步的推动下,短视频、电子商务、在线支付等业务迅速增长,带来了对全站加速服务需求的显著上升。为了更好地服务用户、提高体验,传统的全站加速服务正遭遇资源分配、运维效率、稳定性和成本控制等多方面的挑战。随着边缘计算的迅速发展,凭借其弹性可伸缩、自动化交付、安全性与稳定性等创新特性,为解决这些问题提供了新的途径。因此,火山引擎边缘云技术团队利用边缘计算的云原生技术优势,将全站加速 DCDN 业务转移到边缘计算平台,推动了全站加速 DCDN 服务的一次重大创新升级。

经过一年的改造迁移,火山引擎全站加速 DCDN目前已将 90% 的流量转移到边缘计算容器平台。面对发展中的挑战,全站加速 DCDN 不仅积极应对,还在持续加强容器平台的调度效率、算力、存储和网络等关键能力,确保为抖音集团内部和各行业客户业务提供稳定、高效且极具性价比的加速服务。

本文将基于全站加速 DCDN 与边缘计算的关系以及容器化过程中面临的挑战,分享火山引擎全站加速 DCDN 在边缘计算容器平台规模化落地的实践。

1.全站加速 DCDN 和边缘计算

火山引擎全站加速 DCDN 提供 http/https 动态及动静态混合内容的加速服务,利用丰富的网络资源,结合自研的传输优化、智能缓存、动态路由、安全防护等能力,为用户提供安全、稳定的一站式加速服务,提升用户访问体验。通过抖音集团业务和规模化 ToB 业务的打磨,火山引擎全站加速 DCDN 已形成了一套完善且具备规模商业化能力的系统,并在全球具备 2500+ 节点,可以提供亿级 QPS 的全网并发能力。

边缘计算是分布式计算架构,在靠近用户终端的地方部署基础设施资源,将算力、网络、存储等下沉到边缘,提供低时延、高带宽的服务能力。全站加速 DCDN 节点天然具备全球多节点的分布式特性,且部署在边缘,更靠近用户,因此利用边缘计算的资源,包括网络、算力和存储,来增强全站加速 DCDN 服务,已经成为一种必然的发展趋势。

2.全站加速DCDN 为什么选择容器

边缘计算提供裸金属,虚拟机和容器三种不同的计算资源。火山引擎全站加速 DCDN 对三种计算资源进行了对比。

容器具备的资源轻量级、弹性扩缩容、部署高效等特点更符合业务需求,也可以更好的提升资源利用率,最终全站加速 DCDN 选用容器作为计算资源来进行业务迁移。

全站加速 DCDN 容器化可以解决传统 DCDN 存在的资源、业务、稳定性、成本方面的问题:

  • 异构管理:通过容器化可以解决不同机型、不同资源类型带来的异构管理问题

  • 活动突发:活动突发资源扩容周期长、效率低,通过容器化弹性伸缩解决活动带来的突发资源问题

  • 业务稳定:混部资源抢占,故障域耦合时,可以通过容器做业务拆分,实现资源和调度域隔离

  • 成本优化: 通过小规格容器化,可以提升资源的售卖率和碎片化资源的利用率

除此之外,全站加速 DCDN 容器化能对容器的平台、计算、存储、网络等能力进行全方位的打磨优化,同时可以将全站加速 DCDN 节点上多余的算力、带宽、存储等资源释放出来进行售卖,提升资源利用率,对业务来说实现了双赢。

3.技术挑战和解决方案

全站加速 DCDN 现网改造需要容器兼容现有的平台架构,满足全站加速 DCDN 侧的需求,包括:

  • 通过 Kata+富容器,来实现 systemd 管理、ssh 登陆,同时具备安全隔离、协议栈优化能力;

  • 通过 Ceph 和 Spdk ,让存储支持本地盘/云盘能力;

  • 通过虚拟网卡,支持独立 PIP,具备出公网能力;

  • 通过 LB4 EIP 透传能力,使全站加速 DCDN 具备 LB4 多 EIP 服务能力等。

此外,全站加速 DCDN 容器化过程中还存在很多技术挑战。面对这些挑战,团队不断进行探讨,针对性地提出解决方案。

3.1通过富容器+ kata ,实现独立协议栈隔离

传统容器作为独立的运行环境,缺少 systemd 进行容器内部的进程管理,原有的业务运维体系依赖 crond、sshd 等服务。全站加速 DCDN 侧需要有独立的协议栈来进行协议栈传输优化,同时需要安全隔离的环境。为解决这一挑战,最终团队决定采用富容器+ kata 的方案,实现独立协议栈隔离、减少对运维体系的侵入,保持原有的运维体系。

3.2 EIP 直通模式兼容 LB 转发模式,解决流冲突问题

全站加速 DCDN 接入调度的负载均衡主要由 DNS 负载均衡实现,这种情况下每个节点会存在多个 EIP 来做接入,公有云的 LB 在不侵入用户主机的情况下,会通过 overlay 封装来进行转发,但在某些特殊的场景下,同 CLIENT:CPORT 可能会和不同的 EIP:EPORT 通信,如果转发到后端遇到相同的 RIP:RPORT 就会出现流冲突的问题。为解决这一挑战,最终团队决定通过 EIP 直通的模式兼容原有全站加速 DCDN 的 LB 转发模式,LB 和后端通信的时候,DSTIP 直接使用 EIP 而非 RSIP,同时在 RS 上监听 EIP,这样就解决了流冲突的问题。

3.3调度亲和性,解决 CPU 负载不均问题

在同集群发现不同机型服务器 CPU 表现不一样,这会带来负载不均的问题。为解决这一挑战,团队决定通过调度亲和性,保证同集群内调度的 node 机型保持一致,解决机型代差导致的 CPU 不均。容器 CPU 之前是使用 defaultCpuSet 中的核,以来时间片调度,会造成和其他控制面组件的争抢,所以容器 CPU 需要单独设置 CPU 核,同时 vcpu 和物理 cpu 做绑定,避免其他业务的影响。

3.4三大举措提升稳定性

全站加速 DCDN 容器化过程中,通过以下方式来保障业务稳定性。

  • 故障迁移和熔断: 支持集群内宿主机故障时 pod 自动迁移,同时为防止大规模删除容器,需要具备中心熔断机制,容器平台通过引入"风控策略",可以保证一定时间范围不允许删除超过一定节点的 Pod,从而避免大规模故障发生,同时在边缘 k8s 异常或者通信失败的时候,边缘集群内具备边缘自治能力,保证现有业务稳定运行。
  • 故障恢复: 如果熔断异常,出现大规模删除容器,那就需要具备快速恢复的能力,容器实例通过建立快照能力,并且通过快速恢复工具,可以在真实发生大规模删除 Pod 时,实现对全网删除 Pod 的快速恢复。
  • 调度联动: 结合全站加速 DCDN 侧质量探测结果,全站加速DCDN 调度系统会自动感知节点健康状态,异常情况下会自动将节点主动摘除。

4.全站加速 DCDN 规模容器化实践效果

全站加速 DCDN 容器化改造过程持续了一年,目前全站加速 DCDN 90% 以上的流量已经在容器平台上平稳运行。全站加速 DCDN 容器化为业务带来了直观收益:

  • 提升资源配置效率:容器的弹性调度能力有效应对了春节活动、双 11 和双 12 等特殊时期带来的突发资源问题,显著提升了资源配置的效率,将从前以月为单位的资源筹备时间缩短至一周以内。
  • 规避系统性风险:通过全站加速 DCDN 容器化,隔离了故障域,规避了一次大规模系统性风险以及减少了 90% 的资源争抢问题。
  • 提升上线效率: 容器化部署后,通过镜像打包,节点的上线效率提升了 80% 以上。
  • 提升资源售卖率: 通过小规格容器提升碎片化资源利用率,边缘资源售卖率提升 11%。

5.未来展望

全站加速 DCDN 容器化帮助解决了很多传统 DCDN 存在的痛点问题,也取得了相应的收益,下一步火山引擎全站加速 DCDN 团队将继续协同边缘计算,在以下方面进行更深的合作:

  • 边缘统一调度: 通过统一调度,对算力,存储,以及带宽统一分配,实时感知全站加速 DCDN 算力和带宽使用情况,做到算力弹性流动调度,提升资源使用率。
  • 安全防护: 依托边缘大规模分布式资源,提升 WAF ,抗 DDoS 攻击能力,通过流量检测、流量清洗及黑洞等手动方式,远源拦截,保障源站稳定性。
  • 算力卸载: 通过智能网卡,ssl 卸载等能力,卸载算力,提升算力综合处理能力。
  • 全球网络互联: 通过全球网络互联,云边专用网络,提升内部管理通道,数据回传稳定性,提升内部网络加速性能。

END

采纳边缘云原生技术将为全站加速 DCDN 带来显著的竞争优势,在构建一个高效、稳定、可靠且具备良好可扩展性的现代化加速网络过程中,边缘云原生与全站加速 DCDN 的联合应用将发挥越来越关键的作用。面向未来,边缘云原生与全站加速 DCDN 会不断进行深度融合,将为网络技术的发展带来更多可能性,并推动行业达成新成就。

相关推荐
钱彬 (Qian Bin)33 分钟前
国内docker pull拉取镜像的解决方法
运维·docker·容器·国内镜像源
志凌海纳SmartX5 小时前
概念解读|K8s/容器云/裸金属/云原生...这些都有什么区别?
云原生·容器·kubernetes·虚拟化
xnuscd6 小时前
k8s入门学习
学习·容器·kubernetes
大熊程序猿6 小时前
docker busybox作为initContainers
java·docker·容器
kitsch0x977 小时前
工具学习_Docker
学习·docker·容器
掉头发的王富贵8 小时前
Docker入门之Windows安装Docker初体验
windows·docker·容器
第九系艾文8 小时前
docker构建多平台容器
运维·docker·容器·多平台构建
嘟嘟Listing8 小时前
docker minio修改时区问题记录
运维·docker·容器
lkflxy10 小时前
k8s上面的Redis集群链接不上master的解决办法
redis·容器·kubernetes