金磊 明敏 发自 拉斯维加斯
量子位 | 公众号 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（简朴性）。
这又该怎样明白？
他以为系统的组件数量并不能直接权衡其复杂性。例如：
- 独轮车（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吧~
— 完 —
点这里 | 
