这个世界上有两件事我不明白——女生和无服务器

架构师修行之路

发布于 2021-04-22 11:44:38

5880

发布于 2021-04-22 11:44:38

文章被收录于专栏：架构师架构师

最近，我在YouTube上看了一个非常出色的开发人员的视频[1]。它的标题是“无服务器毫无意义”。虽然我非常喜欢该视频，但也不敢确定作者关于无服务器的观点是否完全正确，因此我想在本文中进行讨论。

在引言中，作者开了个玩笑：“这个世界上有两件事我不明白——女生和无服务器。”

我不知道他与女生的关系，但是对于无服务器的观点，他是对的吗？让我们看看他的批评，并讨论潜在的对立论点。剧透：我认为无服务器确实有意义，前提是你知道何时以及如何使用它。

无服务器的批判

YouTube视频上提到的最主要争论是速度问题。更具体地说，从作者的角度来看，无服务器应用程序的主要缺点是（众所周知的）冷启动问题——增加的延迟，你的代码只有在底层云服务完成分配计算资源，拉取代码或容器镜像，安装额外的程序包并配置环境之后才能开始执行。

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

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

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

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

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

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

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

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

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

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

如果你愿意支付额外的费用，那么有许多缓解冷启动的方法，例如利用预热的实例（提供并发性）或故意发出更多的请求（虚假请求[4]）以确保你的环境保持在线。通过使用诸如Dashbird的监控平台，你甚至可以收到发生在函数中的任何冷启动的通知，从而帮助你优化无服务器资源。在下图中，你可以看到在29个调用中，我们可以观察到一个冷启动，这使总执行时间增加了大约180毫秒的延迟。

Dashbird的可观察性功能有助于识别和防止冷启动（作者提供的图片）

你可以为任何冷启动配置Slack或电子邮件警报，以了解它们发生的频率。

在Dashbird中设置冷启动警报（作者提供）

改善Lambda函数延迟的技术

你可以通过适当利用上下文重用功能来减少无服务器函数的延迟。AWS冻结并存储Lambda的执行上下文，即在函数处理程序（handler）之外发生的所有事情。如果在相同的15分钟内执行了另一个函数，则可以重用冻结的环境。这意味着，如果你做了耗时的操作（例如连接到Lambda处理程序外的关系数据库），那么能够获得明显更好的性能。这篇文章[5]非常详细地解释了该主题。

有许多精彩的文章讨论如何缓解甚至完全消除冷启动问题，例如这篇[6]还有这篇[7]。Dashbird已开源名为xlambda[8]的Python库，该库可以让基于Python的Lambda函数保持在线状态（warm）。同样，杰里米·戴尔（Jeremy Dale）为JavaScript开源了一个类似的Lambda加热器程序包[9]。最后，这个无服务器框架[10]也包括了提供相同功能的插件[11]。

你的工作负载可接受多少延迟？

最终还是要问问自己，用例可接受的延迟时间是多少。当谈到冷启动引起的延迟时，我们通常争论的是毫秒。在我作为数据工程师的工作中遇到的所有用例（也构建后端API）中，日常业务中的延迟都不明显。

最后，诸如AWS的无服务器Kubernetes服务（在Fargate上也称为EKS）之类的平台使你可以在单个Kubernetes集群中混合无服务器和非无服务器数据层。这种混合使你能够在非无服务器EC2数据层上运行关键任务的低延迟工作负载，而其他工作负载（例如批处理）可以由无服务器数据层处理，从而获得这两个不同数据层的最佳性能。你可以在这篇文章[12]中找到有关此内容的更多信息。

无服务器是关于“无运维”和可扩展性

无服务器可以让你更专注业务，因为云提供商会帮你处理IT运维，例如配置和扩展计算集群，安装安全补丁和升级，以及解决硬件崩溃和内存问题。这会让你有更多的时间用来为终端客户提供服务。为客户提供更好的服务不就是我们的最终目的吗？

无服务器背后的自动化节省了高技能工程师的时间，因此他们可以专注于解决业务问题，而不是管理集群。它允许将IT运维的工作分担给AWS的DevOps专家，他们可能比该星球上的其他任何公司都拥有更多的管理计算相关的知识。

从无服务器中受益匪浅的案例

想象一下，你刚刚成立了一家初创公司。最初，你可能不需要大量的资源，并且可能只有一个开发人员。无服务器模式允许你从小规模开始，并且可以使用按需付费模式，自动扩展资源。

同样，可以从无服务器中受益的另一个群体是可能没有大型IT部门的小型企业。只需一名专业的DevOps工程师（而不是整个DevOps团队）就可以管理整个应用程序生命周期，这是无服务器的巨大优势。

如果你的工作量天然具有季节性，那么无服务器也是一个很好的选择。例如，如果你经营一家电子商务公司，则可能会在黑色星期五和圣诞节期间遇到季节性高峰。无服务器基础架构可以让你在这种情况下适应相应的工作量。

另外，某些事件是无法预测的。想象一下，你一直在网上商店出售洗手液，消毒剂，口罩以及类似物品。然后发生了全球性流行病，现在每个人都需要你的产品。无服务器基础架构可以在任何情况下为你提供任何规模的扩展。

代码速度vs开发周期速度

除了代码执行速度外，我们还应该考虑开发速度。在许多情况下，无服务器微服务模式可以加快开发周期，因为从设计上讲，它鼓励使用更小的单个组件，并让你能够彼此独立地部署每个服务。

如果无服务器能够让你快速的向利益相关者（stakeholders）交付应用程序的第一个版本，并在开发周期中加快迭代速度（同时降低成本），那么由于偶尔的冷启动而导致的几毫秒的延迟增加似乎是一个很小的问题。

与其他云服务的无缝集成

以AWS为例，每个无服务器服务都与CloudWatch集成在一起以进行日志记录，与IAM集成以管理访问权限，并与CloudTrail集成以收集度量指标和跟踪，等等。除此之外，无服务器平台通常为你提供基本的构建块，以构建更大的，解耦的微服务体系结构，例如与无服务器消息队列（SQS），无服务器发布-订阅消息总线（SNS），无服务器NoSQL数据存储（DynamoDB）以及对象存储（S3）集成。

YouTube视频中未考虑到的无服务器弊端

视频中还存在一些未提及的缺点，我想列出来，以便给你提供完整的认识，而无需添加任何糖衣。

即使在许多用例中，无服务器在成本，可伸缩性和维护方面似乎都像是一个天堂，但这并不是每个用例的银弹。

面临供应商锁定的风险：云提供商使他们的服务使用起来非常方便并且具有成本效益，以至于你天然的面临被锁定在其特定平台中的风险。
从某种程度上看，无服务器资源相比较自托管资源，你能够对计算资源的控制会比较弱一些。例如，你不能通过SSH到底层的计算实例上手动执行某些配置，并且在实例类型方面你的自由度也较小。例如，你无法在具有GPU的计算实例上运行无服务器函数或容器（目前）。
如果你有一些特定的合规性要求，让你无法在云上的共享租户上处理数据，那么无服务器可能不是你的选择。
尽管将你的IT基础架构拆分为独立的微服务有助于管理依赖并能够加快发布周期，但这也带来了对于独立服务管理方面的挑战。尽管监控解决方案（例如Dashbird）在很大程度上解决了此特定问题，但你也需要意识到这些。

无服务器批判的总结

总体而言，当我们想要像建立自托管的本地技术一样使用无服务器或云服务之类的新模式时，常常会遇到问题。这根本不是使用它的最佳方法。在将工作负载移至云上时，如果直接迁移，那么你将失去云服务的许多好处，甚至会误解其目的。没有一个万能的解决方案，因为我们不能期望任何技术都能在所有用例中使用，成为世界上最快的技术，并且在没有任何不利方面（例如偶尔的冷启动）的情况下几乎还没有额外的成本。

从我的角度来看，在谈论无服务器（坦率地说，是与IT相关的任何内容）时，我们不应只考虑一个方面而不检查其他关键方面，尤其是那些在各自技术的设计中至关重要的方面。从这个意义上说，无服务器确实有其存在的道理，前提是你知道何时以及如何使用它。