早在2006年，事务处理和屡获殊荣的数据库领域图的鼻祖JimGray就与WernerVogels进行了“第一次”对话。谈话的主题是“向亚马逊的技术平台学习”，而矛盾的是，吉姆格雷开创的交易处理是亚马逊电子商务的技术基础。近日，Akamai总监TomKillalea与亚马逊CTOWernerVogels进行了“第二次”对话。谈话的主题是大规模简单存储系统S3的演化设计。矛盾的是，就在一个月前，可与S3相提并论的最大区块链存储项目Filecoin才刚刚起飞。“我认为首先要认识到亚马逊是一家科技公司，这一点很重要，”沃纳·沃格尔斯在“第一次”对话中反复向吉姆·格雷解释说，亚马逊不应仅仅被视为一家在线书店，而应被视为一家在线书店。对于一家科技公司。而且，正是在这次谈话中，亚马逊首次推出了简单存储服务S3。“Amazon.ComBooks”，这个名字并不能体现我们的野心。汤姆基拉利亚说。当TomKillalea于1998年加入亚马逊时（TomKillalea于2018年3月加入Akamai担任董事），该公司只是一个销售书籍的网站：一个简单的C应用程序Obidos，一个部署在BerkeleyDBs上的键值存储，一个名为“ACB”（简称“Amazon.ComBooks”），这些应用部署在5台服务器上。不断膨胀的客户和订单数量使得亚马逊放弃了单体架构，转向去中心化的面向服务的架构。当JimGray询问亚马逊最大的教训时，WernerVogels说：第一课，也是最重要的一课，是元课程：服务意识。严格的面向服务是实现隔离的绝佳技术，您将获得前所未有的所有权和控制级别。使用服务不仅在技术方面得到改进，而且开发和业务流程也从中受益匪浅。服务模型是创建以客户为中心的快速创新团队的关键推动因素。每个服务都有一个与之关联的团队，该团队全面负责服务——从功能范围界定到架构、构建和运营。第二个教训是，通过禁止客户端直接访问数据库，可以在不涉及客户端的情况下对服务状态进行可伸缩性和可靠性改进。这些课程是关于如何访问服务的：如果你希望能够轻松地聚合服务，如果你想插入分布式请求路由或分布式请求跟踪等高级基础设施技术，你需要一个统一的服务访问机制。经验教训3：从客户角度和技术角度来看，赋予开发人员运营责任极大地提高了服务质量。传统的模式是把软件挂在墙上，把开发和运营分开，然后就忘了它。在亚马逊不是这样，谁建造它就运行它。这让开发人员了解软件的日常操作。它还让开发人员每天与客户保持联系。这种客户反馈循环对于提高服务质量至关重要。“如果技术不用于为客户的更大利益服务，那么技术就毫无用处。我们是一家以客户为导向的公司，我们经常使用‘从客户那里逆向工作’的方法。这意味着在我们的思维过程中，在你之前，我们从客户开始，逆向工作，直到我们找到满足新客户需求所需的简单、最少的技术。重要的是，来到亚马逊工作的工程师要明白，我们开发技术不是为了技术，而是为了支持客户。”“面向服务的架构、我们扩展的方式、我们为客户服务的方式——我认为我们最大的成功在于亚马逊已经成为其他企业可以从中受益的平台。”通过技术和业务服务亚马逊由此与用户建立了快速反馈循环，进入飞速增长的飞轮。2006年3月S3推出时，S3仅有8个服务，2019年S3已达到262个服务在与TomKillalea的谈话中，WernerVogels表示：“我完全同意这是前所未有的规模。即使在今天，即使以现在互联网服务的规模令人难以置信，我认为S3仍然领先它两年“三代”。在2006年的S3公告中，亚马逊采用了以下十项分布式系统设计原则来满足AmazonS3的需求：去中心化：使用完全去中心化的技术来消除扩展瓶颈和单点故障。异步：系统在任何情况下都继续工作。自主性：各个组件可以根据本地信息做出决策。本地责任：每个组件负责实现自己的一致性，这绝不是其他对等方的责任。受控并发：操作旨在不需要或有限的并发控制。容错：组件故障被认为是一种正常的操作模式，并且操作继续进行，没有中断或中断最少。受控并行：系统抽象具有使用并行来提高性能、恢复健壮性或引入新节点的粒度。将其分解为小的、易于理解的构建块：与其尝试提??供一个可以完成所有工作的单一服务，不如构建可用作其他服务构建块的小组件。对称性：系统中的节点在功能上是相同的，不需要或需要最少的特定配置即可运行。简单性：系统应该尽可能简单，而不是更简单。以上十项原则是亚马逊构建大规模分布式系统的方式。S3只是这些设计原则的一个例子。原则是灰色的，而客户的需求是常青的。基于以上原则，WernerVogels提出了一种进化架构。当时，大多数科技公司提供一切和一个“平台”，他们会提供厚厚的书和10个不同的合作伙伴，然后告诉客户如何使用该技术。亚马逊没有将自己锁定在自己的技术中，而是走了一条不同的路线。JeffBezos很多年前就说过，是打造工具，而不是打造平台。平台是大型软件平台公司提供技术服务的老路子。“在我们启动S3之前，我们开始意识到我们正在做的事情可以从根本上改变软件构建和服务消费的方式。但我们不知道这将如何发挥作用，因此构建小型、灵活的系统更为重要工具，以便客户可以在其上构建（或者我们可以自行构建），而不是在某个时刻准备好一切和“平台”。这不是时间问题，更重要的是，我们坚信无论我们向S3的界面添加什么，向S3的功能添加什么，应该由我们的客户驱动——以及下一代客户将如何开始构建他们的系统。”“在过去的五到十年里，软件从根本上改变了根本性的变化。我们需要构建正确的工具来支持根本性变化发生的速度。那样的话，你无法预测，你必须与你的客户合作看看他们如何使用你的工具——特别是如果这些工具是以前从未构建过的——并观察他们做了什么。然后我们坐下来问自己，什么是最小集。”“你必须在设计API时保持清醒和谨慎。API是长期的。一旦你把API放在那里，也许你可以提供新版本，但你不能把它从你的客户那里拿走。在您的API设计中保持保守和最小化可以帮助您构建基本工具，您可以在其上添加更多功能，或者合作伙伴可以在其上构建新层，或者您可以将不同的构建块组合在一起。这从一开始就是我们的理念：极简主义，这样我们就可以让我们的客户推动将要发生的事情，而不是我们坐在后面的房间里思考：世界应该是什么样子。“这些设计决策反映在亚马逊的数据湖中。基于构建块和工具，S3远不止是一个数据湖：围绕数据库，S3提供了一个巨大的工具箱（175种不同的服务）。在采访中，S3的设计决策还包括：持久性大于可用性，不变性大于分布式锁，计算和存储分离，不要把自己锁在自己的架构中，WernerVogels在回顾S3的设计原则时说过这样的话，一个有效的复杂系统总是从asimplesystemthatworks.一个从头开始设计的复杂系统永远无法工作，也无法通过修补使其工作。你必须从一个简单的工作系统开始。也许读者不需要去阅读原文两次面试，但你需要记住和思考的是本文总结的要点：服务意识、分布式系统设计十项原则、构建工具而不是平台、不要'不要把自己锁在自己的架构里。【本文为专栏作家诗诗原创文章，转载请通过作者微信公众号butianys（布蒂安斯）获得授权】点此查看作者更多好文
