许多工程师不了解无服务器

(众所周知的)冷启动问题——增加的延迟，你的代码只有在底层云服务完成分配计算资源，拉取代码或容器镜像，安装额外的程序包并配置环境之后才能开始执行。

优先考虑执行速度的工程师给人的印象是，整个应用程序生命周期管理的最终成功指标是我们的代码完成所需执行任务的速度。

作为一个在IT行业工作多年的人，我看到的实际问题却是更多关注维护性以及利用技术来快速可靠的提供商业价值的能力，我不确定这种指标是否正确地衡量了最重要的因素——评估时间， 开发周期的速度，易于维护，为最终用户降低成本，通过促进无缝的IT运营来降低运营中的风险，最后，分配我们的大部分工程时间来正确解决实际业务问题而不是在配置和管理服务器上。

一些工程师错过了什么?无服务器的真正好处

如果你对执行速度这点特别关心并且偶尔的200毫秒(在AWS上能达到一秒)的延迟在你的工作负载中是不可接受的，那么无服务器确实不是你的选择，这点完全可以接受。 但是，我们不能因为无服务器的延迟就说它毫无用处。 每个人都需要自己决定用例中可接受的延迟时间。

无服务器是管理IT基础架构的一种极具成本效益和高效的方式，对于可能没有很多钱用于闲置资源的IT部门以及一支专门7×24小时的支持工程师的维护团队特别有利。

无服务器的低成本可能胜过任何弊端

在我看到的大多数用例中，仅在考虑实际计算成本的情况下，无服务器就比自托管资源便宜几个数量级。 如果再考虑无服务器显着减少了操作，扩展和维护基础架构所需的时间(总拥有成本，简称TCO)，那么这时你才真正认识到成本的节省。事实上维护基础架构的全职工程师团队比任何无服务器资源的成本都要高得多。

我并不是说对于所有用例无服务器选项总是更便宜。 如果你持续收到数亿个请求，如果你的工作负载非常稳定，并且如果你有足够的工程师可以监控和扩展所有这些资源，那么使用自托管的基础架构确实可能会更好。

冷启动是配置和预算的问题

回到成本问题上来，冷启动问题在很大程度上取决于你愿意花费多少以及如何配置无服务器资源。

如果你愿意支付额外的费用，那么有许多缓解冷启动的方法，例如利用预热的实例(提供并发性)或故意发出更多的请求(虚假请求)以确保你的环境保持在线。 通过使用诸如Dashbird的监控平台，你甚至可以收到发生在函数中的任何冷启动的通知，从而帮助你优化无服务器资源。 在下图中，你可以看到在29个调用中，我们可以观察到

（编辑：信阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!