》的演讲，介绍了ADmobile业务云上最佳实践。
【图：ADmobile首席架构师王威】
本文主要根据王威的演讲整理而成，内容分为四部分：
- 业务背景介绍；
- 业务发展中的技术痛点；
- 解决方案；
-
实践经验。
ADmobile是一家程序化的广告聚合SaaS服务商，通过自主研发的广告聚合管理系统，整合流量管理、UR工具，为APP广告变现提升收益。通过一站式广告聚合平台，ADmobile提供专业多维度的数据报表，还有聚合管理、灵活的运营方式和多样灵活的优化工具。
上图可以看到，ADmobile业务发展中服务资源的变化：从最早期就是一台服务器、一个数据库支撑我们业务发展，到现在有200台以上的服务器，还有数据库、中间件、负载均衡等一系列云资源。业务高峰的时候，ECS数量一度达到400台，甚至曾经超过500台；业务高速发展的同时，流量也在激增，对于技术和运维都是一种极大的挑战。
02 ADmobile业务发展中的三大技术痛点
。一些特殊的日子，例如618、双11的大促期间，流量会出现爆发式增长，这需要技术人员提前准备足量的服务器，应对流量的激增，保证我们业务能够平稳运行。
早期部署方式也比较传统，即在一台指定的服务器上，把我们的项目运营好，制定一些相应的启动脚本来生成ECS镜像，通过批量的创建ECS来保证服务正常运行。
。
（基本上需要数十分钟甚至小时级别），这三个技术痛点导致很难应对业务实时的变化发布。
。在一台服务器上把服务部署好，其他的服务器会定时同步最新的服务，并重新启动服务，这样避免了重新生成ECS镜像，可以实现更加灵活的发布。
。在弹性伸缩组里面还可以通过部署一部分抢占式实例，来进一步降低服务器成本。
这是另一个业务架构，它是基于K8s搭建的，现在比较流行通用的架构，分为数据层、服务层、网关层和展示层。
1. 数据层，可能包括数据库MySQL、缓存Redis、对象存储OSS等。
2. 服务层，以K8s为核心，包括我们自己搭建的Kubernetes，只有在进行发布的时候才会占用一些资源，不发布的时候基本上不占用资源。
3. 网关层，主要是通过负载均衡对外提供服务，目前在尝试将服务网格应用到业务中，还处于测试阶段，接下来如果测试稳定，可能就会把负载均衡全部切到服务网格上。
4. 展示层，包括PC端、移动端、小程序等。在这种架构中间，还使用了阿里云的平台服务，像注册中心、日志记录等服务穿插在整个业务的所有过程中。
以下介绍我们在实际工作中遇到的常见问题及解决方案。
1、如何应对流量激增
。实现方式是根据自己的业务结合阿里云的SDK 、API相应的脚本进行编写。
2、如何选择监控指标
。以JAVA应用为例，它是比较占用内存的，当内存占比到70%-80%，它的CPU占用可能还很小；如果我们监控它的CPU使用率，尽管CPU占用处于正常范围，而内存可能已经用到90%或者更高，这种监控指标的选择是不太恰当的，我们应该根据不同的应用灵活地选择监控指标。
3、如何选择扩容和缩容的指标值
，例如，当CPU使用率大于50%的时候进行扩容，CPU使用率小于50%的时候进行缩容。这是因为扩容或者缩容都有冷却时间，如果CPU的使用率就在50%左右上下波动，可能最终导致我们的扩容或者缩容的目的无法实现。
04 四大实践经验总结
我们总结的实践经验有4点：
。因为弹性伸缩组是比较灵活的，如果我们设置的指标不太严格，可能导致ECS出现无序的扩容，或者出现ECS数量变成零等异常情况，从而对业务造成影响。
。这个和第一个类似，如果不设置上限或者上限值设置的不合理，可能会导致无序扩容，应用异常或者监控指标持续上升，最终导致服务器数量异常，对成本带来负担。
。抢占式实例的折扣在活动中可能低到1折，如果业务结构合适，通过分配一定比例的抢占式实例，可以有效地降低成本。
。阿里云提供了很多好用的工具，例如使用ECS云助手，可以对服务器进行批量的漏洞修复或者软件升级。
最后，分享一个弹性伸缩组的案例。在上图中，最高峰的时候，ECS数量应该有45台，最低的时候有10台，并且最低10台的时候我们做了一定的冗余处理。如果放开限制，ECS数量会变得更少，通过这样的部署方案，经过测算，成本总共降低了约30%。
大会官网，观看王威的精彩演讲视频。