ADmobile 首席架构师王威：广告业务云上运维最佳实践

12 月 21 日，在阿里云弹性计算年度峰会上，ADmobile 首席架构师王威发表了《ADmobile 广告业务云上弹性计算最佳实践》的演讲，介绍了 ADmobile 业务云上最佳实践。

【图：ADmobile 首席架构师王威】

本文主要根据王威的演讲整理而成，内容分为四部分：

1. 业务背景介绍；

2. 业务发展中的技术痛点；

3. 解决方案；

4. 实践经验。

01 ADmobile（艾狄墨搏）业务背景介绍

ADmobile 是一家程序化的广告聚合 SaaS 服务商，通过自主研发的广告聚合管理系统，整合流量管理、UR 工具，为 APP 广告变现提升收益。通过一站式广告聚合平台，ADmobile 提供专业多维度的数据报表，还有聚合管理、灵活的运营方式和多样灵活的优化工具。

上图可以看到，ADmobile 业务发展中服务资源的变化：从最早期就是一台服务器、一个数据库支撑我们业务发展，到现在有 200 台以上的服务器，还有数据库、中间件、负载均衡等一系列云资源。业务高峰的时候，ECS 数量一度达到 400 台，甚至曾经超过 500 台；业务高速发展的同时，流量也在激增，对于技术和运维都是一种极大的挑战。

02  ADmobile 业务发展中的三大技术痛点

在早期的方案当中，对于流量峰值的变化，基本无法灵活应对，只能通过部署服务器去应对流量波动。一些特殊的日子，例如 618、双 11 的大促期间，流量会出现爆发式增长，这需要技术人员提前准备足量的服务器，应对流量的激增，保证我们业务能够平稳运行。

早期部署方式也比较传统，即在一台指定的服务器上，把我们的项目运营好，制定一些相应的启动脚本来生成 ECS 镜像，通过批量的创建 ECS 来保证服务正常运行。

早期的技术架构看上去很简单，总共只有 3 个服务，这是我们在线运营的业务。通过负载均衡进入服务 A，通过服务发现调用 B 和 C，整体三个服务支撑了我们现在的一大块业务。这个技术架构中，所有的服务器都是固定的，所以无法根据流量变化去实时动态调节服务器资源，因此造成了服务器资源很大的冗余和浪费。

服务资源冗余、突发大流量的应对困难、镜像生成非常耗时（基本上需要数十分钟甚至小时级别），这三个技术痛点导致很难应对业务实时的变化发布。

03 我们的解决方案

当前，ADmobile 选择了增加了弹性服务器组，发布方式上采用了 ECS 自动同步最新服务，并采用了 Jenkins+K8s 的一键部署。在一台服务器上把服务部署好，其他的服务器会定时同步最新的服务，并重新启动服务，这样避免了重新生成 ECS 镜像，可以实现更加灵活的发布。

上图是我们技术架构中的一个，相比早期的架构可以明显地看到多了一个弹性伸缩组。弹性伸缩组的存在，既避免了服务器资源很大的冗余和浪费，又能更好地应对一些大量流量的突增业务。在弹性伸缩组里面还可以通过部署一部分抢占式实例，来进一步降低服务器成本。

这是另一个业务架构，它是基于 K8s 搭建的，现在比较流行通用的架构，分为数据层、服务层、网关层和展示层。

1. 数据层，可能包括数据库 MySQL、缓存 Redis、对象存储 OSS 等。

2. 服务层，以 K8s 为核心，包括我们自己搭建的 Kubernetes，只有在进行发布的时候才会占用一些资源，不发布的时候基本上不占用资源。

3. 网关层，主要是通过负载均衡对外提供服务，目前在尝试将服务网格应用到业务中，还处于测试阶段，接下来如果测试稳定，可能就会把负载均衡全部切到服务网格上。

4. 展示层，包括 PC 端、移动端、小程序等。在这种架构中间，还使用了阿里云的平台服务，像注册中心、日志记录等服务穿插在整个业务的所有过程中。

以下介绍我们在实际工作中遇到的常见问题及解决方案。

1、如何应对流量激增

这是很多业务运行过程中都会碰到的问题，流量激增可以分为两类：一类是可预测的流量，例如，早高峰或者晚高峰由于用户量的增加导致流量激增，这种可预测的流量激增，可以定时的扩容的策略来保证业务运行；另一类是不可预测的流量，一般可以通过 API 或者 SDK 方式自定义监控指标，借用阿里云的接口提前进行扩容，即根据指标的波动、变化进行相应的扩容或者缩容。实现方式是根据自己的业务结合阿里云的 SDK 、API 相应的脚本进行编写。

2、如何选择监控指标

伸缩容过程中的一些监控指标，例如平均负载、CPU 使用率、内存使用率、网络流量、磁盘 IO 等，可以根据不同的应用类型来选择不同的监控指标。以 JAVA 应用为例，它是比较占用内存的，当内存占比到 70%-80%，它的 CPU 占用可能还很小；如果我们监控它的 CPU 使用率，尽管 CPU 占用处于正常范围，而内存可能已经用到 90%或者更高，这种监控指标的选择是不太恰当的，我们应该根据不同的应用灵活地选择监控指标。

3、如何选择扩容和缩容的指标值

这个主要是指阿里云弹性伸缩组的扩容和缩容的指标值。根据我们的实践，不建议设置相等值，例如，当 CPU 使用率大于 50%的时候进行扩容，CPU 使用率小于 50%的时候进行缩容。这是因为扩容或者缩容都有冷却时间，如果 CPU 的使用率就在 50%左右上下波动，可能最终导致我们的扩容或者缩容的目的无法实现。

04  四大实践经验总结

我们总结的实践经验有 4 点：

第一，不要把所有的 ECS 都交给弹性伸缩组来控制。因为弹性伸缩组是比较灵活的，如果我们设置的指标不太严格，可能导致 ECS 出现无序的扩容，或者出现 ECS 数量变成零等异常情况，从而对业务造成影响。

第二，弹性伸缩组里面设置合适的实例上限。这个和第一个类似，如果不设置上限或者上限值设置的不合理，可能会导致无序扩容，应用异常或者监控指标持续上升，最终导致服务器数量异常，对成本带来负担。

第三，部署适当比例的抢占式实例。抢占式实例的折扣在活动中可能低到 1 折，如果业务结构合适，通过分配一定比例的抢占式实例，可以有效地降低成本。

第四，善用云上运维自动化服务。阿里云提供了很多好用的工具，例如使用 ECS 云助手，可以对服务器进行批量的漏洞修复或者软件升级。

最后，分享一个弹性伸缩组的案例。在上图中，最高峰的时候，ECS 数量应该有 45 台，最低的时候有 10 台，并且最低 10 台的时候我们做了一定的冗余处理。如果放开限制，ECS 数量会变得更少，通过这样的部署方案，经过测算，成本总共降低了约 30%。

点击大会官网，观看王威的精彩演讲视频。