分享5个使用AWS服务时总结的经验教训
推荐超级课程：
@TOC
1. 不要再用自建数据中心的固有思维。
如果你习惯了在自建的数据中心设计和部署应用程序，你需要准备好忘记你所知道的大部分知识。努力理解和拥抱在云环境中操作的差异。
很多例子浮现在脑海中，比如硬件可靠性。在我们自己的数据中心，基于会话的内存管理是一个很好的方法，因为单个硬件实例故障是罕见的。在易失性内存中管理状态是合理的，因为我们很少需要从一台实例迁移到另一台实例。我知道预期在AWS中单个实例的故障率会更高，但我没有考虑到这些影响。
另一个例子：在公司的数据中心，我们拥有一个高容量、超快、高度可靠的网络。这让我们有奢侈的能力围绕与远程系统通信频繁的API进行设计。AWS网络的延迟更加多变。即使我们转向更高度分布式的架构，我们也必须对“在线”交互进行更有组织的规划。
2. 共享租户是困难的。
在设计面向客户的云环境软件时，关键在于管理预期整体的响应延迟。AWS建立在共享资源的模型之上：硬件、网络、存储等等。共享租户可能在堆栈的任何层级引入吞吐量的变化。你要么愿意放弃任何特定的子任务，要么在AWS内管理你的资源，以避免在必须时出现共享租户。
你最好的选择是构建你的系统，以预期和适应在任何层级的失败，这引入了下一个教训。
3. 避免失败的最佳方式是不断失败。
我们有时将公司在AWS中的软件架构称为我们的兰博架构。每个系统都必须能够成功，无论发生什么，即使完全依靠自己。我们设计每个分布式系统以预期和容忍它所依赖的其他系统的失败。
如果我们的推荐系统宕机，我们会降低对客户的响应质量，但我们仍然会响应。我们会展示热门标题而不是个性化推荐。如果我们的搜索系统慢得无法忍受，流媒体播放应该仍然完美运行。
4. 用真实规模学习，而不是玩具模型。
（注：原文在此处突然中断，可能还有后续内容未提供。）在我们全身心投入AWS之前，我们花时间研究了这个平台，并在其中构建了测试系统。我们努力模拟真实的流量模式来对抗这些研究项目。
这在帮助我们选择AWS方面至关重要，但在思考我们的架构方面并不像我们预期的那样有帮助。在我们生产构建的早期，我们构建了一个简单的中继器，并开始将完整的客户请求流量复制到我们的AWS系统中。这真正让我们了解了瓶颈所在，一些在白板上看起来明智的设计选择在大规模下显得愚蠢。
我们继续在AWS内研究新技术，但今天我们正在用真实数据全面开展研究。例如，如果我们正在考虑新的NoSQL选项，我们会选择一个真实的数据存储，并将其全面迁移到我们想要了解的选项。
5. 全身心投入。
当我回顾团队在今年AWS迁移中所取得的成就时，我感到非常惊讶。但并非总是如此顺利。AWS只有几年的历史，在其中进行大规模构建是一项开拓性的事业。在我们努力应对所承担任务的巨大规模以及AWS与我们的数据中心运作方式之间的某些差异时，有一些黑暗的日子。
当你遇到障碍时，要有毅力和决心去克服它们。我们的上司们不仅全力支持这次迁移，他还是推动这次迁移的人！他的承诺，公司各部门技术领导的承诺，帮助我们在本可以选择撤退时推动我们走向成功。
AWS是一套巨大的服务套件，正在不断改进，一些大型技术公司今天已经在那里成功运行。你也可以！我们希望我们的一些错误和学到的教训能帮助你做得更好。