图片由Kumpan Electric拍摄，来自Unsplash

除非你最近一直生活在岩洞里不出来，整个无服务器领域因连亚马逊也似乎决定转向非无服务器架构而震动。

让我们深呼吸，试着理解事情本身的样子，而不是别人希望它们成为的样子。长话短说，一个多月前，亚马逊Prime团队发布了一篇颇具争议性的文章，题目为"将Prime Video音视频监控服务扩展并降低成本90%"，他们表示为了符合某些具有挑战性的要求，不得不转向单体式架构。我们即将在接下来的几行中深入探讨这篇文章，但先停留在标题这里，假装我们已经有了一个初步的理解。

这篇文章几乎被忽视了五周，直到著名的反云技术批评家DHH写了一篇情书式的文章，ChatGPT可以概括为“我说得没错”。我不知道贝索斯的狗是否真的咬过大卫的手，还是这个身份就足以让他心生怨恨。说实话，我本来期望像他这样的高水平专业人士能给出更平衡和更深入的分析，而不是仅仅对云技术大肆抨击。

不幸的是，DHH 持有非常坚定的看法，他远离了云，特别是在 Basecamp 方面。我不清楚他的具体理由，但他的公开论点至少看来是站不住脚的。首先，他写了一篇文章，详细阐述了与脱离云服务有关的成本节省，提到了包括房租、人工和维护在内的成本。

最近，他通过这种对无服务器的天真看法提高了他对过度自信的门槛，紧接着他发表了类似的批评意见，目标是微服务。让我们更深入地探讨，分析一下亚马逊团队的解释。

如果我们仔细阅读这篇文章，就可以勾勒出几个值得提及的关键点，适用于他们的案例。

“我们在Prime Video的视频质量分析（VQA）团队已经有了一个用于音频/视频质量检测的工具，但我们从未打算也没有设计让它在大规模环境下运行（我们的目标是监控数千个并发流，并随着时间的推移增加这个数字）。在增加更多流进入服务的过程中，我们发现大规模运行这样的基础架构非常昂贵。我们也遇到了扩展瓶颈，这让我们无法监控数千个流。”

这很清楚：他们本来设计是用来处理几个流媒体的，结果却用来实时处理数千个流媒体。

我们最初的设计是一个使用无服务器组件（例如，AWS Step Functions 或 AWS Lambda）的分布式系统，这确实是一个快速构建服务的好方法。理论上，这将使我们能够独立扩展每个服务组件。然而，我们使用某些组件的方式导致我们在大约达到预期负载5%时碰到了硬扩展限制。此外，所有这些构建块的总成本过高，使得在大规模应用时难以接受该方案。

这部分相当具有挑战性：服务编排是一个问题。这合情合理，因为服务编排不可避免地会引入摩擦，而规模化的编排意味着你的系统需要扩展以维持系统中最快部分的吞吐量水平。此外，另一个相关方面也显现出来：所有提到的功能都属于同一个业务领域。这是应用程序的一个基本方面：团队将架构分解为一个包含多个组件的分布式系统，以实现快速迭代，在开发过程中实现快速迭代，这可能是因为需求不够明确，导致了多次返工。这是一个明智的选择，但当应用程序功能稳定且需要确保高可扩展性和实时响应时，这一选择就需要调整了。

咱们需要找出他们在响应时间上的限制，以及是否可以放宽一些限制，转而使用异步编排而不是StepFunction编排，从而避免StepFunction状态转换带来的成本。

我们发现的第二个成本问题是关于我们在不同组件之间传递视频帧（图像）的方式。为了减少视频转换任务的高昂计算成本，我们建立了一个微服务，将视频拆分成帧并暂时将图像上传到_Amazon Simple Storage Service (Amazon S3)_桶中。每个缺陷检测微服务都是一个单独运行的微服务，然后下载图像，并使用 AWS Lambda 并行处理这些图像。然而，对 S3 桶的大量 Tier-1 调用费用非常高。

在这里我们需要获取有关阻止团队将视频帧保存到类似EFS的存储中的要求的信息，然后将这些视频帧拉入Lambda执行环境。如果是我的话，我会考虑这种方法，因为S3非常适合存储数据，但在访问次数增加时会变得非常昂贵。如果你的使用场景允许的话，那么优先选择EFS会更好一些，EFS采用按使用量计费的方式，而不是基于请求数量。

微服务因其较小的规模和更易于管理而著名。它们可以根据业务需求定制技术栈，从而缩短部署时间并加快开发人员上手速度。此外，微服务允许添加新的组件不影响整个系统；即使一个微服务失败，系统其他部分仍可以继续运行。这种架构以其可演化性或可扩展性著称，可以轻松适应和修改。从简单的结构开始，它可以根据整体愿景逐步增加复杂性。

这并不是一个强制性的要求，而是一系列可以并且应该仔细评估的利益。对于小型初创公司而言，单体应用可能是一个不错的选择，因为它们易于开发和维护。团队可能会选择一种虽然会增加团队间的沟通成本，但显著减轻了团队的认知负担的技术，从而使他们无需操心应用程序的各种细节，从实例管理到数据库扩展，再到基础设施的最佳实践。

微服务和无服务器组件是大规模工作的工具，但是否选择使用它们而不是单体应用，需要根据具体情况来决定。

每个架构师都有几个选择和分析维度，这些可以影响项目的成果，从单体到分布式，或无服务器/虚拟机，从使用单一语言到使用最适合的工具。在我的职业生涯中，我见过开发人员因为只对一种数据库有信心而反复使用相同的数据库，而不是探索其他可能的选择，也见过团队每三个月就会更换一次语言或框架来保持最新。所有这些观点都是错误的，因为它们忽视了成果的商业价值，也没有考虑到架构师需要面对的各种限制。

这就是我不太认同DHH的“远离云”信仰的原因，不是因为我钟情于无服务器（我认为它更多是构建事件驱动架构的一种手段），而是因为它过于绝对，就像有人在高喊你必须把所有东西都无服务器化一样。

我们应该明白，只有西斯才谈论绝对。