亚马逊 CTO 20 年架构经验之道：俭约架构师的七大黄金法则！

亚马逊 CTO Werner Vogels 向企业传达了一条信息：在管理云成本方面，是时候成为节俭的架构师了。

他拥有近 20 年的平台构建经验，在今天的 re:Invent 2023 大会主题演讲中，给大家上了一节关于成本优化的课：“作为技术专家，我们生活在一个瞬息万变的世界，我们需要保持学习，坐下来，拿出你的记事本，现在开始做笔记。”

Vogels 选择在主题演讲中讨论成本问题，这既反映了当前的经济环境，也反映了云计算支出的不断增长的态势。本月早些时候，Gartner 公司发布预测，到 2024 年云用户支出将达到 6780 亿美元，比今年的 5630 亿美元大幅增长。

亚马逊云科技在引领公有云市场方面取得了巨大成功，但同时也意识到，这个行业所带来的成本压力正在随着生成式 AI 等技术的广泛采用而不断增加。

“在构建这些系统、在有限制的环境中生活中蕴含了很多艺术，”Vogels 表示。“云计算消除了所有这些限制。突然间，最重要的事情就是迅速行动，推出产品。随着执行速度变得更为重要，我们失去了关注成本、以成本为重要考量的架构设计的艺术。作为构建者，我们确实需要开始思考这一点。”

Vogels 概述了成为“俭约架构师”（The Frugal Architect）的七条关键法则，这是一组他自己描述的“法则”，已发布在一个专门致力于此主题的新网站上。其中包括创建将成本与业务对齐的系统，观察基础设施中的关键运营网络以避免未知的费用，并追求渐进式优化。

“我尝试向初创公司强调这一点，” Vogels 说。“你将要采用什么收入模式？他们需要构建符合这一模式的架构。确保你获取收入的维度始终与你的成本保持一致。”

附完整的“俭约架构师的七大黄金法则”：

架构师如何培养自己的成本意识、增强现代架构可持续性。

法则一

将成本视为一种非功能性需求。

所谓非功能性需求，就是用于判断系统操作的标准，与具体特性或功能无关。可访问性、可用性、可扩展性、安全性、可移植性、可维护性和合规性等都在此列。而成本往往是其中受到忽略的一条。

业务之所以身陷困境，往往是因为他们没有考虑到各个阶段中的相应成本——从设计到开发、再到运营——也可能是未能正确量化成本。这背后的原理非常简单：如果成本比收入还高，那还做业务干嘛呢。

更早、以更加可持续的方式考虑成本影响，架构师才能在系统设计过程中在功能、上市时间和效率之间寻求平衡。这样开发团队可以专注于维护更加精简高效的代码，运营部门可以优化资源用量和支出，从而最大限度提高盈利能力。

法则二

确保系统的最终成本与业务保持一致。

系统能否长治久安，取决于其成本是否与业务模式高度匹配。在设计和构建系统时，架构师必须考虑收入来源和利润杠杆。更重要的是，必须找到能够产生利润的维度，确保架构规划始终围绕收益展开。

例如，在电子商务领域，这个核心维度可能是订单数量。当订单增加时，基础设施和运营成本也会随之上升。但没关系，只要系统架构设计良好，我们就能享受规模经济带来的红利。最重要的是基础设施成本对业务的影响始终精确、可以量化。

作为架构师，大家需要关注收入，并据此指导技术选型。任何不计代价的增长只会招致毁灭。

法则三

架构设计是一系列权衡的集合。

在架构当中，每项决定都涉及相应的权衡。成本、弹性和性能这些非功能性需求之间，往往相互冲突、难以调和。

常言道“万事万物终将陨落。”要想抵御这种失败的风险，就必须关注弹性，同时牺牲掉一部分性能。

在技术与业务需求间找到适当的平衡将至关重要，也就是把握住风险承受能力与预算额度间的最佳比例。请记住，节俭是为了最大限度提升价值，而不只是尽可能控制支出。因此，在必须得花的钱上别吝啬。

法则四

无法观察的系统将带来无法估量的成本。

如果不认真观察和测量，系统运营的真实成本将难以把控。就如同隐藏在地下室中的电表一样，这种直观性的缺失必然导致浪费。所以一定要把指标摆在明面上，这将深刻改变运营行为。

尽管实现可观察性需要投入，但这笔钱绝对会物有所值。有句格言说“如果无法量化，也就无法管理。”请始终坚持对利用率、支出、错误等至关重要的成本管理指标保持关注。

当工程师和业务合作伙伴能够随时查看关键成本指标时，自然就会催生出更具可持续性的实践策略。持续检查能帮我们发现非必要支出，并调整运营以减少浪费。总之，可观察性带来的回报往往远超过前期投入。

最重要的是，这本身也是对成本的强调，能在企业中塑造出鼓励可持续性实践的文化。

法则五

依托成本感知架构实现成本控制。

节俭架构的本质，在于强大监控与成本优化能力的结合。精心设计的系统能帮助大家抓住改进的机会。为此，请将应用程序拆分成一系列可以调节的构建块。

一种常见的方法就是按重要性对组件进行分层。T1 层组件必不可少，应当不计成本进行优化；T2 层组件非常重要，但暂时缩小规模也不会产生重大影响；T3 层组件则属于“锦上添花”，要保证其成本低廉且易于控制。

明确定义各层，即可在成本及其他要求之间求得平衡。对组件的精细控制则能优化成本和体验。基础设施、语言、数据库都应具备可调节性，并在系统的设计和构建阶段考虑收入和利润。总之，成本优化必须可量化，且与业务影响直接挂钩。

法则六

成本优化是个渐进的过程。

追求成本效率是个持续的过程。即使在部署之后，我们也必须随时审视系统以逐步寻求优化。其中的关键在于不断提问、深入研究。编程语言往往提供分析工具以追踪代码性能，虽然这需要额外的精力和专业知识，但精细的调优足以带来几毫秒的差异。而这种看似微小的优化，累积起来足以产生超出想象的成本优势。

在运营中，大部分时间都被用于运行现有系统。所以请把握一切机会，分析资源使用情况并减少浪费。在亚马逊，我们持续监控生产中的服务，发现运营模式并消除低效因素。节俭是坚持的结果——通过逐步降低延迟和基础设施成本，服务成本才能最终得到优化。

只要不懈努力，我们总能找到改进空间。而今天省下的资源，就是明天创新的燃料。

法则七

顺风局打多了会让人盲目自信。

如果软件团队在取得重大成功的过程中，从未经历过任何严重失败或者阻碍，则往往会出现自满情绪。这是一种危险的倾向，会导致团队成员对原本的方法、工具和实践变得盲目信息。

软件团队经常陷入这样的陷阱：仅凭以往的工作经验，他们就认为当前的技术、架构或语言永远是最佳选择。这可能会产生一种错误的安全感，阻碍对现状的质疑，更会打击对可能更加高效、更具成本效益或可扩展性更强的新选项的探索。

说到编程语言，人们往往会说“我们是一家 Java 公司”。这话大有问题，其底层逻辑无疑是在扼杀创新。唾手可得的成功会滋生自满情绪，而只有质疑才能不断激发新的优化与改进思路。

Grace Hopper 的名言，准确反映了这一值得高度警惕的陷阱：“我们一直都是这样做的。”