05｜扩缩容：如何应对流量的波峰波谷？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
Serverless函数计算的动态扩缩容是其核心特性之一，本文深入探讨了其实现原理及应用场景。通过真实场景展示了流量波峰波谷对资源需求的变化，以及Serverless函数计算通过弹性扩缩容能力解决资源利用率低的问题。文章从K8s的HPA和开源Serverless框架Knative的KPA入手，深入探讨了自动扩缩容的架构原理，以及Node维度和Pod维度的扩缩容方式。强调了Serverless语义下的动态扩缩容可以让服务缩容到0，而HPA机制无法实现这一点。总的来说，本文通过深入的技术分析，展现了Serverless函数计算动态扩缩容的核心思想和实现机制，为读者提供了深入了解和设计系统的指导。同时，文章还掏出了扩缩容模型设计思路和为服务引入预测能力的方法，为读者提供了更多的思考和探索空间。
《Serverless 进阶实战课》，新⼈⾸单¥59
全部留言(6)
- 最新
- 精选
- Helios老师，我看云厂商提供了chrome这样高计算类服务，按量计费的，这样扩缩容的稳定性如何，能否将现有的在线业务迁移到serverless上呢？
作者回复: 一般云厂商都会提供服务等级协议，里面有对服务SLA 的承诺和赔偿，我们在迁移之前，首先要看老服务稳定性保证和云厂商的是否匹配，另外，还要看这个场景是否合适以及迁移成本，这块的分类和技巧，我会在第三模块中的实战指南跟你细聊哈，欢迎持续关注交流哈
2022-09-19归属地：上海1 
兰天Serverless 由于具备弹性扩缩容的能力，可以完美地解决场景 1 的问题。 对这个问题一直有个疑问，虽然晚上可以缩容，但对于云厂商或自建平台还是要保留很多资源等到白天继续扩容。晚上可以跑离线数据或其它，但白天和晚上是不可能平衡的吧，如果晚上无法充分利用，这部分资源还是要用户买单？作者回复: 这个就涉及到售卖率的问题了，针对公有云，是不需要用户承担这部分费用的，云厂商会根据底层的资源来调度。在一个大盘子里面对云资源利用规划。对于私有化，由于企业自建，业务用户和场景基数比较小，如果只考虑Serverless的扩缩容是不行的，资源池比如在夜间的使用，就需要运维工程师根据场景做调度，比如大数据跑批，放在夜间做。相对的平衡是要做的，否则对于IaaS 层的资源起不到很好的利用率。而我们通常说的按需使用，按量付费，更多的是侧重用户业务的使用。
2022-09-18归属地：上海1
小Y老师，我对从0到1部分还有疑问。文中讲，是当 Revision 存在实例时流量接收的情况，那么如果 Revision 实例缩容到了 0的处理策略。 但是！ 我觉得从1到0似乎更难理解，当没有用户实例的流量的时候，又是怎样感知到的呢？又是通过什么机制将实例从1个变成无的呢？作者回复: 每个pod 会注入一个我们所说的兄弟，queue-proxy ，它负责向Autoscaler报告指标。
2023-05-28归属地：广东2- sqnv_geekwhat is cold pod? can we remove the cold pod if no traffic ingress ?
作者回复: Cold pod 的初衷是为了让流量到来之时可以快速激活，使用中的pod 我们成为warm pod ，一段时间没有请求过来，比如1分钟，会设置为cold pod ， 在过一段时间，cold 会背清除。这个主要看系统的实现方式以及状态扭转。
2022-11-30归属地：上海 
zouqiangShceduler 拼错字了作者回复: 看的仔细👍，已修改
2022-10-15归属地：江苏
奕基于 Node 的扩容方式，扩容一个 Node 就会生成 一批 Pod ，如果这时候 用户只需要 使用一个函数实例（Pod） 还是会造成资源浪费作者回复: 优秀👍，是的，出于安全的考虑，如果通过Node 隔离用户，那么，对于薅羊毛型的用户，会给云厂商带来一定的成本压力。基于安全容器的方式就会好很多。
2022-09-08归属地：上海
