腾讯广告上云：架构设计与优化方案全解析_架构_云加社区



 写点什么

导语 | “云上生长，降本增效”是 2020 年腾讯 AMS (广告营销服务线)上云的主题，希望通过对腾讯云新技术的应用，及自研上云重构部署的机会，实现成本大幅下降，性能提升的双重目标。通过上半年实践，在腾讯云团队及运营管理部的支持下，整体效果超出预期。本文将讲述期间遇到过的困难及优化历程，希望与大家一同交流。文章作者：凌飞，腾讯运维开发工程师。

一、业务架构

本阶段上云的主要链路为上图中红框部分，这条链路为广告播放链路，是整个广告业务中最核心，也是性能要求最高的链路，有以下特点：

1. 请求量大

日均请求量近千亿级别，机器量占了 AMS 自有机器量的绝大部分，整体性能即使是 1% 的上下波动都会涉及几百台机器的变动。

2. 链路拓扑复杂及性能压力极大

整个播放链路涉及 40+ 的细分模块。在 100~200 毫秒（不同流量要求有差异）的极短时间内，需要访问所有模块，计算出一个最好的广告。

3. 数据量大

大量的广告数据及回流训练数据在整个网络中流转，对带宽及存储带来了极大的压力。

二、上云方案选型

当前上云的主流路线主要是 CVM 或 TKE，在考虑 AMS 的上云路线时，我们主要考虑了以下两点:

第一：本次 AMS 上云的核心模块，物理机机型 90% 均为 80 core 以上机型，上云后单机必须在 80 core 以上，已经将一台 CVM 所有 core 都使用完，再从资源管理角度考虑 TKE ，基本没有收益了。

第二： AMS 当前的 CI/CD 流程及业务运营系统无法完全对接 TKE 平台，强行切换的成本/风险与预期的收益无法对等。

基于以上考虑，AMS 的上云策略为前期 CVM 为主，TKE 为辅，继续完善 TKE 管理系统的流程对接。

上云三大阶段

（1）基础设施上云

大量使用云服务器，此阶段最主要的是把自研 IDC 的流量上云，同时试用云数据库，云负载均衡等各种 PaaS 服务。


业务规划	灰度方案	环境适配	流量迁移	监控告警
容量规划	回滚方案	功能测试	流量验证	持续运营
组件规划	风险评估	性能测试	灰度验证
机房规划	放量方案	压力测试	放量迁移
预算规划

（2）架构升级，大量使用 PaaS 服务

弹性伸缩、Docker 化改造，大量使用各种 PaaS 服务，充分发挥云的高级功能。

（3）基于云生态的研发运维体系

建设基于云生态的研发运维体系，全面拥抱云生态。

三、优化历程

虽然名为优化历程，但更多是 AMS 技术团队与腾讯云团队相互磨合，共同进步的历程。提到的一些坑或者优化点，后面上云的同学可能再也不会碰到了，因为大多数已经通过产品化的方式固化在腾讯云服务中。这也算是腾讯推动“开源协同，自研上云”目的之一。

1. 基础环境适配

2. CVM 性能调优

（1）广告播放性能要求

接入方式多种多样，流量方众多，耗时要求各不相同，耗时容忍度不同
每种流量访问的下游数量不同导致耗时不同，每个都影响最终的耗时，耗时增加直接影响收入
各流量之间请求相差悬殊，超时比例即使相同但绝对值不同

（2）如何评估 CVM 与物理机的性能差异？

采用 percentile 百分位统计：

将一组数据从小到大排序，并计算相应的累计百分位，则某一百分位所对应数据的值就称为这一百分位的百分位数。可表示为：一组 n 个观测值按数值大小排列。如，处于 p% 位置的值称第 p 百分位数。

相对于平均值统计，百分位统计区间更大，反应更灵敏，可以更好更及时反应业务质量的变化。

（3）优化目标

（4）主要耗时表现

耗时：云主机在广告检索模块上 99p 耗时比物理机 CG1 高 8-10ms。

	平台	配置
CG1	intel	2个20核CPU(6133)，256G内存，6480G SSD，RAID，210G网口
云主机	Intel	80或者76逻辑核，256G内存，硬盘为CBS，网卡限速为万兆

（5）云主机 ping 抖动

现象：使用 CVM 时发现 99p 时延抖动严重，定位发现是云主机之间存在 ping 抖动问题。

排查过程：

第一步：查看 ping 抖动是否由网络造成？

采用同一个 VPC 的 CVM，排除网络影响。 ping 的同时进行 tcpdump 抓包，确认网络 ping 抖动来源于母机或者 CVM。

第二步：母机查看各种指标，暂时未发现异常。

第三步：查看子机相关指标，OS、CPU、网卡流量，以及查看/proc/interrupts，最终发现是 tlinux1.2 OS 自带的 ethtool 工具版本太老，设置网卡多队列失败。

第四步：升级 OS 后在大流量时故障复现，经过查看母机和子机 CPU 占用率，怀疑子机 vCPU 和母机线程争抢 CPU 导致。

采取措施：

第一步：升级 ethtool 工具或者升级 OS 为 tkernel2 内核、腾讯云部署 QOS 组件。

第二步：使用 DPDK（数据平面开发套件），母机隔离出 4 个逻辑核专门用于包转发。

如何更新存量？
如何保证增量正常？
如何规范腾讯云上架流程？

（6）CPU 抖动引起雪崩

现象：经过 DPDK 优化的机型在某模块上使用时在晚高峰不定时发生 CPU 抖动，失败引发 L5 调度，进而引起该模块云主机雪崩。

定位过程：

发生 CPU 高时，使用率超过 50%。

经过分析，发现 CVM 中的 CPU 和母机 CPU 并不是一一对应，在子机中的 CPU 使用率比较高时，由于母机侧的自动负载均衡，会导致 CPU 跨核调度，发生 cache missing，由于没有透传 L3 cache，也使得不能使用 L3 cache，导致频繁的上下文切换。

（7） AMD CPU 性能优化

AMD 使用表现如下：

同压力时对比 intel 云主机， AMD 物理机耗时抖动严重，无法应用于线上，转而使用 AMD CVM（CVM 配置：90 逻辑 core，独占一 socket）。

定位与分析：

AMD 处理器单路 48 个物理核，双路总计 192 个逻辑核（线程），两个 NUMA 节点。NUMA 非一致内存访问，经过分析广告检索模块的内存占用，结合 NUMA 的内存访问统计，数据主要都位于 node 1 (N1) 上。而 sunfish 有一半的检索线程运行在 node 0 的 core 上，对这部分线程 node1 的内存属于远端内存，因此访存速度缓慢。

收益：

采用单 node 的 AMD 云主机经过测试耗时比 CG1 低 25% 以上，而成本经过测算 AMD 单机成本是 intel CG1 的 60%，经过此次验证也说明了硬件架构贴近业务架构特征所带来的收益，来加速 AMD 的落地。

3. 上云对现网影响如何做到可控

（1）离线试错

在不影响线上系统运行的前提下，克隆真实的在线请求到离线环境实现线下试错，降低系统风险，无用户体验影响，快速支持新版本新环境上线。

（2）灰度方案设计

广点通模块众多，不可能全部同时上云，为了服务切换的平滑稳定，做到用户无感知，主要考虑到云环境初期的各种风险，包括专线质量、服务延时、机型适配等诸多方面。

既要上云，也不能无谓踩坑。既要保证业务平稳运行，维持高可用性，云上环境有问题，可以随时禁用，全部切回自研环境。

机器维度：

云主机适配物理机配置，压测后上线，如有异常及时剔除。

模块维度：

针对 AMS 耗时要求严苛的情况，确定哪些模块先上，哪些模块后上，逐步上线各模块。

SET 维度：

一个 SET 具有完整的请求处理路径，包含接入层+逻辑层，各个 SET 对请求的耗时要求不同，确定哪些 SET 先上云，做到按 SET 回滚。

4. CBS 存储优化

CBS 的可用性主要通过网络块存储方式提供服务，分布式三副本提供保障。而 AMS 上云模块的数据应用模式采用大量的数据频繁地实时更新。

网络服务+三副本是在机制层面提高了可用性，可以减少我们很多运维的工作。但是新技术应用在一套磨合成熟的架构里面，肯定会引出新的问题，我们不应该抗拒新技术，有问题解决问题。下文主要讲一下新的问题及互相妥协的过程。

带宽，通过网络提供服务，大量数据的实时更新就意味着产生极大的网络流量，那网络带宽有可能代替磁盘 IO 成为了文件读写的瓶颈。

成本，频繁的数据更新，意味着数据是类似 cache 性质的，那么对于数据可用性的要求其实并不需要到达三副本的级别。

（1）带宽问题

核心矛盾主要在带宽指标上。业务侧诉求是带宽越大越好，物理机的写入速度可以达到 300MB/s，而文件传输工具的峰值速度一般是 200MB/s（1.6Gb/s）。CBS 的诉求是小带宽，默认带宽是 100MB/s。由于双方诉求相差过大，最终上线时是使用了个折中的速度 180MB/s。

物理机网络传输带宽情况

CBS 侧操作：

由于高性能云硬盘的上限带宽达不到 180MB/s，最终使用了 SSD 云硬盘（上限 260MB/s）。然后再通过云盘打标签（APPID+硬盘空间大小）的方式来配置带宽限速 180MB/s。

业务侧操作：

带宽=数据大小/传输时间。带宽已经被限定，传输时间决定了数据加载速度，业务的需求是越小越好，为了减少对业务的影响，能优化的主要方向就是数据大小。主要是通过了以下三个方式来减少云盘的写入量。

第一：每次传输的数据文件从全量文件修改为增量文件，减少单次传输的数据大小，将传输时间打平。

第二：中间文件直接在内存操作，传输过来的文件会有一个解压的中间状态，这个操作放在 /dev/shm 目录下操作，减少云盘的写入量。在使用大内存机型的条件下，这个操作可以减少几十 G 文件读写压力。

数据写内存后，IO 变化情况

第三：减少灾备数据的传输，双数据源增加主备标识，备机判断主机存活的情况下不做数据发布的操作。由于原来双数据源是无状态互为容灾的架构，增加主备标识后，效果是数据写入量直接减半，代价是故障时，数据更新会延迟一次文件传输的时间。

通过以上三招，将平均写 I/O 从 100+MB/s 降到 30MB/s，每 30 分钟文件写量从 120GB 降到 50GB 左右。

磁盘 IO 优化前后对比

（2）成本问题

我们上云的模块基本都是接入层和逻辑层，机器上的数据也基本都是无状态的 cache 性质数据。这种类型的数据更多是要求性能，而对可用性的要求做到 raid5 级别就可以了，三副本的存储成本太高了。但三副本是 CBS 的核心机制，这里可操作的空间不是很大，期间我们也是考虑过一些别的方案，最终也没有实现。

CFS 方案：

我们的数据的读写模式本质是一写几千读，CFS 在理论上也能支持，而且更合适。但是经过成本测算，CFS 的成本会比 SSD 云盘成本更高，而且 CFS 的自研业务需求较少，不利于通过运营手段分摊并减少成本，最终该方案未实施。

单副本方案：

CBS 的同学也在考虑单副本的方案，由于最终方案尚未确定下来，不过多讨论。主要列举一下，我们业务对于单副本方案的需求或者关注点。

系统盘与数据盘分离；
故障率做到与物理盘坏盘率相同水平；
底层物理故障不应该影响大量 CVM；
可以接受停机维护，但是如果因为全盘目录损坏导致需要重装系统，以重新构建一些系统级目录，运维成本过高，则意义不大。

综合以上，由于 CBS 的高可用性保障及可根据业务形态调整配置的特性，业务侧对 CBS 还是非常认可的。在运维效率提升及成本优化的过程中，起到了非常大的帮助。

5. 网络时延优化

问题：云主机至自研 IDC ping 时延过高。

广州到深圳 5ms；
上海宝信云到自研 IDC 4-5ms。

主要措施：

部署 pvgw 设备；
直通车网络优化项目。

6. TKE 服务建设

由于 CVM 对于小核心业务提供能力不足，经常出现亲和度不够导致同业务下多个小核心 CVM 来自于同一台宿主机，增大了业务风险和容灾能力不足。所以开始接入公司的 TKE 服务，但由于 TKE 公有云没有和腾讯内部的很多自研系统（监控运维）及账号打通，所以对大多自研上云业务并非最好选择。

（1）平台选择

接触了公司已有的两款 TKE 平台：STKE 和 TKEstack。

两个平台的相似点在于，都是以 TKE 为基础来提供容器化服务的方案。但差异在于 STKE 是专为公司自研上云提供的 TKE 服务，打通了更多的公司内部服务。

TKEstack 更多的则是面向私有化场景，但加入了适用于大数据计算的场景，并且和服务类型的应用混合部署。而在广告内部存在着大量的离线模型计算，TKEstack 的场景更贴近广告业务。

（2）TKEstack 优势

支持丰富的网络模式，大幅拓展了容器应用场景，满足复杂应用容器化的特殊需求；
提供全维度弹性资源限制，使得容器的稳定性、集群资源利用率均得到提升；
实现了 GPU 卡、GPU 显存的虚拟化功能，可有效提升用户 GPU 资源使用效率；
结合腾讯十多年海量运营经验，全新设计出的一种全新的易用的应用类型；
自带 P2P 分发功能的镜像仓库，可防止镜像服务网卡流量被占满，并可显著提升了拉取镜像的速度。

在运维侧，则实现了小核服务的按需分配（低负载管理）和快速扩容（自动扩容）等功能，在业务质量和成本管理中都有着显著的提升。

（3）镜像管理

镜像可兼容 CSIGHUB，gaiastack 仓库，蓝盾和 mirrors 平台，现基础镜像都以 mirrors 平台管理为主，已实现 AMS 广告公共基础镜像的仓库服务提供，已完成广告自有基础镜像搭建并已提交至业务侧使用。并已完成私有仓库与平台之间的凭证互通，可实现平台拉取私有镜像。

（4）容器化 CI/CD

容器化的持续化集成区别于普通 IDC 业务的持续化集成，因为容器化还增加一步镜像构建的动作，这块现有方案为 csighub 的 hook 功能和蓝盾的流水线功能，可以检测某个 git 仓库的地址，一旦发生 commit 动作就会触发自动构建。

自动构建的镜像为运维侧提供的基础镜像或者增加了业务基础环境的业务镜像（如 PHP、jdk 等）

容器化的持续化部署也与普通 IDC 业务有所不同，普通 IDC 业务是根据一个下发管道，来把代码包下发到业务机器上，然后进行迭代后重启（如织云）。但容器化的 CD 是把原先提供服务的 pod 进行销毁，再根据上述自动构建的镜像进行重启拉起，这样就实现了一次自动化部署。

四、容错容灾部署

由于播放链路的机器是多年来逐渐部署起来的，有着比较重的历史包袱。而早年间，整体链路的耗时压力并没有现在这么严峻，所以在条带化的部署架构设计时，只考虑了按业务流量性质的条带化部署，各个模块的机器部署在不同的 IDC 中。

随着多年的发展，功能模块越来越多，请求数据包大小逐渐增大（包大小增加 60KB，同城跨 IDC 耗时就会增加 1ms 左右）。

再看业务架构中的特点二、链路模块多+整体耗时控制严格。这导致整体链路中跨 IDC 访问耗时占比比较高，占比在 10% 以上。所以这次自研上云是一个很好的契机，重构业务部署架构，在保证可用性的前提下，尽可能通过就近部署减少网络访问耗时。

1. 部署原则

为了达到这个目标，在进行新的 Set 划分时主要是按照以下几个原则：

每个地域选择两个容灾 IDC 。
接入层混布，使用相同 L5/STGW，通过权重控制物理机与 CVM 间的流量对比，物理机后面接物理逻辑 Set，CVM 后面接云 Set 。这样流量在物理及云之间切换时，对流量侧就是无感知的。
逻辑层按 IDC 就近部署，这个会导致机器部署的碎片程度增加，管理单元数量大幅上涨，所以相应内部 Set 管理系统也得进行更新迭代。
数据在物理及云各部署一套，由于部署一套在线数据的成本非常高，只能物理及云各部署一套，无法做跨城容灾部署主要也是受限于这里。