金磊明敏发自拉斯维加斯
量子位公众号 QbitAI
罕见，着实罕见。
一场近 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 吧~
视频地址：https://mp.weixin.qq.com/s/sXKMFKU4Ytnfqb7Ti1l3uA?token=706944461&lang=zh_CN
