在AWS re:Invent大会上，CTO Werner Vogels分享了亚马逊在系统设计方面的一些基本经验教训。
译自 Werner Vogels' 6 Lessons for Keeping Systems Simple，作者 Joab Jackson。
"实体不应无故增多"——威廉·奥卡姆，奥卡姆剃刀
且不说亚马逊网络服务 (Amazon Web Services)，这家云巨头已经能够在其系统和服务上扩展超过二十年，不断推出新功能，同时保持用户体验易于管理。
在其 惯例周四 主题演讲中，AWS 首席技术官 Werner Vogels 分享了他二十年来在云巨头工作的经验中，关于 保持简单 的一些经验教训。
复杂性总是潜入系统设计中，因此工程师必须勤勉地管理这种复杂性。
目标始终是“以安全的方式扩展我们的系统，使其随着时间的推移变得更加复杂”，他说道。
目标不是消除复杂性，而是有效地管理它。
增强任何系统时的危险在于它带来了不必要的复杂性，这难以维护，并剥夺了用户的乐趣。
但正如 Larry Tesler 所指出的，复杂性无法消除，只能转移。
现在，存在良好的复杂性，这是为了帮助系统发展而添加的；然后是那种在没有架构监督的情况下发生的复杂性，它只会减慢用户速度，并使系统更难以维护，他解释道。
复杂性不仅取决于系统中组件的数量，还取决于这些组件的排列方式。
"你无法将给定任务的复杂性降低到某个点以下。一旦达到这一点，你只能转移负担。"——Larry Tesler
在这里，Vogels 以自行车设计为例。
实际上，自行车最简单的形式是独轮车，它只有一个轮子。独轮车非常灵活（"它们可以原地转弯"），但很难骑。
另一方面是三轮车，它们很容易骑，但笨重且难以操纵，任何骑过三轮车的人都知道。
最好的设计实际上是两轮自行车，它兼具易用性和灵活性。
"自行车有更多组件，但从整体角度来看，它是最简单的形式，"他说道。自行车成为最流行的自行车形式并非偶然。
将复杂性放在需要的地方。
Amazon S3（简单存储服务）就是一个例子，它只提供最终一致性，而不是强一致性。这意味着如果客户购买了 Amazon S3 存储桶，它最终会可用，但可能不会立即可用。
然而，客户希望获得强一致性，并已开始构建变通方案，以确保在其自身设计中基于 S3 实现强一致性，这导致了他们自身系统中不必要的复杂性。
AWS 最终重新设计了 S3 以实现强一致性，"将复杂性转移到需要的地方"，即远离客户。
那么，系统工程师如何管理他们自己系统中的复杂性呢？
Vogels 提供了六个技巧：
不向前发展的软件系统会消亡。即使是最稳定的软件也会看到世界在没有它的情况下前进。
此外，谁不想看到自己喜欢的应用程序拥有新功能或运行速度更快？
你的系统会随着时间的推移而发展，你需要修改你的架构，Vogels 建议道。
"每当你改变数量级时，你都需要重新审视你的架构，"Vogels 说。当 S3 推出时，设计工程师知道他们将改变架构。随着时间的推移，尽管其 API 的占用空间很小，但它积累了惊人的功能范围。
"你会看到，每年我们都会添加新功能，而不会对我们为客户提供的功能产生任何影响，"他说。
网络服务也是如此，在用户的请求下，网络服务得到了显著的发展。
"我们知道，无论我们在 2006 年为您提供的网络功能是什么，到 2010 年肯定会在 2020 年发生根本性的变化，"Vogels 说。
你需要制定一个策略来应对复杂性，这种复杂性会随着时间的推移在你的系统中增长。
Vogels 说，可进化性是管理复杂性的前提条件。
复杂性可能会潜入你的应用程序，就像谚语中青蛙汤里的热量一样。
"小的变化起初似乎很容易管理、很容易吸收，但如果你忽略了警告信号，系统就会变得越来越复杂，越来越难以管理和理解，"他说。 答案是将系统分解成多个更易于管理的组件。
Amazon CloudWatch 最初是一个简单的监控服务。随着更多功能的添加，每个功能都加载到登录页面上，直到页面变得非常繁忙，AWS 才重新设计了它，使其只保留核心功能。其他功能被迁移到它们自己的环境中。
服务应该有多大？它应该能够容纳在一个工程师的脑子里。
“如果你无法记住它，你的服务通常就太大了，”Vogels 说。
Vogels 说，通过完善的 API 构建具有“智能端点”和“细粒度接口”的业务重点组件。将它们分散，以便它们“独立发展”。
企业技术并非为了自身而构建。它是为客户而构建的。因此，系统架构师需要与他们服务的业务部门紧密合作。
协作至关重要。业务部门可能会说它需要 100% 的正常运行时间。这是可行的，但代价高昂。因此，系统设计师可能需要指出 100% 的可靠性将有多昂贵。
“然后你们就可以进行对话了，”他说。
Vogels 曾说过，一切都会一直失败。所以诀窍是计划失败。
随着应用程序的流行和功能的增加，它在操作方式上也会产生复杂性。考虑使用基于单元的架构来保持这种日益增长的复杂性的简单性。
“构建系统的时间通常比运行系统的时间要少得多。因此，提前投资可管理性至关重要，”Vogels 说。
管理这些操作也必须分解成更小的构建块。这是为了减少影响范围，这对于最大限度地减少停机时间至关重要。
“单元在复杂系统中创造秩序，”他说。“它们将问题隔离到特定单元，而不会影响其他单元。”
需要一个路由器和控制平面将请求路由到各个单元。路由标签可以基于区域 ID、主机 ID、客户 ID。
“随着时间的推移，分解成单元将有助于您维护客户的可靠性和安全性，”他说。
不确定性难以处理。因此，提前设计您的系统以减少不确定性。
AWS 为其面向客户的负载均衡器运行一个超平面，以处理数百万客户用来更改配置的所有更改。
令人惊讶的是，AWS 没有使用事件驱动架构 来设置此服务，这与普遍的看法相反，对于此任务来说是一种糟糕的方法，因为来自用户的负载请求速率将是不可预测的。
相反，AWS 将更改写入 S3 文件，负载均衡器以定期轮询间隔提取这些文件。
“简单需要纪律”——AWS 首席技术官 Werner Vogels
“这是一种我们称之为持续工作的模式，”Vogels 说。这种方法避免了峰值、积压和瓶颈，并且还使系统能够自我修复，因为“S3 是不可渗透的。”
AWS 的Route 53 域名服务在其运行状况检查器上采用相同的原理：轮询而不是排队。
要管理复杂性，就自动化复杂性。
AWS 使用自动化来完成许多任务，甚至包括构建新的区域，这是完全自动化的。
问题不在于自动化什么，而在于什么不自动化。只有那些真正需要人工参与的决策才应该有人工干预。其他一切事情都应该自动化。
“自动化应该是标准，例外情况是我们需要人工参与，”Vogels 说。“手动输入只应在真正需要人工判断的领域中需要。”
安全是 AWS 的一个高度自动化的流程，其中包括自动化威胁情报等流程。AWS 每天收到“数万亿”个 DNS 更改请求，每天至少识别 100,000 个恶意域名，这通过一个自动化流程完成——这是一个手工无法完成的流程。
支持票证是另一个适合自动化的领域通过代理。代理最适合非常狭窄的用例，在这些用例中，它们被赋予了一系列工具，可以通过称为“无服务器提示链”的流程来解决问题。
如果代理无法解决问题，只需将其提请人工注意。
“自动化所有不需要高度判断力的事情，”Vogels 说。