Werner Vogels：20年架构设计，仅道六句箴言！

Werner开场视频讲述了世界上最大的存储系统之一Amazon S3的故事，以及通过Two-Pizza team工作法，保有高效创新的团队。“每年我都被大家的热情所感染”，Werner说自己参与过13次re:Invent大会，在2012年首届亚马逊云科技re:Invent大会上首次提出的“21世纪架构”的理念，今年——Werner引入了“繁简之道”（The Way of Simplexity）的概念：“要真正控制你的系统，你需要管理复杂性。”

可演进性是必要条件，也是管理复杂系统的前提

只有构建出能够以可控方式演进的系统架构，我们才能从容应对复杂性的持续变化，在保证系统核心价值的同时，不断融入创新，满足不断升级的需求。这正是亚马逊云科技等科技巨头在架构设计上的重中之重，也是每个技术团队都应该重视和学习的宝贵经验。

将复杂性分解为高内聚、定义明确的API，然后构建模块

Werner以Amazon CloudWatch为例，解释亚马逊云科技是如何将庞大服务分解为可演进的小模块。Amazon CloudWatch是实时监控亚马逊云科技资源运行的应用程序，随着系统不断扩展，Amazon CloudWatch作为亚马逊云科技关键基础服务之一，每天有成百上千亿的指标，复杂性也达到了新的高度。亚马逊云科技通过将Amazon CloudWatch拆分为一系列低耦合、高内聚的小组件，并定义良好的API接口，提供非常简单的前端服务。该服务经过一次次重写，在为客户提供新功能的同时，并不会带来中断。

“去大化小”的架构思路，将复杂的大系统分解为简单、灵活、可组合的微服务，这是应对复杂性的可演进路径。每个小型组件的职责明确，变更成本低，可以通过组件的不断优化而持续演进，并在关键时刻平滑过渡，避免服务中断。在遇到新功能时，既可以在现有功能上进行扩展，也可以创建一个新的微服务来实现，如果我们扩展现有代码，通常会更快，但需要冒着复杂度增加并产生超级服务的风险；如果创建新的微服务，则需要更长的开发时间，但可以保持服务的复杂度可控。

让组织与架构对齐，组建小团队，鼓励主人翁精神，鼓励批判反思现状

第二，主人翁精神。交给团队一个问题，并赋予他们决策权和空间去解决它。领导者的职责是赋予团队决策权，同时保持一种紧迫感，帮助他们按时交付。

一方面要赋能团队，授权并信任他们；另一方面也要建立良好的问责机制，营造积极向上的文化氛围，推动持续改进。只有组织与技术架构相互匹配、相互支撑，才能真正释放团队的创新活力，攻克复杂性。

单元化的组织，尽可能缩小问题在复杂系统中的影响范围

Werner强调，确保复杂性可控也至关重要，方法是：采用基于单元的架构（Cell-based Architectures），将系统拆分为更小的独立单元。这些基础单元的颗粒度比传统团队更小、职责更明确。同时独立运作的细小单元，能更精确的控制“爆炸范围”。一旦发生故障或需要升级，只会波及到该单元本身，避免了连锁反应导致整个系统瘫痪。

Werner结合亚马逊实践，深入阐释了设计哲学。理想情况下，一个单元应该足够大，能处理可想象的最大工作负载，但也要足够小，以便全面测试。这是一个权衡。但最终的衡量标准是，是否有助于长期维护可靠性和安全性，并减少对客户影响。单元化设计是提高系统可靠性、弹性和安全性的有力手段。通过将复杂的大型系统分解为相对独立的单元，每个单元的故障影响就被隔离。单个单元也更易于管理、测试和演进。

借助单元化架构设计思想，配合云原生技术如容器和服务网格，就能在降低复杂性的同时，最大程度提高系统的可靠性和弹性，真正为客户提供始终如一的优质体验。其最佳实践在《What is a cell-based architecture》一文中有所阐述^[1]。

设计可预测的系统，降低不确定性的影响

Werner指出，不确定性是管理复杂度的另一关键问题。不确定性通常很难处理，想象一下：你的任务是设计一个配置系统，但是现有系统的客户正在不断地重新配置他们的任务和参数，而且客户的数量级是数以百万计；这时，一种常见的方法是使用小规模事件驱动的体系结构，更改配置并存储在数据库中。每发送一个事件或队列，我们就相应调整系统。但如果这种情况持续发生，系统负载均衡所必须承担的重新配置的负载量，就会变得相当可怕。

但是，我们所采用是一种更简单的方法，将所有的调整存储在一个文件中，该文件包含一组固定的记录，负载均衡器在固定的循环中，每隔几秒钟从该文件中获取新的配置，并处理所有记录。此时重新配置就是完全可预测的，可简单地构建高度可预测系统，持续地从Amazon S3中取出一个文件，避免积压、瓶颈，自然而然地自我修复——这就是持续工作模式。

另一个利用持续工作模式的例子是Amazon Route53的健康检查。配置健康检查之后，无论节点是否可用，健康状况检查器只会定期推送出完整的配置文件到聚合器，聚合器合并所有请求，然后将其推送到一个更大的表中，并推送Amazon Route53。这就实现了不会每次都触发调整，只有当DNS请求到达并被解析到一组IP地址时，系统才会检查表中的记录。这样，系统就是高度可预测的。而这是特意设计出来的。化繁为简需要有意识地配置和调整，设计可预测的系统，以减少不确定性。

将复杂性自动化，让一切无需判断决策的事务都自动化

“自动化是另一条重要经验”，Werner说。有些过程需要人工参与，但对于大量功能而言，自动化是关键所在。Werner以安全领域为例，亚马逊云科技每天要处理超过1万亿次DNS请求，并且每天都会自动发现12.4多万个恶意域名——这是人工系统无法复制的自动化过程。因此，我们不应该问“我们应该自动化什么？”，而应该问的是“我们还有哪些没有自动化？”我们应该将一切无需判断决策的事务都自动化。

例如，客户可以使用Amazon Bedrock Serverless Agentic工作流程，创建智能化的票据分级系统。在这些系统中，针对特定用例场景训练的自主AI代理可以自行解决问题，在必要时才升级给人工处理。自动化是应对复杂性、提高效率的重要手段。当我们将大量重复性工作交给机器去执行时，不仅能极大降低人工操作的复杂度和出错率，还可以让人类的注意力集中在真正需要判断和创造的环节上。

在分享全部六点繁简之道的经验后，Werner讲述了“复杂性的负担”，亚马逊云科技正在通过构建更简单、更高效的系统，帮助客户将自主构建系统的复杂性转移到亚马逊云科技云服务上来。他强调了亚马逊云科技CEO Matt Garman在主题演讲中发布的Amazon Aurora DSQL扩展功能这一典型案例，相比较于传统云数据库，它不仅消除了全球部署及资源管理的复杂度，更将跨区域强一致性和低延迟，以及全球同步时钟的复杂性转移给了云。

同时，Werner深入解读了Amazon Aurora DSQL背后的核心技术与逻辑，包括关键的繁简之道思路、从前端到存储的5级传输架构，以及打破了分布式系统时间无用论，微秒级时间精准同步的Amazon Time Sync Service。正是这一系列突破性的技术，为客户提供跨区域、强一致、低延迟的Amazon Aurora DSQL。

Werner说，时间可能是最根本的构建模块。亚马逊云科技的微秒级精准时钟和时间同步服务，将帮助客户显著降低复杂度。

在主题演讲的最后，Werner表示，作为科技从业者，“我们有责任帮助客户解决世界上最棘手的问题。”正是出于这一理念，去年他与救济技术组织（Tech To The Rescue）领导的AI for Changemakers组织以及亚马逊云科技社会责任团队合作，设立了“NOW GO BUILD CTO Fellowship”。该计划旨在支持那些利用人工智能和云计算推动积极变革的首席技术官们。

科技的力量是双刃剑，能造福世界，也可能带来不利影响。作为科技从业者，我们肩负着更大的社会责任。Werner呼吁，不要将科技孤立于社会之外，而是要主动以科技助力解决人类面临的种种挑战。“现在去构建”一个更美好的世界，正是科技人的终极使命！