荒僻，确实荒僻。

一场近 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 吧 ~

—  完  —

点这里� � 怜惜我，难忘标星哦～

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

科技前沿进展日日再会 ~