罕见！云计算一哥CTO，现场不发产品只讲教训

see122

金磊 明敏 发自 拉斯维加斯
量子位 | 公众号 QbitAI

罕见，着实罕见。

一场近2小时的活动，CTO竟然全程没有发布任何新品！

这就是AMAZON云科技的CTO——Werner Vogels，刚刚在自家年度盛宴re:Invent24上演的一幕。

但有一说一，即便如此，诺大的现场，几乎无人离席。

为什么？

因为比起新产品，Werner相当于是把他入职AMAZON20年背后更珍贵的经验给公开出来了。

而且剑指生成式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今天提出的这套方法论，正是把AMAZON云科技多年来在实践中“踩过坑”后总结而来。

所以，正如那句“还要啥自行车”，AMAZON云科技都帮大家整理完了，赶紧来看下吧~

Lesson1：未雨绸缪，系统可演化是必要

Make evolvability a requirement — Evolvability is a precondition for managing complexity.
将可演化性作为一项要求，可演化性是应对复杂性的一种预判

首先第一课，Werner Vogels提出，可进化性是必须的，这是进行复杂管理的先决条件。

什么意思？

随着时间推移，系统是一定会发生变化的。因此在设计之初，就要确保架构能够轻松适应新的需求。

而且进化能力不同于可维护性，前者是长期的、粗粒度的功能或结构增强，而后者是短期的、细粒度的局部变化。

不然就会像温水煮青蛙一样，等意识到问题时，或许就太晚了。

在系统设计初期时，就应该做好前期规划、管理系统复杂性。

最直接的例子就是亚马逊 S3的发展。

最初，S3的设计目标是提供一个简单、耐用且具有成本效益的云存储服务。

后来随着客户数量以及服务量增加，S3不得不改进其技术和架构。比如从单引擎系统升级为支撑多个微服务和分布式存储的架构。

实际上，每一年S3都会增加新功能，但从不影响现有服务的稳定性。好比给高速运转的引擎加部件。

这得益于其在系统设计时就考虑到了未来的升级需求，设计了灵活、可扩展的架构，以应对未知的挑战，因此才可以在未来逐步扩展能力。

这种可进化性使得它能不断引入新技术、新功能和新流程，以适应新市场需求，保持竞争力。

不过，随着系统不断进化，复杂性就会增加。如何控制系统的复杂程度、提高可维护性，这是Werner Vogels讲的第二课。

Lesson2：化繁为简，提出微服务架构

Break complexity into pieces — Disaggregate into building blocks with high cohesion and well-defined APIs.
将复杂性拆解成多个部分，分解为内聚性高且有明确定义API的构建模块。

AMAZON云科技最初采用单体架构，后面随着业务发展，系统变得越来越复杂，单体架构表现出了扩展性差、可维护性低等问题。

所以，AMAZON云科技决定将单体架构拆解为多个独立的小型服务，即微服务架构。

每个服务负责一个业务功能，独立部署和维护，并定义良好的API接口以便它们相互通信。

在微服务架构划分中，遵循单一职责原则，即每个服务只负责一个单一的功能或智能。

增量拆分原则是将整个系统逐步拆分成多个较小的部分，然后逐步迭代进行拆分。

同时还要求一个服务内部组件之间的耦合度要尽可能低，与其他服务之间的依赖性尽可能小。这样做可以提高服务的独立性，使得各个服务可以独立地进行开发、测试、部署和扩展。

这种方法不仅减少了系统间的耦合，还让团队能更专注于各自的模块。全系统可以通过组件的不断迭代优化而持续演进，并在关键时刻平滑过渡，避免服务中断。

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

Align organization to architecture — Build small teams, challenge the status quo, and encourage ownership.
让组织与架构相匹配，组建小团队，挑战现状并鼓励主人翁意识。

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

有多小？一个形象的比方——大概两块披萨就能喂饱整个团队（doge）。

在AMAZON云科技内部，这种机制也被称为“两个披萨团队”。

它能很好解决传统职能层次导致的沟通效率低下、决策缓慢等问题。

这种方法不仅提高了团队的灵活性和自主性，还促进了创新和快速响应市场需求的能力。

让每个团队独立地工作和决策，可以进一步加快产品开发和迭代速度，这也是AMAZON云科技能够长期保持竞争力和创新力的诀窍之一。

另一方面也要建立良好的问责机制，营造积极向上的学问氛围，推动持续改进。

Lesson4：小而精美，一个team就是一个细胞

Organize into cells — In a complex system, you must reduce the scope of impact.
组织成单元形式，在复杂系统中必须缩小影响范围。

Werner Vogels还提到了一种内部的组织结构，被称为“细胞化”。

它将应用程序分解成更小的、独立运行的模块，使每个模块都能独立运行，把问题隔离在特定单元内，不影响其他单元。

就像是一个个细胞，它们拥有自己内部的功能，并通过细胞膜隔绝出一个相对独立的环境。

这在复杂系统中至关重要，有助于维护系统的稳定性和可靠性。

例如，AMAZON云科技服务通过散列算法将客户分配到特定单元，避免单点故障对所有用户的影响。

当然单元的划分也要大小适中，既要大到能够处理最大的工作量，又要小到可以进行实际实行。

Lesson5：未卜先知，降低不确定性

Design predictable systems — Reduce the impact of uncertainty.
设计可预测的系统，降低不确定性的影响。

设计可预测系统的核心目标是减少不确定性对系统的影响，使系统能够在高度复杂的环境中仍然保持稳定和高效。

设计可预测系统的几个关键策略是：

• 简单确定
  通过保持系统设计的简单性，能够更容易地预测和管理系统的行为。

例如，在负载平衡的处理上，AMAZON云科技采用了一种更简单的方法，将所有变化推送到一个文件中，然后在固定的循环中更新负载平衡器的配置。这种方法确保了系统的行为是可预测的，并且能够处理所有的配置条目。

• 持续工作模式
  使用持续工作模式，从亚马逊 S3中定期拉取文件，避免积压和瓶颈。这种模式自然具有自我修复的特性，因为屏幕的可用性极高。
• 自动化和标准化
  自动化是减少复杂性的关键手段。通过标准化操作，可以减少人为干预所带来的不确定性和错误。例如，在健康检查器系统中，定期推送完整的配置文件，而不是每次都推送变化。
• 分布式架构和模块化
  设计系统时，应将其分解为独立的模块，每个模块可以独立运行和扩展。这样可以在某个模块出现问题时，将影响控制在最小范围内。
• 高可观察性
  系统应具备高可观察性，能够实时监控和分析系统的运行状态。通过这种方式，可以及时发现和解决潜在的问题。
• 处理复杂性的策略
  通过将复杂的任务分解为简单、可管理的部分，可以有效地控制和处理系统的复杂性。AMAZON云科技一些服务采用固定的处理循环而不是事件驱动架构，从而确保系统的行为可预测，降低了运行时的复杂性。

Lesson6：机器代劳，提高效率

Automate complexity — Automate everything that does not require high judgment.
使复杂性自动化，将不需要高度判断力的一切事务自动化。

简单来说，这就是让机器来帮人处理那些可以简单判断的任务，把需要创造性和复杂决策的任务留给人类。

这种自动化能更进一步提高效率。

比如利用AI来监测恶意活动，并自动响应，保护客户业务免受安全威胁。

自动化不仅仅是解决常见问题的工具，它应该成为标准流程的一部分，只有在处理特殊情况时，才需要人工输入。

AMAZON云科技内部通过对支撑票进行自动分类和优先排序，有效减少了人工操作，提高了问题解决速度。

验证六个Lesson的价值

Werner提出的方法论，可以说不仅是AMAZON云科技服务成功的基石，更是现代分布式系统设计的重要引导。

不过在理论之外，他在现场也展示了经得起六大Lesson验证的产品——亚马逊 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，其各模块可以由小型团队独立开发和维护，这与AMAZON云科技的“两块披萨团队”理念完全一致。

例如查询处理器团队可以专注于事务逻辑优化，而日志模块团队则可以重点解决持久性问题，各司其职却无缝协作。

对应Lesson4，Aurora DSQL采用分布式架构，将系统功能划分为多个独立单元以限制故障影响范围。

例如数据存储被分为多个分片（Shards），每个分片独立运行并处理特定数据，确保某个分片故障不会影响全局服务。

而事务协调模块（Adjudicator）独立处理冲突，确保并发事务之间的隔离性和一致性，同时减少对核心数据库存储的影响。

对应Lesson5，Aurora DSQL解决了分布式系统中时间管理的传统难题，通过本地时钟处理事务的“开始时间”和“提交时间”，消除了对复杂分布式一致性算法（如Paxos）的依赖。

同时，存储引擎采用固定的查询和数据处理方式，避免了事件驱动架构可能带来的不可预测性，使系统性能更加稳定。

对应Lesson6，Aurora DSQL日志模块实现了自动化，事务提交后会马上写入日志模块，日志模块自动排序和分发事务，确保持久性和一致性。

并且其存储和查询模块可以根据负载动态扩展，无需人工干预，提高了资源利用效率。

由此可见，AMAZON云科技这次提出的六个Lesson，是经过考验的那种，更是“值得一抄的作业”。

而AMAZON云科技之所以能到做如此，离不开贯穿这几天所有Keynote的关键词，那就用户需求（Customer Needs）。

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

Innovation Driven by Customer Needs.
客户需求驱动创新。

不过有一说一，其实很多服务型企业同样是把客户需求放在第一位，那么AMAZON云科技又有何独特之处呢？

在量子位与AMAZON云科技全球客户技术支撑与服务副总裁Uwem Ukpong交流过程中得到了明确的答案：

大家非常擅长精准捕捉客户的需求，会坐下来面对面刨根问底的程度，不错过任何细节。
并且大家属于务实派的那种，先做再说。

One More Thing：

Werner在AMAZON就职长达20年之久，是全球最著名的CTO之一。

而看过近几年re:Invent的小伙伴可以发现，他的专场发布会有一个鲜明的特点，那就是Werner很喜欢出镜微影片。

最后就来欣赏一下这位“老戏骨”和他的Simplexity吧~

视频地址：https://mp.weixin.qq.com/s/sXKMFKU4Ytnfqb7Ti1l3uA?token=706944461&lang=zh_CN

来源：网易