2024亚马逊云科技re:Invent大会的精彩仍在继续，亚马逊副总裁兼CTO Dr. Werner Vogels关于系统架构的主题分享，可以说是每年的压轴之作。在去年俭约架构设计理念基础上，今年关于复杂系统架构设计原则的深度解析，再一次点燃了架构师的热情。

开场短片中，Werner重点介绍了亚马逊内部“two-pizza team”文化，这是创新人贝索斯曾提出的一个理念——“团队颗粒度越小，协作就越好”，也是底层架构设计的精髓，背后其实是微服务技术逻辑在支撑。亚马逊用这一理念开启了十多年探索，在创新和效率上取得显著成果，简约架构、松耦合、无状态服务……其实都是这一技术理念的产物。

面向未来，系统架构的复杂性一直在增加，我们该如何继续扩大规模，提高系统可靠性？“复杂无处不在，请为失败做好准备。”Werner认为，无论是单体服务、微服务，还是纳米服务，每一项服务都有争议，企业正确的做法是“按需选择”，根据业务需求以及成本等相关要素去选择适合的技术路线。

问题是，什么是复杂性？是不断增加的组件吗？Werner以单轮车、双轮自行车和三轮车为例，说明组件数量并不能代表系统整体的复杂性。

从泰斯勒定律来看，复杂性有一个内在逻辑，即每个应用程序都承载着其固有的、不可削减的复杂度，无论是在产品开发阶段还是用户交互过程中，这种复杂度都无法被随意消除，只能通过各种方式进行调整与平衡。

用Werner的原话概括，复杂性既无法创造，也无法摧毁，只会被转移到其他地方。同时，并非所有的复杂性都相同，有一种复杂性是由不断变化的技术或者缺乏架构设计思维导致。最终，这样的系统会消减你的速度，使系统难以维护。

那么，意想不到的复杂性有哪些迹象呢？比如：功能开发交付变慢、频繁的故障事件需要升级处理、费时费力的调试、代码基础库不断膨胀、到处都是依赖关系等等。

Werner表示，企业要想从容应对不断增加的复杂性，在系统设计时应该秉承六个原则：

1、可持续的演进架构

进化是人类进步的源泉！正如达尔文的进化论所言，物种的起源不是神创造，而是经过长时间的演化，逐渐形成新类型、新物种。

同样，可持续演进架构应该从第一天开始学会管理环境，防止复杂性失控。另外，随着时间的推移，还需要对系统架构不断优化。可进化不同于可维护性，可进化性是长期的复杂性处理策略；而可维护性是确保系统在短期内正常工作。

2、将复杂系统拆分

亚马逊云科技将复杂系统拆解为一系列低耦合、高内聚的小型组件，并配备清晰定义的API以促进组件间的无缝通信，成功打造了更直观的前端服务，比如：Amazon CloudWatch，这是一项监控应用性能、响应变化、优化资源利用及提供操作健康洞察的服务。

3、组织架构需要和技术架构匹配

在构建日益复杂的系统时，组织本身的复杂性往往与系统软件不相上下。而构建高效团队的首要秘诀是拒绝自满。

即便一切顺利，也需要保持警惕，不断审视潜在风险，随时发现问题解决问题。在保持自醒的同时，要建立一个信任型团队，给予团队一定的自主权和决策权。

4、以单元化技术架构缩小影响范围

将服务拆解为基于单元的架构，能够有效地隔离问题，避免其影响其他单元。理想的单元设计应足够庞大,以应对可预见的最大工作量，同时又要足够小巧，便于进行大规模测试。准确来说，我们需要在规模与可操作性之间找到一个平衡点，这将有助于维护客户更长远的可靠性和安全性，并显著缩小问题对客户的影响范围。

5、以可观测性系统消除不确定性影响

构建一个高度可预测的系统，能够有效降低不确定性的影响，而事件驱动的架构在此方面尤为宝贵。以Amazon Route 53为例，它提供了高可用性和可扩展性的域名系统（DNS）、域名注册以及健康检查云服务。通过减少频繁的DNS数据库重新配置，转而专注于在接收到请求后即时进行健康检查，使整个处理流程变得高度可预测。

6、自动化处理不需要人为决策的事务

许多开发人员和工程师所面临的关键任务往往既艰巨又枯燥。相较于询问“我们应该自动化什么？”，更应思考的是“我们不自动化的是什么？”。因此，理想状态是将所有无需高度判断力的工作实现自动化。

举例来说，客户可以利用无服务器智能工作流技术，创建一个不稳定Ticket分类系统。在这个系统中，针对明确用例设计的自主AI代理能够自主解决问题，或在必要时升级为人类介入，从而极大地提升了效率。

现实业务环境中，一提到复杂系统，很多人会知难而退。那么，一些领先应用在进行系统设计的时候，会秉承哪些设计原则或者理念呢？在亚马逊云科技几款经典产品中，系统架构设计绝对是加分项！

Amazon S3

Amazon S3 团队工程师Andy以拖拉机拉雪橇为例，说明分布式系统设计不能只盯着“缓冲区”，随着引擎的发动，复杂性也会增加。Amazon S3之所以有今天的成功，是因为架构设计团队始终保持专注和耐心。通过专有威胁模型，企业可以有效预测风险。

另外，组织人员也要与技术架构匹配，需要建立小型团队，让每个成员都有紧迫感和所有权意识，直至达到前文提到的two-pizza team的水平。

Amazon Aurora DSQL

采用分布式系统应对复杂性挑战，Amazon Aurora DSQL是个典型案例。在CAP定理中，一个系统有三个特性，包括一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），通常三个要素只能同时实现两点，不能三者兼顾。

过去，很多厂商一直在为CAP的“既要又要也要”努力，但一直没有实际进展，Aurora DSQL采用并行处理命令，再通过时间戳（Amazon Time Sync Service）、漂移问题的解决，降低了延迟问题。

为了实现多区域强一致性和低延迟能力，Amazon Aurora DSQL将事务处理与存储解耦，以克服通用方法的局限性，这意味着用户体验得到大幅提升，将以光速实现信息的来回传递。在信息传输过程中，Amazon Time Sync Service可以确保所有区域都能准确追踪数据库操作的顺序，该服务在每个EC2实例上集成硬件参考时钟，并与卫星连接的原子钟实现同步，为全球各地的用户提供微秒级的精确时间保障。

目前，Amazon Aurora DSQL号称是最快的无服务器分布式SQL数据库，用户可创建99.999%多区域可用、高度一致且PostgreSQL兼容的应用程序，而且不必管理基础设施。对于一个基本的 10次事务SQL语句，Amazon Aurora DSQL的读写吞吐量是其4倍。

Amazon DynamoDB

除了在关系型数据库中实现多区域、强一致性和低延迟特性，亚马逊云科技在其流行的NoSQL数据库Amazon DynamoDB上推出了类似的功能。

借助Amazon DynamoDB Global Tables，用户不仅用来创建和现代化企业的关键应用程序，还能确保多区域应用程序能一直读取最新数据，并且不需要更改任何代码。

正如Werner所言，虽然复杂性不可避免，但只要遵循一系列架构设计原则去不断迭代，就可以让未来系统始终保持可持续、可控、可靠和简化。需要重点强调的是，相比建立一个系统，更应该关注可管控性，这是系统设计的关键。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您发展海外业务和/或了解行业前沿技术选择推荐该服务。