云架构俭约之道七法则（The Frugal Architect）

授权声明：本篇文章授权活动官方亚马逊云科技文章转发、改写权，包括不限于在 亚马逊云科技开发者社区, 知乎，自媒体平台，第三方开发者媒体等亚马逊云科技官方渠道

文章目录

一、前言

在今年 2023 亚马逊云科技的 re:Invent 大会中 Amazon.com 副总裁兼首席技术官 Werner Vogels 博士在主题演讲中，介绍了 The Frugal Architect（云架构俭约之道）这一架构设计法则理念。讲真的，当时并没有怎么上心点开这个视频，当看到这一部分的时候，突然一激灵，这一部分是我需要的，因为在过去的案例中深有感触，你的设计好坏，会影响很大的一部分成本，依稀还记得一个多服务的系统，在预估的时候，成本中心算下来要一千万花费，当时最头疼是客户显然很难接受，另外一个问题是我如何能够降低这个成本，完成最终的架构实施。

2004年Werner Vogels 加入亚马逊担任系统研究总监，2005年1月被任命为CTO和副总裁至今。

今年是Werner Vogels 第十二次在 re:lnvent 大会进行主讲。

Werner 凭借 20 年经验为技术专业提供了架构设计、衡量和优化方面的实用建议。他强调了技术领域的快速变化，呼吁持续学习。俭约不单指金钱，更关乎资源节约。科技进步和人工智能模型的更新带来了巨大的资源消耗挑战，必须引起高度重视。他认为成本是可持续性的近似衡量，这一点一直是他关注的焦点，也应成为大家的关注点。

Werner博士以荷兰文件传输服务公司 WeTransfer 的案例作为例证，该公司通过采用亚马逊云科技，成功降低了 2022 年服务器使用中的碳排放，减少了

78%

。这一改变源自他会上分享的七项黄金法则。

《The Frugal Architect》只有七页，每一页都突显了 Werner Vogels 想要强调的一项法则。这本书为架构师和开发者提供了关于架构设计、评估和优化的规范准则，形成了一份重要的教程。

在全球企业普遍强调“降本增效”的大环境下，《The Frugal Architect》的理念更显得及时。

关于 Law 与 Rule 的区别

注意：规则是人定的，但是他并不是死的硬性的规则，并且在 The Frugal Architect（云架构俭约之道）中这些规则被称为 Law（法则） 而不是 Rule。

关于 Law 与 Rule 的区别，我觉得这里有必要提一下：

• Law是万世不易四海皆准的真理，是天之律法；在中国古代那就是「经」。
• Rule是人类制定的规则，是可以变动的，放中国古代那就是「纬」。

相对于 Rule，我们可以发现 Law 更接近本质，对常人（非理论革新者）来讲，Law 无法被推导，它处于理论或思维的原点，而 Rule 则常由一个或多个 Law 推导得出，其存在并非必须，我意思是说，前者只是后者体现出来的「现象」，如果没有 Rule，我们也可以由 Law 直接计算或推导得出，只是麻烦一些而已，但反过来要想由 Rule 得出相应的 Law 则是不可能的！

总之：可以理解为，Rule 是 Law 的现象，Law 是 Rule 的本质。

二、云架构俭约之道七法则

Design（设计方面）

Law 1：把成本作为非功能性需求

非功能性需求指定了可用于评判系统运作的标准，而不是具体的特性或功能。例如可访问性、可用性、可扩展性、安全性、可移植性、可维护性和合规性。经常被忽视的是成本。

公司之所以会失败，是因为他们在业务的各个阶段都没有考虑成本，从设计到开发再到运营，或者因为他们没有正确地衡量成本。数学很简单：如果成本高于收入，你的业务就面临风险。组织也需要将成本和可持续性视为非功能性要求。

通过早期和持续考虑成本影响，系统可以设计得平衡：特性、上市时间和效率。开发可以专注于保持精简高效的代码。而运营可以微调资源使用和支出，以最大化盈利能力。

核心要点：在设计架构的每一步都考虑成本因素

Law 2：可持续性系统需要将成本与业务相匹配

系统的可持续性取决于其成本与业务模式的良好匹配程度。在设计和构建系统时，我们必须考虑收入来源和利润点。重要的是找到你将从中获利的维度，然后确保架构符合这个盈利模式。

例如，在电子商务中，这个维度可能是订单数量。当订单增加时，基础设施和运营成本也会上升。这是可以接受的，因为如果你的系统架构良好，你就可以开始利用规模经济。重要的是基础设施成本对业务产生可衡量的影响。

作为建造者，我们需要思考收入，并利用这些知识来指导我们的选择。因为不顾一切成长会导致一连串的破坏，甚至是损失。

核心要点：偿还你的架构债

Law 3：架构设计是一系列权衡的取舍

在架构设计中，每个决策都伴随着权衡取舍。成本、弹性和性能是经常相互冲突的非功能性需求。

俗话说，“万物皆有可能失败。” 能够抵御失败意味着投资于弹性，但性能可能会付出代价。

找到技术和业务需求之间的合适平衡至关重要——找到符合风险承受能力和预算的最佳点。记住，节俭是关于最大化价值，而不仅仅是降低支出。为此，你需要确定愿意为什么付费。

核心要点：确立你的优先级

Measure（评估方面）

Law 4：未被观察的系统导致未知的成本

Werner 博士分享了一个阿姆斯特丹老房子的例子，将电表放在走廊上比藏在地下室的房子会使用更少的能源，其原因在于他们每天都可以看到能源消耗。

如果没有仔细的观察和测量，操作系统的真实成本将保持不可见。就像藏在地下室的公用事业计量器一样，缺乏可见性会导致浪费习惯。使计量器更加可见可以深刻地改变行为。

尽管观察需要投资，但不实施足够的监控是短视的。谚语警告说，“如果不能衡量它，就不能管理它。” 跟踪利用率、支出、错误等等对于成本管理至关重要。

当关键的成本指标置于工程师和他们的业务伙伴的核心位置时，更可持续的实践会自然而然地出现。持续的检查让你能够发现过度支出，并调整运营以削减开支。在可观测性方面的投资回报通常远远超过了开支。

最重要的是，将成本置于前沿可以鼓励可持续的实践。

核心要点：定义你的衡量单位

Law 5：依托成本感知架构实现成本控制

精简架构的本质是强大的监控与优化成本的能力相结合。良好设计的系统使你能够针对改进机会采取行动。为了实现这一目标，将应用程序分解为可调整的构建模块。

一种常见的方法是按重要性对组件进行分层。一级组件是至关重要的；无论成本如何都要进行优化。二级组件也很重要，但可以在不造成重大影响的情况下暂时降低规模。三级组件是“好有但不必须”的；让它们成本低廉且易于控制。

定义层级可以在成本和其他要求之间进行权衡。对组件的细粒度控制既优化了成本，又优化了用户体验。基础设施、编程语言、数据库都应该是可调整的。在架构和构建系统时要考虑收入和利润。成本优化必须是可衡量的，并与业务影响相关联。

核心要点：建立层级

Optimize（优化方面）

Law 6：成本优化是循序渐进的

成本效率的追求是一个持续的过程。即使在部署后，我们也必须重新审视系统，逐步改进优化。关键是不断质疑并深入探究。编程语言提供了性能分析工具来分析代码性能，虽然这些工具需要设置和专业知识，但它们能够进行细粒度的分析，从而导致可以减少毫秒级时间的变化。看似微小的优化在规模上积累起来会带来巨大的节省。

在运营中，大部分时间都花在运行现有系统上。有机会对资源使用进行分析，找出浪费并进行减少。在亚马逊，我们持续监控生产中的服务，以了解模式并修剪低效。节俭需要坚持不懈——通过逐步降低延迟和基础设施成本，我们可以优化提供服务的成本。

总是存在改进的空间……只要我们不断寻找。今天我们获得的节约为明天的创新提供了资金。

核心要点：持续优化

Law 7：未经挑战的成功导致假设

当软件团队在没有遇到重大失败或障碍的情况下取得重大成功时，就可能产生自满情绪。人们很容易过分自信于导致这些成功的方法、工具和实践。

软件团队经常陷入一种陷阱，就是假设他们当前的技术、架构或语言将永远是最佳选择，仅仅因为它们过去曾有效。这可能导致一种虚假的安全感，使人不愿质疑现状或探索可能更有效、更具成本效益或可扩展性的新选择。

在选择编程语言时经常会出现这种情况。“我们一直使用Java。”是我经常听到的一句话，它可能会扼杀创新。未经挑战的成功通过假设滋生了自满。我们必须始终寻求质疑、优化和改进的方法。

正如 Grace Hopper 所说，英语中最危险的短语之一是：“我们过去总是这样做。”

核心要点：证伪你曾相信的事情

三、个人反思

首先，看到像亚马逊这样庞大的公司的首席技术官在主题演讲中花了大量时间关注成本，这令人耳目一新（也令人惊讶）。随着公司努力在预算不断减少的情况下推动成功的产品创新，成本优化变得越来越重要，而上述一套可靠的原则将作为应对这些挑战的有用指南。

就我最同意的观点而言，最初的观点可能是最强烈的。在开发新产品时，成本不再处于次要地位。当你稍后考虑成本时，为时已晚，并且很难恢复早期未考虑成本的设计决策。我发现这在我们建设新管道的设计讨论中更多地被考虑在内，总的来说，人们似乎越来越关注成本，这是一件好事。

正确的架构都是关于权衡的，成本肯定会在决策中发挥作用。正确实施成本控制（第五法则）使这个过程变得更加简单。你的哪些组件是绝对不会出现故障的，哪些部分运行时间稍慢或偶尔出现故障是可以容忍的？了解这一点可以让你做出更好的成本驱动决策，例如使用按需实例与 Spot 实例、更容易出错的实例类型等。

适当的监控也很关键。虽然人们会从应用程序日志的角度考虑这一点，但不要忘记成本！正确标记所有资源并设置仪表板，并内置异常检测，以跟踪一段时间内的成本。 亚马逊云科技整合了计费和成本管理控制台，这使得你可以更轻松地在一个地方找到所需的一切。

成本优化是一个渐进的过程。虽然你总是想在一开始就考虑这一点，但障碍和挑战将会出现并迫使你转变方向。重要的是要牢记成本并继续将其作为决策过程的一部分。

最后但并非最不重要的一点是，质疑一切。良好的公司文化的标志是不仅允许而且鼓励这样做。你永远不知道什么时候你会发现事先没有考虑到的差距。

最后总结一下，Werner Vogels 在今年的 re:Invent 大会上分享了《The Frugal Architect》的架构设计法则。这些法则涵盖了关于成本、系统可持续性、权衡取舍、观察系统和成本优化的重要原则。他特别强调了将成本视为非功能性需求的重要性，以及对成本敏感的架构设计在实现成本控制方面的价值。而他的七项黄金法则不仅提供了技术层面的指导，更是对于技术人员应持续学习和不断优化的呼吁。这些法则不仅适用于技术架构，更关乎如何在一个不断变化的科技环境中保持敏锐和持续进步。