应用程序的无服务器：日常生活中的架构

[无服务器0的爱情故事通常以第一份意外成本报告或第一个无人能诊断的事件结束。正是在日常的基础上，系统在生产中运行，人们依赖它，该方法才显露出其真正的特征。

启动 [无服务器1 很容易。无服务器运营是教程中没有人提到的难点所在。当您需要了解、监控正在运行的内容并为其付费时，使该技术具有吸引力的相同属性、短暂执行、自动可扩展性、按使用收费等都成为具体的挑战。

本文就是关于那个阶段的。不是关于概念或实施，而是关于一切都悬而未决之后会发生什么，而让船保持漂浮的责任是你的。可观察性、成本和运营：这些主题将那些玩无服务器的人与那些真正运营无服务器的人区分开来。

生产冲击

在开发过程中，一切似乎都在掌控之中。您测试一个功能，它做出响应，您就可以跟随。在生产中，随着实际流量的增加，您以前从未见过的行为开始出现。

在某些时候，函数执行的时间比预期的要长。错误会在不可预见的点出现。每月费用与估算不同。当您尝试理解原因时，您会发现自己没有足够的可见性来回答。

这就是[无服务器3]生产带来的冲击。分布在数十个短暂执行中的系统本质上是很难看到的。你看不到的东西，你就无法控制。

我的立场是，[无服务器4] 不会消除运营工作，它会改变运营工作，并在某些方面强化它。

你不再关心服务器了，这是真的。但它承担了运行一个更广泛、更动态、更难以观察的系统的责任。工作并没有消失。它改变了它的性质。

任何采用无服务器并认为操作会很简单的人都会感到失望。操作是不同的，掌握它需要在三个经常被忽视的方面进行投资：[可观察性5]、成本控制和持续监控纪律。

在传统应用程序中，您可以登录服务器并进行调查。在[serverless6]上，没有可加入的服务器。函数诞生又消亡。当出现问题时，故障环境就不再存在。

因此，【可观察性7在 Serverless 中并不是奢侈品，它是理解系统的唯一途径。这意味着从一开始就需要做好三件事。

结构化日志，以可搜索的方式记录每个函数执行的操作。指标，显示一段时间内的执行模式、持续时间、错误和使用情况。分布式跟踪，让您可以跟踪跨多个功能和服务的请求。

如果没有这三层，调试生产中的问题就变成了猜测。有了它们，您可以回答操作中最重要的问题：我的系统内现在发生了什么？

按使用付费模式被视为一种优势，而且事实往往如此。但在日常生活中，他却隐藏着一个陷阱。当成本与使用量成正比时，错误可能会实时损失真金白银。

不正确循环中的函数、触发级联的事件、恶意流量的峰值，所有这些都成为发票。而且由于 [无服务器 8] 会自动扩展，因此它可以像扩展成功一样有效地扩展问题。

负责任地运营[无服务器9]需要密切监控成本。设置异常支出警报。了解哪些功能消耗最多。在有意义的地方设置限制。月底不能是你发现某些事情已经失控的时刻。

对于公共组织来说，这一点更加敏感：可预测的预算很重要，而毫无预警地上涨的云账单是一个管理问题，而不仅仅是一个技术问题。成本需要像任何其他系统健康指标一样进行监控。

更新数十个独立功能需要流程。如果没有自动化和版本控制，您将失去对运行位置的控制。健康的运营惯例将每一次变化视为可追溯和可逆的。

在一个广泛应用的系统中，故障很少会导致一切崩溃。相反，当其他部分出现故障时，其他部分也会随之发生故障。良好的运营意味着针对部分故障进行设计：自动重试、保存无法处理的内容的队列，以及明确部件掉落时应采取的措施。

每个 [无服务器10] 平台都对同时执行、持续时间和大小有限制。在日常生活中，这些限制可能会让你在高峰时感到惊讶。了解他们并监控你与他们的距离是成熟运营的一部分。

想象一个处理公民对市政服务请求的[无服务器11]系统。一切都很顺利，直到截止日期那天，数量猛增。

如果没有[可观察性12]，团队只会看到缓慢的抱怨而不知道原因。通过可观察性，它会发现特定功能正在面临竞争限制，并且成本随着流量而上升。

成熟的运营会根据信息采取行动：调整限制，识别瓶颈，并在第二天审查峰值成本以了解是否值得。如果没有这种能见度，就很难在黑暗中扑灭火灾。正是这种差异定义了运营成熟度。

Serverless 会奖励那些认真操作它的人，并惩罚那些在推出后忽视它的人。该技术提供了灵活性并节省了成本，但需要持续关注[可观察性13]和成本。

我的教训很简单。启动只是开始，而不是结束。系统存在于日常生活中，正是在那里我们发现架构是一个好的决定还是一个未实现的承诺。

对于那些了解技术和财务账单每天都会收到的人来说，无服务器会大放异彩，而不仅仅是在发布时。

如果您在生产环境中使用[无服务器14]并且觉得自己缺乏可见性或成本控制，那么值得与他交谈。我在博客上还有其他关于无服务器概念、用例和实现的文章，这些文章从头到尾完成了这一旅程。