腾讯云资源伸缩平台实现

前言，我们的场景是应用部署于CVM云主机上面，每当大促活动前后，服务的高频扩缩容给运维人员带来了不小的挑战。
也许你可能会问：哎？！为何你们不直接把部署在云主机上的应用容器化掉呢？迁移到k8s中不就没有动态扩缩容的问题了吗？为什么要化大成本做小事情呢？
答：任何一个解决方案如果不站在具体的场景中，去考虑落地问题，都是耍流氓！千台云主机规模的架构，如何实现快速，低故障率的容器化改造？容器化改造后的性能问题有考虑过吗？容器化改造的成本？时间成本，维护成本，我想在迁移的过程中，代码的迭代速度也会有直接或间接的影响吧？所以，我们决定做这样一个事情的前提是，在双十一之前，运维同学可以做到自动化扩缩容！而留给我们的时间却只有两个月。

手工操作带来的巨大风险

运维侧面临的问题

• 手工扩容面临诸多不便，带来极高的误操作概率
• 时间周期过长，应用大大小小有几百个，每个应用扩下来非常繁琐
• 工作效率低下，自动化程度 = 0

  公司层面临的问题

• 提前一个月扩容，时间和成本造成巨大浪费
• 需要承受一定因扩容带来的故障率

  手动扩容一次需要做哪些事情？

  

  立项

  所以在2021年的双十一前，我们决定投入一定的精力，将运维解脱出来，将成本释放回来。就算双十一过后，我们将运行在云主机上的应用全部迁入到k8s中，那么我们一次双十一，也可以剩下一笔相当可观的费用，因为我们的目标是：当天活动，当天扩容，而且全流程自动化！就以前提前一个月扩容的方式对比，我们的成本初步估计：1:30

如何落地？

现在到了最令我们头疼的环节，那就是如何落地这个平台？上面也看到了单应用扩容这个过程，繁琐复杂，且我的一切操作均和生产环境有关，一旦出现错误可能是致命的！但好在自动化的前提是：将复杂的用户操作，梳理为流程。通过设计手段将流程变为可落地的应用或者模块。按照上面的手工操作步骤，这个流程显而易见我们已经有了

如何设计？

最开始我们想到的是，能否利用腾讯云的弹性伸缩（autoscaling）来实现？
优点：开发量最小，实现时间最短，可靠性相对较高。
缺点：自然是无法百分百满足定制化场景

借鉴了腾讯云弹性伸缩的页面布局设计后，我们开始对自己的资源伸缩有了初步的一个设计模型：

• 首先我们的应用信息肯定是基于CMDB上拉取过来，在自己本地维护一份数据，至于关联机器的增减则调用CMDB相关接口。
• 扩容和缩容的两个任务设计上，我们首先保证了一条原则：那就是无状态任务！有状态会让程序实现变得更加复杂。每次任务执行会在后台开启一个协程，这个协程顺序执行各种操作，如果中间某个步骤失败，则将本次任务置为失败状态然后退出。人为介入处理排查失败原因后，再次提交任务即可。同时这也符合，在繁杂的线上扩容任务中，有任何一个环节失败，我们都不希望任务继续执行的理念
• 最后，我们将扩容和放量也分开处理，因为放量被视为一个高危线上操作，需要用户前台确认机器准备无误才允许放量，这样的一套流程设计充分体现了无状态任务的优势，同时也大大减少了编码时间

  资源伸缩调用关系图

  

  扩容操作步骤：

  1. 点击按钮扩容，喝杯咖啡的功夫等待后台任务持续运行～
     
  2. 新机器放量，像操作负载均衡一样给新机器分配权重。
     PS：这里为什么要这样考虑？举一个场景，腾讯云云主机故障，需要下线维护处理。此时我轻轻松松关掉流量。随他怎么处理～
     
     操作仅需两大步骤，且全部是以页面点击，自动化的方式完成

     缩容操作步骤：

  3. 调整权重，回收线上流量，这个和扩容操作步骤反过来执行即可
     
     当然所有权重相关的高危操作，均有操作历史记录
     

2. 确认机器无流量，点击按钮直接缩容
   

   过程中遇到过哪些问题？

3. 扩容时长问题，怎么控制在10分钟以内？

   最开始，我们是每次扩容，每次选一台在线机器制作镜像。但无疑带来的一个问题就是时间过长，有的机器上面磁盘比较大的，制作一次镜像一个小时也是有的。
   改进：是否可以将制作镜像的动作前置。因为系统参数是不可能频繁变动的，频繁变动的只有代码。那么我们每天0点批量跑一次脚本，触发所有应用对应的镜像机器制作镜像。然后每次扩容的时候，只需要保证新机器代码版本一直即可

4. 如何保证新机器和老机器保持代码版本一致性问题？

   线上运行有5台机器，扩容的时候我又扩出来5台，这10台机器如何保证代码是全部一致的？
   方案一：机器准备好后，触发jenkins构建，默认发布一次代码
   方案二：找到最新发布的历史版本，最新的版本我认为是老的5台机器上稳定运行的代码，然后出发构建，仅部署新出来的5台机器
   综合稳定性考虑我们选择了方案二，也成功的解决了我们的问题

5. 如何动态调整机器权重？

   调整机器权重，这需要我们的业务机器，一定要做到流量可配置。要么依赖云厂商的负载均衡，或者依赖服务的配置中心都可以，但一定要有这个标准，不然资源伸缩是没有办法去调整权重的。我们的业务架构是LNMP，但我们将所有机器上的nginx提取出来，单独放在一个nginx集群，集群的upstream信息则是存储在了consul中，这样资源伸缩只需要操作consul集群便可以动态调整机器权重。这也涉及到了一个标准先行的问题，需要做一个系统之前也要尽可能的考虑到有哪些需要标准化先落地的场景

   项目成果

   • 成本控制层面
     按照以往提前一个月开始手动扩容的情况对比，成本节约了至少40%以上
   • 稳定性层面
     完全实现了自动化，从根本上杜绝了人为误操作的可能性
   • 工作效率层面
     无疑解决掉了运维相当一部分的工作量，且运维在面对大促活动前的准备工作没有了心里负担