ADmobile首席架构师王威：广告业务云上运维最佳实践
12月21日，在阿里云弹性计算年度峰会上，ADmobile首席架构师王威发表了《ADmobile广告业务云上弹性计算最佳实践》的演讲，介绍了ADmobile业务云上最佳实践。
【图：ADmobile首席架构师王威】
本文主要根据王威的演讲整理而成，内容分为四部分：
-
业务背景介绍；
-
业务发展中的技术痛点；
-
解决方案；
-
实践经验。
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%。
12月21日，在阿里云弹性计算年度峰会上，ADmobile首席架构师王威发表了《ADmobile广告业务云上弹性计算最佳实践》的演讲，介绍了ADmobile业务云上最佳实践。
【图：ADmobile首席架构师王威】
本文主要根据王威的演讲整理而成，内容分为四部分：
-
业务背景介绍；
-
业务发展中的技术痛点；
-
解决方案；
-
实践经验。
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%。