微盟 Serverless 对应用效能和成本优化实践

本文首发自 微盟技术中心 微信公众平台~

近年来，AI 与大数据的 Serverless 化云产品如雨后春笋般涌现，各大云计算技术企业纷纷加入这场技术革新的热潮中。Serverless 化云产品具有按量付费、快速弹性伸缩、无需感知底层物理资源，更为经济的运维成本等优势，赢得了业界的广泛认可和积极响应。

在 12 月 28-29 日上海 QCon 软件开发大会上，策划了 Serverles 化云产品架构设计与实践专题，邀请了微盟容器运维专家李盛雁老师来会议上分享《用 Serverless 实现 SaaS 服务流量优化与快速响应》的话题，在正式演讲之前，我们邀请李盛雁老师大概介绍本话题的技术思路。

微盟集团成立于 2013 年 4 月，是中小企业云端商业及营销解决方案提供商，同时也是腾讯社交网络服务平台中小企业准确营销服务提供商。微盟围绕商业云、营销云、销售云打造智慧云端生态体系，通过去中心化的智慧商业解決方案赋能中小企业实现数字化转型。

背景简介

微盟全站业务容器化已经超过了 4 年时间，容器规模整体接近了 6W，其中包括了各种类型应用的容器。这其中包含了前端服务、后端服务、中间件服务、数据库服务等等容器，从另外一个维度来看包含了 IO 密集型应用、CPU 密集型应用、内存密集型应用等等容器。

这次主要分享的是微盟容器服务 Serverless 化项目中，对前端服务 (IO 密集型) 效能和成本优化的实践。

在介绍之前有这么几个问题要回答：

1. 为什么要对前端服务 Serverless 化？
2. 是我们原有的容器化方案有什么问题吗？
3. 为什么要对前端服务进行效能和成本优化呢？

从我的角度来看，是因为前端服务容器在日常运行的过程中，经常会因为一些业务属性导致传统容器系统无法满足现有的业务需求。

我在这边列举一些常见的问题：

1. 前端服务流量波动大，传统 HPA 响应慢，难以满足动态扩缩容需求。
2. 传统 HPA 反应缓慢，导致执行扩容时，原有 Pod 可能已超负荷，影响服务可用性。
3. 使用 NodeJS 的前端服务 Pod 因单 CPU 限制，需更多 Pod 数量支持流量。
4. 高并发下需提前扩容，流量峰值难预测，影响资源利用效率。
5. 商户爆款引起流量激增，导致扩容后 Pod 回收不及时，降低资源利用率。

上面只是简单列举了一些常见的问题，还有很多问题没有列举出来，但是这些问题都是我们在日常生产过程中遇到的，也是我们在后面需要解决的问题。

当然在没有使用 Serverless 之前我们在容器系统改造和优化过程中，我们也引入很其他开源组件或者自研模块：比如容器的生命周期管理、容器的资源管理、容器的监控告警和提前预测等等，希望通过在原有模式上寻找突破，虽然在一定程度上解决了一些问题，但是还是无法从根本上解决问题。

最终我们选择了 Serverless 的方案，下面我会详细介绍我们在微盟容器服务 Serverless 化过程中，是如何解决上面的问题的。

业务痛点 性能痛点：

• 业务特性：业务通常表现为高并发、高峰值和剧烈波动，与业务活动和热度紧密相关。
• 架构应对困难：传统架构难以适应这些需求，易导致资源不足、服务不稳定和扩容响应慢。
• 资源配置问题：大量预留资源可能导致资源浪费和低效利用，影响整体性能表现。

 成本痛点：

• 预测难度：业务增长和变化难以预测，可能导致资源过剩或不足。
• 成本与稳定性：资源不足可能影响性能和稳定性，过剩则造成成本浪费。
• 规划挑战：难以提出合适的资源规划方案，导致底层资源难以满足快速增长的需求。
• 成本投入：维护复杂业务场景需要大量人力和财力。

 开发痛点：

• 基础设施考量：需考虑底层基础设施和运维，影响开发效率和质量。
• 集成协调复杂性：与各种服务和组件的集成协调引入约束和妥协，为未来开发带来潜在困难。

建设目标

依据业务痛点，我们可以得出我们的目标是：

1. 快速扩容，应对流量波动，保障稳定。
2. 资源使用灵活，无需关注容器细节。
3. 操作简单、快速、稳定。
4. 提高资源效率，降低成本。

![图片](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/d1d7f0a23359442e9e372c574759df66~tplv-k3u1fbpfcp-jj-mark:0:0:0:0:q75.image#?w=1080&h=429&s=140924&e=png&b=f7f7fa)

 快速扩容

保证业务服务的稳定性，是我们的首要目标，也是我们的核心目标。如何快速扩容，应对流量波动，保障稳定是我们需要解决的问题。

这个问题也是我们最终选择 Serverless 的原因，因为 Serverless 的特性就是快速扩缩容，应对流量波动，保障相对稳定。Serverless 能做到这点是依赖底层 Knaitve 的扩缩容能力，Knaitve 的扩缩容能力是通过 KPA 算法来实现的，它能够根据业务的流量情况，自动扩容和缩容，从而保证业务的稳定性。

可以通过这个图来看一下 KPA 算法的工作原理：

• 稳定模式（Stable） : 在此模式下，Autoscaler 调整部署规模以实现每个 Pod 的平均并发目标。这一并发数基于 Pod 在 60 秒内接收的数据请求平均数计算得出。
• 恐慌模式（Panic） : Autoscaler 根据 60 秒窗口内的平均并发数计算，系统需在 1 分钟内稳定至目标并发水平。但若 6 秒内并发数达到目标的两倍，则进入恐慌模式，在此模式下，Autoscaler 使用更短、更敏感的紧急窗口。若紧急状态持续 60 秒，系统将恢复至原始的 60 秒稳定窗口。

Knative KPA 与 Kubernetes 的 HPA 的区别：

 灵活使用

一个复杂的系统，往往需要很多组件来支撑，这些组件之间的关系也是非常复杂的，所以我们在这边需要解决的问题是：如何让业务开发人员无需关注细节，只需要专注业务开发，按时交付。

在传统的容器化方案中，我们需要关注的东西太多了，比如：容器的生命周期管理、容器的资源管理、容器的监控告警和提前预测等等，但是这些东西对于业务开发人员来说，是不需要关注的。所以我们需要一个更好的方式来解决这个问题。

所以我们在完成了底层 Serverless 与 Kubernetes 的对接之后，不能直接将 Serverless 的能力直接暴露给业务开发人员，我们需要将 Serverless 的能力封装起来，对业务开发人员透明，同时把这些封装好的能力与现有管控平台对接（实现容器的生命周期管理、容器的资源管理、容器的监控告警、日志查看、状态性能分析等等），从而让业务开发人员无需关注容器细节，只需要专注业务开发。

 降本增效

在容器生产使用过程中，前端服务的容器绝大多数都是 NodeJS，只能使用单个 CPU。同时请求上无法准确预估商家的爆款流量，所以需要长时间预留大量闲置业务容器。那么如何降低成本是一个很大的问题，面对这个问题的很长时间中，一直都是依靠人力通过经验来预估，但是这种方式是不准确的，所以我们需要一个更好的方式来解决这个问题。

在 Serverless 的方案中，通过 KPA 来解决这个问题，利用业务流量的波动，自动扩容和缩容，从而降低成本。

通过一个结构图介绍我们在 Serverless 的方案中，Pod 数量是如何根据业务流量的波动来自动扩容和缩容的。

1. 请求首先通过 Ingress-gateway 进行路由，然后达到公共服务（Public service），流量会转发到对应的 Pod。
2. Autoscaler 定期通过队列代理（Queue-proxy）收集到达 Pod 的请求指标，并据此调整 Pod 的实例数量。
3. 随着持续的请求流向 Pod，Autoscaler 将依据最新的请求指标来确定适宜的扩缩容比例。

具体实践 系统架构

 融合能力

跟管控平台的产品、研发人员和使用 Serverless 的研发人员完成沟通后，确定了我们需要融合的 Serverless 能力特性，不仅需要对现有管控平台进行扩展，还需要对 Serverless 完成通用性能力封装后，最后将 Serverless 能力融合到现有管控平台中，从而实现 Serverless 能力的融合。

CI 流水线

差异化发布

应用状态监控

应用日志查询

应用调用链

获得收益

微盟应用服务 Serverless 化后，我们的效能和成本都有了非常大的提升。

降低运营复杂性：

• 解耦应用与服务器：Serverless 架构实现软件应用与服务器的解耦。
• 减少前期规划：用户无需提前规划服务器数量和规格。
• 简化运维监控：用户不需持续监控服务器状态，只需关注应用整体。

降低运营成本：

• 按需执行应用：Serverless 应用只在处理请求或事件触发时运行。
• 减少空闲资源成本：空闲时不占用资源，降低无效成本。
• 付费模式优化：仅为实际使用的计算资源付费，节约公有云成本。

缩短产品迭代时间：

• 功能解构：业务功能分解为多个独立应用。
• 清晰边界：功能间界限明确，减少耦合。
• 提升开发效率：加快软件开发进程，缩短迭代周期。

增强创新能力：

• 提高部署效率：加速应用的开发和部署。
• 低成本试验：灵活、低成本地尝试新想法。
• 创新激励：加强快速创新和实验的能力。

成果 & 总结 成果

经过大半年 Serverless 的方案优化，我们的前端服务的效能和成本都有了非常大的提升，具体成果如下：

1. 服务流量承载评估时间大幅缩短，从 2-3 小时降至仅 10 分钟。
2. 运维人员业务准备工作时间显著减少，从 20 分钟减到 2 分钟。
3. 应用容器资源空闲率降低，下降 15% 。
4. 应用容器资源成本大幅下降，降低了 40% 。
5. 研发团队使用 Serverless 的学习成本极低，0。

总结

通过这次前端服务 Serverless 的方案优化，不仅能够解决前端服务的问题，同时也很好的提升我们的服务效能和降低我们的服务成本，所以我们后续也会继续推进微盟容器服务 Serverless 化项目。在未来的时间里，我们将在原有的 Serverless 的方案上，继续进行优化，根据实际业务场景，融合与迭代更多新功能和新特性，从而更好的服务于我们的业务。