最近在YouTube上看到一个非常牛逼的开发者的视频。它的标题是“无服务器是毫无意义的”。虽然我真的很喜欢这个视频，但我不确定作者对无服务器的看法是否完全正确，所以我想我会在本文中讨论它。在介绍中，作者开了个玩笑：“这个世界上有两件事我不懂——女生和serverless。”我不知道他与女孩的关系，但他对无服务器的看法是否正确？?让我们看看他的批评并讨论潜在的反驳。剧透：我认为无服务器确实有意义，前提是您知道何时以及如何使用它。无服务器批评YouTube视频中提到的主要论点是速度问题。更具体地说，从作者的角度来看，无服务器应用程序的主要缺点是（众所周知的）冷启动问题——当底层云服务分配计算资源、拉取代码或A容器镜像，在安装附加包和配置环境后开始执行。优先考虑执行速度的工程师的印象是，衡量整个应用程序生命周期管理成功与否的最终标准是我们的代码能够以多快的速度完成其需要执行的任务。作为在IT行业工作多年的人，我看到的实际问题是更注重可维护性和使用技术快速可靠地交付业务价值的能力。我不确定这个指标是否正确衡量了最重要的因素——评估时间、开发周期的速度、易于维护、降低最终用户的成本、通过促进无缝IT操作降低操作风险，最后，分配我们的大部分正确解决实际业务问题的工程时间不在配置和管理服务器上。一些工程师错过了什么？Serverless的真正好处这真的不是您的选择，这是完全可以接受的。但是，我们不能因为它的延迟就说Serverless是无用的。每个人都需要自己决定他们的用例可以接受什么样的延迟。无服务器是一种极具成本效益和高效的IT基础设施管理方式，对于可能没有太多资金用于闲置资源的IT部门以及24/7全天候支持工程师的专门维护团队尤其有益。无服务器的低成本可能超过任何缺点在我见过的大多数用例中，仅考虑实际计算成本，无服务器比自托管资源便宜几个数量级。如果您随后认为无服务器显着减少了操作、扩展和维护基础架构所需的时间（总拥有成本，简称TCO），那么您就会真正意识到成本的节省。事实上，维护基础设施的全职工程师团队比任何无服务器资源都要昂贵得多。我并不是说无服务器选项对于所有用例来说总是更便宜。如果您不断收到数亿个请求，如果您的工作负载非常稳定，并且如果您有足够多的工程师可以监控和扩展所有这些资源，那么使用自托管基础设施可能确实更好。冷启动是配置和预算的问题回到成本问题，冷启动问题在很大程度上取决于您愿意花多少钱以及如何配置无服务器资源。如果您愿意支付额外费用，有多种方法可以缓解冷启动，例如利用预热实例（提供并发）或有意发出更多请求（假请求）以确保您的环境保持在线。通过使用Dashbird等监控平台，您甚至可以在函数中发生任何冷启动时收到通知，帮助您优化无服务器资源。在下图中，您可以看到在29次调用中，我们可以观察到冷启动，这为总执行时间增加了大约180毫秒的延迟。Dashbird的可观察性功能有助于识别和防止冷启动（图片由作者提供）您可以为任何冷启动配置Slack或电子邮件警报，以查看它们发生的频率。在Dashbird中设置冷启动警报（作者）改善Lambda函数延迟的技术您可以通过适当利用上下文重用来减少无服务器函数的延迟。AWS冻结并存储Lambda的执行上下文，即在函数处理程序之外发生的所有事情。如果在相同的15分钟内执行了另一个功能，则可以重新使用冻结的环境。这意味着如果您执行耗时的操作（例如连接到Lambda处理程序之外的关系数据库），您可以获得明显更好的性能。本文非常详细地解释了该主题。有很多优秀的文章讨论如何缓解甚至完全消除冷启动问题，比如这篇和这篇。Dashbird开源了一个名为xlambda的Python库，它使基于Python的Lambda函数保持温暖。同样，JeremyDale也为JavaScript开源了一个类似的Lambda加热器包。最后，无服务器框架还包括提供相同功能的插件。您的工作负载可以接受多少延迟？最后，问问自己，对于您的用例来说，什么延迟是可以接受的。当谈到冷启动导致的延迟时，我们通常以毫秒为单位进行争论。在我作为数据工程师（也构建后端API）的工作中遇到的所有用例中，日常业务中的延迟并不明显。最后，AWS的无服务器Kubernetes服务（在Fargate上也称为EKS）等平台允许您在单个Kubernetes集群中混合无服务器和非无服务器数据层。这种混合使您能够在非无服务器EC2数据层上运行任务关键型、低延迟的工作负载，而其他工作负载（例如批处理）可以由无服务器数据层处理，从而实现两全??其美。最棒的表演。您可以在这篇文章中找到更多相关信息。无服务器是关于“无操作”和可扩展性无服务器允许您专注于您的业务，因为云提供商为您处理IT操作，例如配置和扩展计算集群、安装安全补丁和升级，以及解决硬件崩溃和内存问题。这将使您有更多时间为最终客户提供服务。更好地为我们的客户服务不是最终目的吗？无服务器背后的自动化节省了高技能工程师的时间，因此他们可以专注于解决业务问题而不是管理集群。它允许将IT运营卸载给AWS的DevOps专家，这些专家可能比地球上任何其他公司都拥有更多的计算管理知识。从无服务器中受益匪浅的案例想象一下，您刚刚成立了一家初创公司。最初，您可能不需要很多资源，而且您可能只有一名开发人员。无服务器模型允许您使用即用即付模型自动开始小规模和扩展资源。同样，另一个可以从无服务器中受益的群体是可能没有大型IT部门的小型企业。只需一名专门的DevOps工程师（而不是整个DevOps团队）就可以管理整个应用程序生命周期，这是无服务器的巨大优势。如果您的工作负载自然是季节性的，无服务器也是一个不错的选择。例如，如果您经营电子商务业务，您可能会在黑色星期五和圣诞节前后经历季节性高峰。在这种情况下，无服务器基础架构允许您相应地调整工作负载。此外，某些事件无法预测。想象一下，您一直在网上商店销售洗手液、消毒剂、口罩和类似商品。然后发生了全球大流行，现在每个人都需要你的产品。无服务器基础架构可以在任何情况下为您提供任何规模的扩展。CodeSpeedvsDevelopmentCycleSpeed除了代码执行速度，我们还应该考虑开发速度。在许多情况下，无服务器微服务模式可以加快开发周期，因为根据设计，它鼓励使用更小的单个组件，并允许您独立部署每个服务。如果serverless允许您快速将应用程序的第一个版本交付给利益相关者并在开发周期中加速迭代（同时降低成本），那么由于偶尔的冷启动而增加的几毫秒延迟似乎是一个小问题。与其他云服务的无缝集成以AWS为例，每个无服务器服务都集成了用于日志记录的CloudWatch，用于管理访问权限的IAM，以及用于收集指标和跟踪的CloudTrail等。除此之外，无服务器平台通常为您提供基本构建块来构建更大的、解耦的微服务架构，例如无服务器消息队列(SQS)、无服务器发布-订阅消息总线(SNS)、无服务器NoSQL数据存储(DynamoDB)和对象存储(S3)集成。YouTube视频中没有考虑到Serverless的缺点还有一些视频中没有提到的缺点，我想列出来是为了在不加任何糖衣的情况下给你一个完整的画面。尽管无服务器在许多用例的成本、可扩展性和维护方面看起来像是天堂，但它并不是每个用例的灵丹妙药。供应商锁定的风险：云提供商已经使他们的服务使用起来非常方便且具有成本效益，以至于您自然会冒着被锁定在他们特定平台上的风险。在某些方面，与自托管资源相比，无服务器资源使您对计算资源的控制更少。例如，您无法通过SSH进入底层计算实例以手动执行某些配置，并且您在实例类型方面的自由度较低。例如，您不能在具有GPU的计算实例上运行无服务器函数或容器（目前）。如果您有一些特定的合规性要求阻止您在云中的共享租户上处理数据，那么无服务器可能不是您的选择。虽然将您的IT基础架构拆分为独立的微服务有助于管理依赖关系并加快发布周期，但它也给管理单个服务带来了挑战。虽然Dashbird等监控解决方案在很大程度上解决了这个特定问题，但您也需要了解这些问题。无服务器批评总结一般来说，当我们在构建自托管本地技术时尝试使用无服务器或云服务等新范例时，我们经常会遇到问题。这根本不是使用它的最佳方式。将工作负载迁移到云端时，您会失去云服务的许多优势，甚至会因直接迁移而误解其用途。没有万能的解决方案，因为我们不能指望任何技术在所有用例中都是世界上最快的，并且没有任何缺点（例如偶尔的冷启动）几乎没有额外的成本。在我看来，在谈论无服务器（坦率地说，任何与IT相关的事物）时，我们不应该只考虑一个方面而不检查其他关键方面，尤其是那些在各自技术的设计中必不可少的方面。重要方面。从这个意义上说，无服务器确实有存在的理由，前提是您知道何时以及如何使用它。
