无服务器计算风靡一时，遵循以下提示可消除其中的非计算瓶颈，避免程序限制和任务排队，并保持功能的及时响应…

无服务器计算提供了一个基础架构，允许将服务器资源应用于系统，以便扩展并有效提供计算能力，但省去了服务器管理带来的麻烦，这意味着没有人需要在运行时关心单个服务器（坦率地说，没有人真正关心过），这使得将一组服务器外包到云提供商具有成本效益，而无服务器界面通过最小化合同使外包关系变得尽可能简单。

关于无服务器，许多人的直接反应是尝试用图表和与其各自无服务器功能相关的告警来替换附加到服务器的图表和告警。然而，这并未从根本上解决应用程序管理挑战。正如没有人真正关心服务器一样，没有人真正关心无服务器功能。

大部分人关心的只是系统为用户提供的服务水平，这意味着有价值的监控必须关注可能出错的事情，并且在无服务器的情况下，出错不再关注服务器层面，因为服务器容量耗尽等错误已经被有效隐藏。那么，典型的无服务器问题是什么？又是如何表现的呢？

冷启动成本

这是无服务器系统经常出现且被频繁讨论的问题，为了最大限度提高利用率，无服务器提供商有时会选择完全关闭非活动功能。当负载恢复时，启动成本会导致响应时间延长。当一个业务功能由链接在一起的许多无服务器功能组成时，这种效果可能会复杂化。

解决方法：许多用户人为ping功能以确保服务活着。要通过链式服务网络有效应用此策略，必须了解它们之间的端到端关系，以便依赖链中的所有服务保持活动状态，从而使业务的端到端跟踪必不可少。

资源请求

无服务器平台会限制无服务器功能将执行的并发请求数，通常是在某个帐户和单个功能级别。一旦达到并发限制，进一步的用户请求将排队，从而导致响应时间延长。虽然限制有效计算资源池似乎有悖常理，但这确实可以防止潜在花销（不要忘记，容量按消费基础计费）。

解决方法：提高门槛或者确保合理设置资源以满足响应时间和并发方面的任何非功能性要求。同样，需要端到端的可见性，因此可以快速确定受限制的内容，以及限制对最终用户体验的影响。

如果解决了所有无服务器限制，就可以支持尽可能多的并发请求。根据具体情况，这并不意味着麻烦彻底解决，如果等待读取或写入数据，就需要无限缩放lambda等待数据访问，同时需要为非生产性等待付费。

功能悬挂的确切原因随持久性存储的不同而有差异：

云数据存储：云数据服务变得越来越有弹性，但许多仍需要根据并发读写卷配置资源。
传统系统：没有哪个功能是孤岛，许多做无服务器的用户正在使用无服务器功能（有时是大型机，有时是传统的基于服务器的部署）包装现有系统。虽然很容易提高阈值以允许功能扩展，但这只意味着很容易压倒无法轻易扩展的后端。

解决方案：为了确保后端系统能够承受理论上的最大负载，请将它们与功能限制器一起调整。这有助于确保系统端到端地顺利运行，从而避免不必要的成本和客户不满。在某些情况下，可能需要复制数据以使不同的系统从不同的位置访问（当然，这以增加数据管理复杂性为代价，可能导致不一致的风险蔓延到数据中）。

此外，在事务级别了解系统端到端流程，对识别和告警生产瓶颈以及端到端分析至关重要。

无服务器最普遍的含义是，开发人员配置代码，在无服务器计算中为生产提供整个包，而不仅仅是功能部件，这意味着一旦使用IDE调试生产问题，最好熟悉某种性能管理解决方案，因为至少一半“错误”可能会与部署相关。系统命运完全在个人手中，应用程序级别的端到端可见性至关重要。