基础架构即代码 | 亚马逊如何在现实生活中实践 DevOps-六虎

当我在 2005 年作为开发人员参加亚马逊时（那时 Amazon Web Services 还不存在），我从公司领了一个传呼机（如图 1 所示）。在亚马逊，开发人员不只要规划完结一个具体的服务，还要担任这个服务的布置和管理。为了完结运营任务，开发人员需求轮番 “值勤”，随时预备毛病诊断和处理。传呼机便是值勤用的。

图1: 亚马逊发给职工值勤用的传呼机

这全部表明，亚马逊在 “DevOps” 这个术语呈现之前就现已在完结 DevOps 的路上了。Amazon.com 在亚马逊云科技供给的平台上运转着不计其数个体系，来支撑其全球商场事务、视频传递和其他消费者服务。当架构需求重新规划的时候，亚马逊开发人员就会考虑 DevOps，以便在值勤期间更轻松地为客户供给最佳体会。

亚马逊云科技开发者社区为开发者们供给全球的开发技能资源。这儿有技能文档、开发事例、技能专栏、训练视频、活动与竞赛等。帮助中国开发者对接国际最前沿技能，观点，和项目，并将中国优秀开发者或技能引荐给全球云社区。假如你还没有关注/收藏，看到这儿请必定不要仓促划过，点这儿让它成为你的技能宝库！

在这篇文章中，咱们将经过三个实用事例共享 Amazon.com 的研制团队怎么经过 “根底架构即代码” 的方法来完结微服务的连续、自动、独立的布置。

这种方法将事务逻辑与微服务以及担任它们的团队对齐，使得问题能够更快地传达给正确的团队，而且能够完结更快地更改并面向出产环境，同时不会搅扰其他组件。这加快了事务的立异，也减轻了值勤的作业量。

IMDb

互联网电影数据库咱们称之为 IMDb ，是国际上最流行的电影、电视和名人内容来历。

多年来，他们的后端一直是一个单体架构，运转在数百个 EC2 实例主机上的 REST API。这种架构尽管有用，但不够灵活，这也意味着运维工程师需求面临繁琐的值勤任务。

IMDb 的后端担任供给节目标题、艺人名字、星级评分汇总、图画、发布年份等等。GraphQL 是后端运用很好的选择。运用联合 GraphQL，后端能够被划分为多个微服务，每个微服务专注于特定的事务逻辑：一个用于服务图画，一个用于处理评级，另一个则知道哪些艺人呈现在哪些节目中。联合 GraphQL 使得每个服务只需求知道它自己的形式，同时客户断能够跨多个微服务完结数据恳求。

以下是它的作业原理：

图 2 在左侧显现了一个 GraphQL 查询（缩写），用于在 Jackie Chan 页面上查询“闻名著作”的插件，地址指向www.imdb.com/name/nm0000… nm 最初的 ID（例如成龙的 ID 是 nm0000329），而节目（包括电影或电视系列）有以 tt 最初的 ID。查询恳求发送给网关，网关了解整个形式，拆分每个部分并路由到恰当的微服务（称为图形元素），每个微服务都由 Amazon Lambda 供给核算。Lambda 是无服务器核算，这意味着无需装备服务器，直接运转您的代码。图 2 的顶部的微服务担任展示有哪些电影，下面的微服务担任关于电影的元数据（标题、年份等等），以此类推。

图 2: IMDb 结合 GraphQL 在实际运用中的效果

网关和每个 graphlets 都是独立栈，能够分别布置。正如咱们所看到的，每个 graphlets 的事务逻辑都是被明确界说的，担任这些 graphlets 的团队熟悉它和完结它的技能。一些 graphlet 是由旧服务创建的，并运用 Lambda 作为前端，以便能够将正确的呼应形状习惯 GraphQL 查询。其他 graphlet 是较新的，完全无服务器化的。旧的也能够被无服务器的替代，而不会对体系的其余部分形成任何搅扰。由于没有了单体架构，问题发生在哪里以及哪个团队具有解决方案变得愈加清晰。现在，团队发现值勤更轻松了。

Amazon Relay 面向货车司机的移动运用

亚马逊另一个重要事务便是物流，这也是亚马逊最闻名的事务之一。

在 Amazon.com 上购买的物品需求在正确的时间送达正确的方位。在配送中心、邮局和供货商之间，亚马逊在北美有数万个经过大货车运送货品的转运站（图 3）。

图 3: 亚马逊的 18 轮货车，也称为“大型货车”

多年来，亚马逊现已开发出了复杂的体系模型用来辅导将物品投放到正确的方位，但这仅仅核算机中的程序模型。要实际移动物品，货车司机需求知道什么时间？去哪里？拿什么？和将其放在哪里？这便是Amazon Relay运用的作用。Amazon Relay 运用（图 4）将复杂模型转化为具体可行的行动方法。

Amazon Relay:relay.amazon.com/?trk=cndc-d…

图 4: Amazon Relay 运用程序为货车司机供给了全部必要的信息。

与 IMDb 相似，Relay 团队规划了一个网关，运用程序与之通信，并将事务逻辑放入多个后端服务中，这些服务称为“模块”。例如，一个服务/模块确认配送中心的拜访，并生成在图 4 中可见的门禁通行证，另一个服务/模块用于核算履行（司机何时去哪里）。网关和模块都是独立布置的且具有独立的流水线。

图 5 显现了他们是怎么做到这一点的：

图 5: Amazon Relay 运用程序运用网关和称为“模块”的独立后端服务进行作业。

经过Amazon API Gateway，用域名作为外部拜访的单一进口，并运用依据路径的路由，这样就使得每个调用都能精确对应相应的服务。因此，对 example.com/message 的恳求面向运转消息功用的模块，而 example.com/navigate 恳求面向导航模块。API Gateway 答应为从指定路径到指定 Lambda 创建对应的 API。新建模块是无服务器架构的，运用 Lambda、DynamoDB（NoSQL 数据库）和SQS（队列服务）。更新旧模块，将 Lambda 放在前端，并与 API Gateways 进行集成。

Amazon API Gateway: –docs.aws.amazon.com/apigateway/…

DynamoDB: –docs.aws.amazon.com/amazondynam…

SQS:docs.aws.amazon.com/AWSSimpleQu…

团队运用多个 API 网关来阻隔他们的运用模块，这使得他们能够独立布置各个模块，先布置对事务不那么要害的模块，假如呈现问题能够回滚而不影响要害模块。这是经过利用各模块之间的阻隔和分阶段布置完结的。

这种架构更容易完结多区域战略。不管东部仍是西部的货车司机，都能够从更低的推迟中受益，由于他们的恳求被指引到更接近他们的 Amazon Web Services 区域。而这种多区域架构对灾难恢复战略也适用，在必要时间，所有流量都能够路由到某具体的一个区域。有关 Amazon Relay 怎么启用多区域的更多详细信息，请参见此视频：www.buildon.aws/posts/how-a…

配送中心

咱们现已介绍了配送中心之间货车的运转方法，现在让咱们来谈谈配送中心本身。全球范围内，亚马逊运营着 500 多个配送中心。Amazon Fulfillment Technologies and Robotics 是规划、布置和运营支撑这些配送中心服务的亚马逊部分。这包括收货体系以及确认物品在库房中的方位、告诉作业人员在哪里找到满意客户订单的物品、生成运送信息、确认运用哪个包装盒等体系。

正如我们现在所预期的那样，每个服务都独立布置，除此之外，亚马逊还采用了仓储架构来完结更高等级的独立布置。在仓储架构中，每个仓储都是一个独立完好的服务、一个独立实例（图 6），仓储之间没有共享。依据某些要害的分区，入站恳求会被指向特定的仓储。

图 6: 采用仓储架构，每个仓储都是独立完好服务、独立实例，它们是独立的，不互相共享状态。

关于支撑亚马逊配送中心体系，配送中心本身是自然的要害。配送中心之间不共享状态，因此将每个配送中心映射到特定的仓储是自然的选择。这样经过毛病阻隔来进步耐性的最佳实践。具体细节能够考虑图 7：三个配送中心比邻，服务于同一地舆区域。

图 7: Fulfillment Technologies and Robotics 分配配送中心给仓储，以便每个地舆区域由散布在不同仓储中的配送中心供给服务。

假如有毛病发生，不管是新布置软件中的缺点，仍是根底设施呈现了问题，这个具有耐性的架构能够缓解这些毛病，这也是仓储架构的存在的含义。毛病仅会影响到存在问题的仓储，和他们所匹配的配送中心的运营。但其他仓储遭到毛病阻隔的维护，能够继续正常地呼应恳求。在图示事例做，毛病仅会影响咱们组中的一个配送中心（图 8），但由于该地舆区域的配送中心位于不同的仓储中，其他配送中心继续为该地区的客户供给服务。

图 8：阻隔将毛病限制在一个仓储中，其他仓储正常运转。

每个仓储独立布置，且具有独立的自动化布置流水线。每个仓储都是后端服务的独立堆栈。图 9 显现每个仓储都布置在独立的 Amazon Web Services 帐户中，有一个用于测验的预出产（“pre-prod”）帐户和用于日志数据和跟踪的共享帐户。布置是顺序进行的，等待前一个库房布置成功并稳定后才布置下一个库房。