亚马逊CTO的架构之道-俭约架构师的成本优先架构原则

 以下是亚马逊CTO（Werner Vogels）在演讲当中总结他20年的架构经验时提到的一些架构设计原则

原文视频地址，参见：AWS re:Invent 2023 - Keynote with Dr. Werner Vogels

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

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

　　“在我们设计的时候，成本是非功能方面的要求，跟安全、合规、可用性、性能这些最经典元素一样，你必须记在心里面，时刻把它体现出来。毕竟我们不仅仅是为了打造技术而打造技术，我们打造这个技术是为了支持业务运营需求的。”

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

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

 

法则二：确保系统的最终成本与业务保持一致

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

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

　　作为架构师，大家需要关注收入，并据此指导技术选型。任何不计代价的增长只会招致毁灭。正如Werner强调的：“你要很确定，我们业务基础设施扩展的方式，能让成本成长低于销售收入的增长。”

 

法则三：架构设计是一系列权衡的集合

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

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

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

　　Werner还在这个环节指出，创新设计时需要平衡成本、安全性还有洞察力/内情这三样东西，“Amazon Lambda就是在这样的过程中一边探索一边打造出来的。我们在做设计时，始终要保持三个方面的关系，有时候你可能需要在成本方面做一些牺牲，来达到其他的技术或者安全的要求。再往上，我们一定要建一个演化的基础结构，我们要确定我们做事情不能影响到客户，这也是Lambda成功的关键。”

 

法则四：无法观测的系统将带来无法估量的成本

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

　　Werner用建筑举了个例子，“上面两个房子是一模一样的，其中一个房子使用的能源量比另外一个房子少了1/3。为什么呢?关键在于其中一个装了测量器，会自动调整冷暖气。”

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

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

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

 

法则五：依托成本感知架构实现成本控制

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

　　也就是说，不同的组件一定要有相应的工具来掌控，来操纵这些内容的程式，同时来调试它的矩阵和性能，要能做到随时随地想打开哪些组件就能打开它们，想关上的时候也能及时关上。这个开关必须要置于业务运营的关键环节上，保障你能够轻松控制业务的运营。

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

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

 

法则六：成本优化是个渐进的过程

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

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

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

 

法则七：没经历过挫折会让人盲目自信

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

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

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

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