详情

萧瑟开yun体育网，真是萧瑟。

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

—  完  —

点这里� � 怜惜我，谨记标星哦～

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

科技前沿进展日日再见 ~