共计 3340 个字符，预计需要花费 9 分钟才能阅读完成。
作者：丛霄
背景介绍
全托管的 Serverless 计算平台能给用户带来更少的运维代价、更强的稳定性和更快的弹性能力。
Serverless 的指标之一是免运维，但仍旧存在一些阻碍，在 Serverless 场景特有的一些要害服务配置比方 “并发度”、“最小实例数”、“最大实例数”，如何配置参数才是最合适的？怎么确定本人配置的参数是否正当？仍旧始终是让用户头痛的事件。
本文介绍了函数计算团队在自动化举荐 Serverless 函数最佳配置上的思考和相干工作，心愿帮忙用户解决目前应用 Serverless 的痛点问题，彻底解放用户的双手，开释 Serverless 服务的价值。
评估 Serverless 服务最佳配置的难点
用户应用 Serverless 服务的预期是：更低的老本、更快的弹性、更优的性能、更稳固的环境，这同时也是 Serverless 平台承诺提供给用户的能力。尽管如此，很多用户在应用过程中还是呈现了各种问题：
- 为什么应用 Serverless 后发现老本还变高了？
- 为什么应用 Serverless 的冷启动工夫那么长？
- 在 Serverless 平台上的性能提早体现为什么更差了？
Serverless 平台能提供肯定的根底能力，然而针对不同的业务逻辑，须要采取适合的配置能力更好的施展 Serverless 的成果。然而如何评估某函数的最佳配置，其中波及到多变量的协同优化问题，并不是一个简略的问题。具备以下几个难点：
难点 1：老本和性能的衡量
- 肯定的单实例多并发数，能够进步单实例并行处理申请的数量，缩小实例数，从而降低成本；
- 并发数过高时，会减少资源竞争，导致性能提早减少，从而减少老本；
- 较低的实例规格单价老本更低，然而延时更大；较高的实例规格单价成更高，然而延时可能更低
如何针对用户的偏好场景（性能优先还是老本优先），为用户举荐最佳的函数配置，成为首先须要思考的一大难点。
难点 2：不同函数业务逻辑的复杂度
除了老本和性能维度的掂量，针对不同类型的函数逻辑，不同的配置参数成果也有差别。很多函数业务逻辑简单，只针对繁多逻辑分支进行评估最佳配置并不代表整体的最优；不适合的配置可能增大用户非预期的老本。比方：
- 对于 CPU 密集型的函数，规格减少对单实例性能的晋升有较大的改善
- 对于 IO 密集型的函数，规格减少对单实例性能的晋升存在边际效应递加的状况，当超过某规格后，规格的晋升对性能晋升的成果根本没有
比方下图展现了 CPU 密集型函数在不同规格下的压测数据：
CPU 密集型的规格越高，maxTPS 越大；并且规格与 maxTPS 出现显著的线性关系。
规格越大，maxRT 越低，阐明 CPU 密集型的函数，增大资源规格能够显著升高 RT。然而规格增大到 4G、8G 后，对 RT 的升高成果边际效应递加。
下图展现了 IO 密集型函数在不同规格下的压测数据：
规格的晋升对 IO 密集型的性能改善作用无限，特地到了高规格，比方 3G 后，maxTPS 增幅不大
难点 3: 函数配置对平台侧资源的影响
函数的并发度、最小实例数、最大实例数等配置会影响到平台侧资源池的容量布局，如何保障单函数的资源刚性交付，多函数的资源隔离；如何优化平台侧弹性调度能力，进步平台侧的资源利用率，是另一个难点问题。
- 较低的单实例并发度，函数流量稳定变动的场景，会提前达到单实例并发下限，导致实例扩缩容频繁，对用户体感来说的冷启动更频繁，对平台来说须要创立和保护更多的实例个数，整体的资源利用率偏低
- 最大实例数的配置，如何保障实例资源的刚性交付
如何评估 Serverless 服务的最佳配置
通过以上几个难点剖析，咱们晓得评估 Serverless 服务的最佳配置并非易事，上面的几个演变阶段，介绍了用户应用 Serverless 进行服务配置的形式变动，从青铜到王者，咱们始终在为用户提供最好的 Serverless 服务致力。
青铜用户：拍脑袋设置
在上线初期，用户须要面对一堆配置参数，如果是首次应用函数计算的新用户，还须要翻看文档才理解配置含意，重复折腾后也不晓得配置参数多少才适合，最初还是“拍脑袋”轻易设置了一个值。
白银用户：人工重复调整
函数上线后，可能会发现之前的配置不合理，仍旧须要重复批改函数配置验证。如果批改了函数逻辑，可能会发现之前的配置会呈现问题，比方申请提早变大，或者函数偶尔呈现 OOM 谬误。
有一些教训的开发者会抉择本人进行压测，确定函数的最佳配置。然而压测的应用具备肯定的门槛，并且压测失去数据个别用户也不晓得怎么剖析，可能会产生更多的疑难。最终折腾一番，用户也不是很确定压测失去的配置是否是最合乎本人预期的最优抉择。
为了解决青铜和白银用户的这些困扰，咱们推出了自动化举荐配置的王者性能。
王者：性能探测 + 数据分析的自动化举荐
近期函数计算重磅推出了函数的 性能探测性能， 性能探测的目标是帮忙用户评估函数单个实例在不同规格下的性能下限，并且举荐出满足用户预期提早的最佳并发度和函数规格配置。
具体的探测办法，依据 little’s law 排队实践，咱们晓得服务的吞吐量、并发数和响应工夫之间存在着一个等式关系：并发数 = 申请的均匀提早 * TPS
如果咱们应用图形化示意，如下图所示：
横坐标是并发数，右边的纵坐标是 TPS，左边的纵坐标是提早。因为每个服务器的解决能力都无限，所以会呈现
- 吞吐量 - 并发数：随着并发数回升，吞吐量先回升后平缓，可能呈现降落，即性能好转；
- 提早 - 并发数：当并发度过高时，提早会变高，甚至会急剧好转；
通过性能探测，咱们会失去每种规格的要害性能数据：
- 每个规格的最高能接受的 QPS：基于此，用户如果对业务流量比较清楚，能够计算失去函数所需的最小实例数和最大实例数。
- 举荐的最佳规格和规格下的最佳并发度。
比方用户预期本人的函数调用端到端提早是 1000 毫秒，那么咱们会依据 1000 毫秒的提早限度，举荐出最佳的规格，以及该规格下的最佳并发度，即满足提早限度的最高 QPS 时对应的并发度。
整个性能采纳流程图的形式指引，先压测单实例，再压测多实例，因为在性能体现安稳的零碎，多实例的性能是单实例性能的线性叠加，所以只须要压测出单实例的性能，就能够推算出多实例的性能。
用户可能依据疏导使用性能探测，并失去举荐后果；同时性能探测性能是完全免费的，用户只须要为函数承接的申请流量付费，不须要为压测性能付费。
单实例压测后果剖析页面：
单实例压测数据详情页面：
目前函数性能压测性能曾经在函数计算控制台上线，具体具体的应用形式能够参考文档。
性能探测举荐的函数配置优先保障满足性能需求，实现最高的资源利用率，然而真正实现最低老本配置，须要联合函数线上历史流量数据分析，进行举荐。
在进行老本优化举荐规格时，不仅须要达到节约老本的目标，还须要保障不毁坏现有服务的 QoS，即性能不会因为实例规格的升高，而导致提早增大。
比方上面这张图示意用户理论资源使用量较低，理论配置的规格偏大，咱们能够举荐更低的规格，以帮忙用户节约老本。
通过联合性能探测 + 历史流量数据分析，能够自动化给用户举荐失去保障性能的同时，老本最低的最佳函数配置。
至尊王者：智能动静调整并发度
最初咱们期待的至尊王者，是彻底解放用户的双手，可能智能动静地调整函数的并发度，不论流量变动或业务逻辑如何变动，用户再也不须要关怀或重新配置函数并发度的大小。
智能动静并发度将来一个演变方向，在这种模式下，用户不须要通过手动配置参数，而是在函数运行时动静调整，依据实例 CPU 负载的衰弱指标主动调整到最佳值。函数计算也会持续致力，打造体验更好的，更帮用户节省成本，更 Serverless 的自动化配置计划。
总结与瞻望
目前性能探测性能曾经在函数计算控制台凋谢，基于历史流量评估可能降低成本的最佳配置也会在近期公测凋谢。基于性能探测的自动化举荐函数配置性能，极大升高了用户上手以及运维函数配置的复杂度，冀望能给用户应用 Serverless 带来王者般的体验。
附加链接
[1] 函数性能探测
https://help.aliyun.com/document_detail/477504.html
[2] 参考《Little’s Law Wikipedia RobustScaler: QoS-Aware Autoscaling for Complex Workloads》
https://arxiv.org/abs/2204.07197
