遵循这些建议，以消除非计算瓶颈，避免供应商节流和排队，以及保持无服务器功能的响应。
无服务器计算现在十分流行。所有人要么在调查它，要么已经部署它了。不要落在最后，否则你会错过的！
有什么好大惊小怪的？无服务器计算提供了一种基础结构，让服务器资源在需要时应用于系统以进行扩展，从而有效地将计算能力作为一种实用工具，供系统根据负载需求使用。
这意味着没有人需要在运行时关心单个服务器（坦率地说，从来没有人关心过它们）。规模经济使得将管理一批服务器外包给云提供商变得具有成本效益了，而通过最小化契约，“无服务器”接口将这个外包关系变得尽可能简单。
作为人类，许多人的第一反应是尝试用与其无服务器功能相关的图表、交通灯和警报替换他们附加到服务器上的图表、交通灯和警报。然而，遗憾的是，这并不能从根本上解决应用程序管理的挑战。因为正如没有人真正关心服务器一样，也没有人真正关心孤立的无服务器功能。
人们真正关心的是系统向用户提供的服务水平。这意味着，为了具有价值，监视必须集中在可能出错的地方，而在无服务器的情况下，“出错”主要意味着试图违反物理定律，因为“耗尽服务器容量”实际上已经不再讨论范围之内了。
那么典型的无服务器问题是什么？它们是如何表现的？以下是困扰无服务器部署的三大问题以及消除它们的方法。
冷启动成本
问题：这是无服务器系统中经常讨论到的问题。为了最大化利用，无服务器提供者有时会选择完全关闭不活动的功能。当负载重新开始时，功能启动成本会对响应时间造成一定的影响。而当一个业务功能是由许多链接在一起的无服务器功能组成的时，这种影响就可以进行复合。
解决办法：许多用户会人为地对其功能进行 Ping命令，以确保它们是活着的。为了有效地将此策略应用于链接服务的网络，就必须了解它们之间的端到端的关系，以便使依赖链中的所有服务都保持活动状态，从而使商业事务的端到端的跟踪变得必不可少。
节流
问题：无服务器平台限制了无服务器功能即将执行的并发请求的数量，这通常是在帐户和单个功能级别。一旦达到并发限制，排队的用户请求就会变得更多，从而延长响应时间。虽然对潜在的、无限的计算资源池进行节流似乎有悖直觉，但这确实可以防止账单潜在地无限进行增长（不要忘记，容量是按消耗计费的）。
解决办法：提高门槛！或者至少，确保合理地设置它们，以满足响应时间和并发使用方面任何非功能性的需求。同样，端到端的可见性也是必需的，这样就可以准确地判断节流情况，以及节流对终端用户体验的影响。
非计算瓶颈
问题：好的，你已经移除了所有无服务器节流，因此现在你的功能将支持尽可能多的并发请求。问题解决了！但可悲的是，这只是将问题转移了而已。迟早，你的功能将需要在某个地方保持某种状态。根据其所处位置的不同，你可能会遇到更多的麻烦。不久之后，你就将需要等待读取或写入数据，这意味着你的无限扩展的匿名功能都将等待进行数据访问——而在这一徒劳的等待过程中，你将会被收取费用。
根据持久性存储的不同，功能像这样挂起的确切原因也将有所不同。
云数据存储：云数据服务正变得越来越有弹性，但许多服务仍然需要基于并发读写量来配置资源。
传统系统：没有功能是孤立的，许多无服务器企业用户都在用无服务器功能(有时是大型机，有时是基于传统服务器的部署)包装现有系统。虽然提高阈值以允许功能扩展是很容易的，但这仅仅意味着覆盖无法轻松进行扩展的后端是很容易的。
解决办法：为了确保你的后端系统能够处理理论上的最大负载，请结合你的功能节流对它们进行调整。这将帮助确保系统顺畅地从端到端进行，从而避免不必要的成本和客户的不满。在某些情况下，你可能需要复制数据，以使不同的系统能够从不同的地方访问它们。(当然，这样做的代价是增加了数据管理的复杂性，以及数据不一致的风险。)
同样，对于识别和警报生产中的瓶颈，以及从端到端地对系统进行分析来说，在事务级别上理解通过系统的端到端的流动是非常重要的。
关注无服务器的开发运维
我听到你在说，“但我是一个开发人员！我为什么要关心这种疯狂的、非功能性的部署呢？”
无服务器最大的暗示是，配置现在变为了代码(或者至少是其中一部分)。在无服务器环境中，开发人员现在交付给生产的是整个软件包，而不仅仅是功能部件。
这反过来意味着，一旦用IDE调试了生产问题，在无服务器环境中，你最好也要熟悉某种性能管理解决方案，因为至少有一半的“漏洞”可能是与部署相关的。这不再是“他们的错”（即开发运维）。系统的命运完全掌握在你的手中——应用程序级别的端到端的可见性对你来说将变得至关重要。
