荒凉开云体育，简直荒凉。

一场近 2 小时的举止，CTO 尽然全程莫得发布任何新品！

这便是亚马逊云科技的 CTO ——Werner Vogels，刚刚在自家年度盛宴re:Invent24演出的一幕。

但有一说一，即便如斯，诺大的现场，险些无东谈主离席。

为什么？

因为比起新址品，Werner 终点于是把他入职亚马逊20 年背后更珍稀的履历给公开出来了。

而且剑指生成式 AI，统统六大 Lesson：

Lesson1：有恃毋恐Make evolvability a requirement.

Lesson2：化繁为简Break complexity into pieces.

Lesson3：各司其职Align organization to architecture.

Lesson4：小而空洞Organize into cells.

Lesson5：料敌如神Design predictable systems.

Lesson6：机器代劳Automate complexity.

之是以会如斯，是因为在 Werner 看来，当今无论是数据还是大模子的参数限制都在呈现指数级的增长，濒临越发复杂和普遍的系统，行业亟需一个措施论。

而这个措施论，简而言之，便是把 Complexity（复杂性）变为Simplexity（浅近性）。

这又该如何贯通？

Werner 举了一个相等形象的例子——自行车。

他以为系统的组件数目并不可平直算计其复杂性。举例：

独轮车（Unicycle）：唯有最少的组件，看起来很浅近，但推行操作却相等繁难，需要很高的时期和悉力。

三轮车（Tricycle）：组件稍多，踏实性更强，但在活泼性方面受到扫尾，比如转弯不够便捷。

平淡自行车（Bicycle）：组件数目介于两者之间，却提供了最好的均衡点，既活泼又易于掌持。

平淡自行车固然比独轮车和三轮车有更多的组件，但其联想达到了功能和体验的最好均衡，因此也让它成为了当今最浅近易用的交通器具。

一言蔽之，浅近性不单是是减少组件，而是系统合座体验的优化。

Werner 今天建议的这套措施论，恰是把亚马逊云科技多年来在实践中"踩过坑"后回来而来。

是以，正如那句"还要啥自行车"，亚马逊云科技都帮咱们整理完结，飞速来看下吧 ~

Lesson1：有恃毋恐，系统可演化是必要

Make evolvability a requirement — Evolvability is a precondition for managing complexity.

将可演化性动作一项要求，可演化性是搪塞复杂性的一种预判

来源第一课，Werner Vogels 建议，可进化性是必须的，这是进行复杂管制的先决条件。

什么预见？

跟着时候推移，系统是一定会发生变化的。因此在联想之初，就要确保架构能够放纵合乎新的需求。

而且进化才智不同于可调治性，前者是永远的、粗粒度的功能或结构增强，尔后者是短期的、细粒度的局部变化。

否则就会像温水煮青蛙一样，等意志到问题时，无意就太晚了。

在系统联想初期时，就应该作念好前期商量、管制系统复杂性。

最平直的例子便是Amazon S3的发展。

领先，S3 的联想蓄意是提供一个浅近、耐用且具有资本效益的云存储劳动。

其后跟着客户数目以及劳动量增多，S3 不得不雠校当时期和架构。比如从单引擎系统升级为营救多个微劳动和漫衍式存储的架构。

推行上，每一年 S3 都会增多新功能，但从不影响现存劳动的踏实性。好比给高速运转的引擎加部件。

这收成于其在系统联想时就推敲到了往时的升级需求，联想了活泼、可膨胀的架构，以搪塞未知的挑战，因此才可以在往时逐渐膨胀才智。

这种可进化性使得它能不断引入新时期、新功能和新进程，以合乎新市集需求，保持竞争力。

不外，跟着系统不断进化，复杂性就会增多。如何限度系统的复杂进度、升迁可调治性，这是 Werner Vogels 讲的第二课。

Lesson2：化繁为简，建议微劳动架构

Break complexity into pieces — Disaggregate into building blocks with high cohesion and well-defined APIs.

将复杂性拆解成多个部分，理解为内聚性高且有明确界说 API 的构建模块。

亚马逊云科技领先接收单体架构，背面跟着业务发展，系统变得越来越复杂，单体架构发扬出了膨胀性差、可调治性低等问题。

是以，亚马逊云科技决定将单体架构拆解为多个安然的微型劳动，即微劳动架构。

每个劳动厚爱一个业务功能，安然部署和调治，并界说浮松的 API 接口以便它们相互通讯。

在微劳动架构差别中，除名单一职责原则，即每个劳动只厚爱一个单一的功能或智能。

增量拆分原则是将通盘系统逐渐拆分红多个较小的部分，然后逐渐迭代进行拆分。

同期还要求一个劳动里面组件之间的耦合度要尽可能低，与其他劳动之间的依赖性尽可能小。这么作念可以升迁劳动的安然性，使得各个劳动可以独随即进行开拓、测试、部署和膨胀。

这种措施不仅减少了系统间的耦合，还让团队能更专注于各自的模块。全系统可以通过组件的不断迭代优化而不竭演进，并在关节时刻平滑过渡，幸免劳动中断。

Lesson3：各司其职，组织和架构对皆

Align organization to architecture — Build small teams, challenge the status quo, and encourage ownership.

让组织与架构相匹配，组建小团队，挑战近况并饱读动主东谈主翁意志。

Werner Vogels 以为，组织构建要和系统架构保持一致。当系统架构被拆分红一个个小模块后，组织也应该如斯。

有多小？一个形象的比喻——粗略两块披萨就能喂饱通盘团队（doge）。

在亚马逊云科技里面，这种机制也被称为"两个披萨团队"。

它能很平允置传统职能档次导致的调换成果低下、决议安宁等问题。

这种措施不仅升迁了团队的活泼性和自主性，还促进了改动和快速反应市集需求的才智。

让每个团队独随即职责和决议，可以进一步加速居品开拓和迭代速率，这亦然亚马逊云科技能够永远保持竞争力和改动力的秘诀之一。

另一方面也要建立浮松的问责机制，营造积极朝上的文化氛围，推进不竭雠校。

Lesson4：小而空洞，一个 team 便是一个细胞

Organize into cells — In a complex system, you must reduce the scope of impact.

组织成单位方式，在复杂系统中必须放松影响界限。

Werner Vogels 还提到了一种里面的组织结构，被称为"细胞化"。

它将应用技艺理解成更小的、安然运行的模块，使每个模块都能安然运行，把问题终止在特定单位内，不影响其他单位。

就像是一个个细胞，它们领有我方里面的功能，并通过细胞膜防碍出一个相对安然的环境。

这在复杂系统中至关遑急，有助于调治系统的踏实性和可靠性。

举例，亚马逊云科技劳动通过散列算法将客户分拨到特定单位，幸免单点故障对整个用户的影响。

天然单位的差别也要大小适中，既要大到能够处理最大的职责量，又要小到可以进行推行推行。

Lesson5：料敌如神，镌汰不笃定性

Design predictable systems — Reduce the impact of uncertainty.

联想可瞻望的系统，镌汰不笃定性的影响。

联想可瞻望系统的中枢蓄意是减少不笃定性对系统的影响，使系统能够在高度复杂的环境中仍然保持踏实和高效。

联想可瞻望系统的几个关节战略是：

浅近笃定

通过保持系统联想的浅近性，能够更容易地瞻望和管制系统的行动。

举例，在负载均衡的处理上，亚马逊云科技接收了一种更浅近的措施，将整个变化推送到一个文献中，然后在固定的轮回中更新负载均衡器的成就。这种措施确保了系统的行动是可瞻望的，而况能够处理整个的成就条件。

不竭职责模式

使用不竭职责模式，从 Amazon S3 中如期拉取文献，幸免积压和瓶颈。这种模式天然具有自我开拓的性情，因为屏幕的可用性极高。

自动化和尺度化

自动化是减少复杂性的关节妙技。通过尺度化操作，可以减少东谈主为干扰所带来的不笃定性和间隙。举例，在健康检查器系统中，如期推送完好的成就文献，而不是每次都推送变化。

漫衍式架构和模块化

联想系统时，应将其理解为安然的模块，每个模块可以安然运行和膨胀。这么可以在某个模块出现问题时，将影响限度在最小界限内。

高可不雅察性

系统应具备高可不雅察性，能够实时监控和分析系统的运事业态。通过这种面貌，可以实时发现和处置潜在的问题。

处理复杂性的战略

通过将复杂的任务理解为浅近、可管制的部分，可以有用地限度和处理系统的复杂性。亚马逊云科技一些劳动接收固定的处理轮回而不是事件驱动架构，从而确保系统的行动可瞻望，镌汰了运行时的复杂性。

Lesson6：机器代劳，升迁成果

Automate complexity — Automate everything that does not require high judgment.

使复杂性自动化，将不需要高度判断力的一切事务自动化。

浅近来说，这便是让机器来帮东谈主处理那些可以浅近判断的任务，把需要创造性和复杂决议的任务留给东谈主类。

这种自动化能更进一步升迁成果。

比如诳骗 AI 来监测坏心举止，并自动反应，保护客户业务免受安全威迫。

自动化不单是是处置常见问题的器具，它应该成为尺度进程的一部分，唯有在处理异常情况时，才需要东谈主工输入。

亚马逊云科技里面通过对营救票进行自动分类和优先排序，有用减少了东谈主工操作，升迁了问题处置速率。

考据六个 Lesson 的价值

Werner 建议的措施论，可以说不仅是亚马逊云科技劳动到手的基石，更是当代漫衍式系统联想的遑急引导。

不外在表面除外，他在现场也展示了经得起六大 Lesson 考据的居品——Amazon Aurora DSQL。

（注：于 re:Invent24 第一天，由 CEO Matt Garmarn 发布，并非 Werner 首发。）

它是一种新式无劳动器漫衍式数据库，为的便是处置传统数据库在膨胀性和性能方面的挑战。

对应 Lesson1，Aurora DSQL 可以说是从联想之初便是为往时的可演化性作念好了准备。

Aurora DSQL 将数据库功能解耦为安然组件，如查询处理器（Query Processor）、和解器（Adjudicator）、日记模块（Journal）和存储引擎（Storage Engine）。

这种联想允许每个模块笔据需要安然升级或替换，而不影响其他部分。

跟着时期的发展，Aurora DSQL 能够通过模块替换快速合乎新需求。举例，日记模块可笔据蒙胧量膨胀，存储引擎可优化数据读取成果，从而营救业务限制的增长。

对应Lesson2，Aurora DSQL 十足除名"化繁为简"的理念，将复杂性理解为多个安然且高内聚的模块。

举例查询处理器专注于事务处理和快照终止、日记模块厚爱事务耐久性和全局排序、存储引擎优化数据的读写性能。

通过明晰的 API 完结低耦合，各模块只需要完成特定的输入输出任务，无需处理全局逻辑。

对应Lesson3，其各模块可以由微型团队安然开拓和调治，这与亚马逊云科技的"两块披萨团队"理念十足一致。

举例查询处理器团队可以专注于事务逻辑优化，而日记模块团队则可以重心处置耐久性问题，各司其职却无缝合营。

对应Lesson4，Aurora DSQL 接收漫衍式架构，将系统功能差别为多个安然单位以扫尾故障影响界限。

举例数据存储被分为多个分片（Shards），每个分片安然运行并处理特定数据，确保某个分片故障不会影响全局劳动。

而事务和解模块（Adjudicator）安然处理毁坏，确保并发事务之间的终止性和一致性，同期减少对中枢数据库存储的影响。

对应Lesson5，Aurora DSQL 处置了漫衍式系统中时候管制的传统难题，通过腹地时钟处理事务的"运行时候"和"提交时候"，摈斥了对复杂漫衍式一致性算法（如 Paxos）的依赖。

同期，存储引擎接收固定的查询和数据处理面貌，幸免了事件驱动架构可能带来的不可瞻望性，使系统性能愈加踏实。

对应Lesson6，Aurora DSQL 日记模块完结了自动化，事务提交后会立即写入日记模块，日记模块自动排序和分发事务，确保耐久性和一致性。

而况其存储和查询模块可以笔据负载动态膨胀，无需东谈主工干扰，升迁了资源诳骗成果。

由此可见，亚马逊云科技此次建议的六个 Lesson，是经过磨砺的那种，更是"值得一抄的功课"。

而亚马逊云科技之是以能到作念如斯，离不开衔接这几天整个 Keynote 的关节词，那就用户需求（Customer Needs）。

正如 CEO Matt Garman 所说的那句话：

Innovation Driven by Customer Needs.

客户需求驱动改动。

不外有一说一，其实许多劳动型企业相同是把客户需求放在第一位，那么亚马逊云科技又有何独到之处呢？

在量子位与亚马逊云科技众人客户时期营救与劳动副总裁Uwem Ukpong交流过程中获得了明确的谜底：

咱们相等擅长精确捕捉客户的需求，会坐下来濒临面刨根问底的进度，可以过任何细节。

而况咱们属于求实派的那种，先作念再说。

One More Thing：

Werner 在亚马逊赴任长达 20 年之久，是众人最着名的 CTO 之一。

而看过近几年 re:Invent 的小伙伴可以发现，他的专场发布会有一个较着的性情，那便是Werner 很可爱出镜微电影。

终末就来抚玩一下这位"老戏骨"和他的 Simplexity 吧 ~

—  完  —

点这里� � 调治我，铭刻标星哦～

一键三连「共享」、「点赞」和「在看」

科技前沿进展日日再见 ~