Werner Vogels 架构哲学新篇章：架构化繁为简的六大经验

 >在2024亚马逊云科技 re:Invent 全球大会第四天的主题演讲中，**亚马逊副总裁兼 CTO Dr.Werner Vogels** 分享了 The Way of Simplexity，繁简之道，浓缩了 Werner 在亚马逊20年构建架构的经验。 Werner 表示，复杂性总是会“悄无声息”地渗透进来，让系统变得更加复杂。复杂性本身是件好事，因为它意味着添加更多功能。所以“复杂性”并不是问题，而“管理复杂性”才是个问题。 ### **繁简之道简化从两块 Pizza 开始！** Werner 开场视频讲述了世界上最大的存储系统之一 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 的故事，以及通过 Two-Pizza team 工作法，保有高效创新的团队。“每年我都被大家的热情所感染”，Werner 说自己参与过13次 re:Invent 大会，在2012年首届亚马逊云科技 re:Invent 大会上首次提出的“21世纪架构”的理念，今年——Werner 引入了“繁简之道”（The Way of Simplexity）的概念：“要真正控制你的系统，你需要管理复杂性。”  随时间变化，需求的扩展、安全等等需要解决的问题逐步积累，系统的复杂性就逐渐上升。**“有意识的复杂性”是必要的，新功能需要与之匹配的系统规模。**“无意的复杂性”就可能造成真正的问题，导致系统变得脆弱、低速。Werner说：首先要识别这两种复杂性。办法也很简单：警示信号有很多，如发布功能速度放缓、系统频繁升级、调试耗时、模式不一致等。那么如何管理复杂度？“保持可演进性”，Werner 指出，“达尔文早已认识到，要成功形成一个复杂有机生物，唯一的方式就是无数次连续微小修正。”引用赫拉克利特的观点：世界处于不断的变迁之中。如果系统不持续演进，客户会认为公司的技术已经落伍。 #### **经验1 可演进性是必要条件，也是管理复杂系统的前提**  **Werner 指出，构建可控演进的架构，是应对复杂性、生存下去的关键所在**。他以 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 为例，当团队开始构建亚马逊简单存储服务 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 时，“我们就知道一年后不会使用同样的架构。”从表面上看A mazon S3 系统很简单，但在底层越来越复杂。2006年推出时，它只有6个微服务，现在已经超过300个。 但是，可演进架构与可维护性不同。**可演进性是一种长期策略，旨在应对复杂性的持续变化，而可维护性则是确保系统在短期内正常运行**。他说，亚马逊云科技一直在为 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 添加新功能，但客户近乎无感——从未影响其核心功能。 拓展系统，看起来似乎很简单，但其实，随着其内在复杂度的增加，难度与日俱增。我们无法预知未来，但可以设计出灵活、可扩展的架构，以应对未知的挑战。这不仅需要远见卓识的技术规划，更需要对架构本身和技术不断打磨。  **只有构建出能够以可控方式演进的系统架构，我们才能从容应对复杂性的持续变化，在保证系统核心价值的同时，不断融入创新，满足不断升级的需求**。这正是亚马逊云科技等科技巨头在架构设计上的重中之重，也是每个技术团队都应该重视和学习的宝贵经验。 #### **经验2 将复杂性分解为高内聚、定义明确的 API，然后构建模块** Werner 以 [Amazon CloudWatch](https://aws.amazon.com/cn/cloudwatch/?trk=cndc-detail) 为例，解释亚马逊云科技是如何将庞大服务分解为可演进的小模块。[Amazon CloudWatch](https://aws.amazon.com/cn/cloudwatch/?trk=cndc-detail) 是实时监控亚马逊云科技资源运行的应用程序，**随着系统不断扩展，[Amazon CloudWatch](https://aws.amazon.com/cn/cloudwatch/?trk=cndc-detail) 作为亚马逊云科技关键基础服务之一**，每天有成百上千亿的指标，复杂性也达到了新的高度。亚马逊云科技通过将 Amazon CloudWatch 拆分为一系列低耦合、高内聚的小组件，并定义良好的 API 接口，提供非常简单的前端服务。该服务经过一次次重写，在为客户提供新功能的同时，并不会带来中断。  **“去大化小”的架构思路，将复杂的大系统分解为简单、灵活、可组合的微服务，这是应对复杂性的可演进路径**。每个小型组件的职责明确，变更成本低，可以通过组件的不断优化而持续演进，并在关键时刻平滑过渡，避免服务中断。在遇到新功能时，既可以在现有功能上进行扩展，也可以创建一个新的微服务来实现，如果我们扩展现有代码，通常会更快，但需要冒着复杂度增加并产生超级服务的风险；如果创建新的微服务，则需要更长的开发时间，但可以保持服务的复杂度可控。  #### **经验3 让组织与架构对齐，组建小团队，鼓励主人翁精神，鼓励批判反思现状** 亚马逊云科技副总裁及杰出工程师 Andy Barfield 登台加入 Werner 演讲，阐释了第三条经验。他表示，[Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 服务已经存在18年了，**在构建越来越复杂系统的同时，必须承认，组织的复杂性与正在构建的软件一样复杂。** 首先，成功的团队不能自满。即使一切顺利，你仍然需要时刻留意可能出现的问题，并不断提出质疑。正是这种“挑战现状、指出漏洞并找到问题”的精神，帮助保障 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 的持久性。  第二，主人翁精神。**交给团队一个问题，并赋予他们决策权和空间去解决它。**领导者的职责是赋予团队决策权，同时保持一种紧迫感，帮助他们按时交付。  **一方面要赋能团队，授权并信任他们；另一方面也要建立良好的问责机制**，营造积极向上的文化氛围，推动持续改进。只有组织与技术架构相互匹配、相互支撑，才能真正释放团队的创新活力，攻克复杂性。 #### **经验4 单元化的组织，尽可能缩小问题在复杂系统中的影响范围** Werner 强调，确保复杂性可控也至关重要，方法是：采用基于单元的架构（Cell-based Architectures），将系统拆分为更小的独立单元。这些基础单元的颗粒度比传统团队更小、职责更明确。同时独立运作的细小单元，能更精确的控制“爆炸范围”。一旦发生故障或需要升级，只会波及到该单元本身，避免了连锁反应导致整个系统瘫痪。  Werner 结合亚马逊实践，深入阐释了设计哲学。理想情况下，一个单元应该足够大，能处理可想象的最大工作负载，但也要足够小，以便全面测试。这是一个权衡。但最终的衡量标准是，是否有助于长期维护可靠性和安全性，并减少对客户影响。**单元化设计是提高系统可靠性、弹性和安全性的有力手段**。通过将复杂的大型系统分解为相对独立的单元，每个单元的故障影响就被隔离。单个单元也更易于管理、测试和演进。  借助单元化架构设计思想，配合云原生技术如容器和服务网格，就能在降低复杂性的同时，最大程度提高系统的可靠性和弹性，真正为客户提供始终如一的优质体验。其最佳实践在《What is a cell-based architecture》一文中有所阐述\[1]。  #### **经验5 设计可预测的系统，降低不确定性的影响** Werner 指出，不确定性是管理复杂度的另一关键问题。不确定性通常很难处理，想象一下：你的任务是设计一个配置系统，但是现有系统的客户正在不断地重新配置他们的任务和参数，而且客户的数量级是数以百万计；这时，**一种常见的方法是使用小规模事件驱动的体系结构，更改配置并存储在数据库中**。每发送一个事件或队列，我们就相应调整系统。但如果这种情况持续发生，系统负载均衡所必须承担的重新配置的负载量，就会变得相当可怕。  但是，我们所采用是一种更简单的方法，**将所有的调整存储在一个文件中，该文件包含一组固定的记录，负载均衡器在固定的循环中，每隔几秒钟从该文件中获取新的配置，并处理所有记录**。此时重新配置就是完全可预测的，可简单地构建高度可预测系统，持续地从 [Amazon S3](https://aws.amazon.com/cn/s3/?trk=cndc-detail) 中取出一个文件，避免积压、瓶颈，自然而然地自我修复——这就是持续工作模式。  **另一个利用持续工作模式的例子是 Amazon Route53 的健康检查**。配置健康检查之后，无论节点是否可用，健康状况检查器只会定期推送出完整的配置文件到聚合器，聚合器合并所有请求，然后将其推送到一个更大的表中，并推送 Amazon Route53。这就实现了不会每次都触发调整，只有当 DNS 请求到达并被解析到一组 IP 地址时，系统才会检查表中的记录。这样，系统就是高度可预测的。而这是特意设计出来的。化繁为简需要有意识地配置和调整，设计可预测的系统，以减少不确定性。  #### **经验6 将复杂性自动化，让一切无需判断决策的事务都自动化** “自动化是另一条重要经验”，Werner 说。有些过程需要人工参与，但**对于大量功能而言，自动化是关键所在**。Werner 以安全领域为例，亚马逊云科技每天要处理超过1万亿次 DNS 请求，并且每天都会自动发现12.4多万个恶意域名——这是人工系统无法复制的自动化过程。因此，我们不应该问“我们应该自动化什么？”，而应该问的是“我们还有哪些没有自动化？”我们应该将一切无需判断决策的事务都自动化。  例如，客户可以使用 [Amazon Bedrock](https://aws.amazon.com/cn/bedrock/?trk=cndc-detail) Serverless Agentic 工作流程，创建智能化的票据分级系统。在这些系统中，针对特定用例场景训练的自主 AI 代理可以自行解决问题，在必要时才升级给人工处理。自动化是应对复杂性、提高效率的重要手段。当我们将大量重复性工作交给机器去执行时，不仅能极大降低人工操作的复杂度和出错率，还可以让人类的注意力集中在真正需要判断和创造的环节上。  ### **基于微秒级精准时钟更进一步降低分布式系统复杂度** 在分享全部六点繁简之道的经验后，Werner 讲述了“复杂性的负担”，亚马逊云科技正在通过构建更简单、更高效的系统，帮助客户将自主构建系统的复杂性转移到亚马逊云科技云服务上来。他强调了亚马逊云科技 CEO Matt Garman 在主题演讲中**发布的 [Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) DSQL 扩展功能这一典型案例**，相比较于传统云数据库，它不仅消除了全球部署及资源管理的复杂度，更将跨区域强一致性和低延迟，以及全球同步时钟的复杂性转移给了云。  同时，Werner 深入解读了 [Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) DSQL 背后的核心技术与逻辑，包括关键的繁简之道思路、从前端到存储的5级传输架构，以及打破了分布式系统时间无用论，微秒级时间精准同步的 Amazon Time Sync Service。正是这一系列突破性的技术，**为客户提供跨区域、强一致、低延迟的 [Amazon Aurora](https://aws.amazon.com/cn/rds/aurora/?trk=cndc-detail) DSQL。**  Werner 说，时间可能是最根本的构建模块。**亚马逊云科技的微秒级精准时钟和时间同步服务，将帮助客户显著降低复杂度。**  ### **设立NOW GO BUILD CTO Fellowship** 在主题演讲的最后，Werner 表示，作为科技从业者，“我们有责任帮助客户解决世界上最棘手的问题。”正是出于这一理念，去年他与救济技术组织（Tech To The Rescue）领导的 AI for Changemakers 组织以及亚马逊云科技社会责任团队合作，**设立了 “NOW GO BUILD CTO Fellowship”。该计划旨在支持那些利用人工智能和云计算推动积极变革的首席技术官们。**  科技的力量是双刃剑，能造福世界，也可能带来不利影响。作为科技从业者，我们肩负着更大的社会责任。Werner 呼吁，不要将科技孤立于社会之外，而是要主动以科技助力解决人类面临的种种挑战。“现在去构建”一个更美好的世界，正是科技人的终极使命！ \[1] 参考链接： https\://docs.aws.amazon.com/wellarchitected/latest/reducing-scope-of-impact-with-cell-based-architecture/what-is-a-cell-based-architecture.html?trk=cndc-detail **了解更多产品详情，请扫描下方二维码：** [Amazon EC2 ](https://aws.amazon.com/cn/ec2/?trk=cndc-detail)Trn2 ultra server  Amazon Nova Foundation Models  [Amazon Bedrock](https://aws.amazon.com/cn/bedrock/?trk=cndc-detail) prompt caching