金磊 明敏 发自 拉斯维加斯量子位 | 公众号 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吧~—完—点这里👇关注我，记得标星哦～一键三连「分享」、「点赞」和「在看」科技前沿进展日日相见 ~
粤公网安备 44011502001135号