在Gilt将微服务部署到AWS：ION-Roller简介

在七年的时间里，gilt.com已从Ruby-on-Rails初创企业发展成为基于Scala微服务架构的主要电子商务公司。吉尔特（Gilt）的闪购业务模式是基于推动客户流量的“脉冲”负载来竞争数量有限的奢侈品。采用微服务已为我们的服务提供了可扩展性，性能和可靠性的结合。它还为我们的开发团队提供了自治，授权和灵活性。团队可以自由选择使用的语言，框架，数据库和构建系统来为核心站点功能，移动应用程序，个性化算法，实时数据馈送和通知创建服务。

随着寒武纪软件服务的爆炸式增长，出现了如何部署和运行我们创建的工件的问题。 Gilt在“裸机”上开始运行其软件，该软件首先运行在一个传统数据中心上，然后是两个传统数据中心。团队将要求提供硬件，然后使用自定义脚本和Capistrano进行混合部署。它有效，但容易出现困难。 Hypervisor技术的初步实验被证明会削弱我们每天的脉冲负载性能。许多服务最终都放置在同一个物理机箱上，这导致性能异常，并且由于缺乏资源隔离而导致停运；如果在脉冲通信期间对服务进行流氓部署而消耗“每个请求多个线程”，则可能会占用整个站点。

我们采用了多种技术并创建了工具，以通过生产中的性能测试和连续部署来缓解这些问题。但是，我们对将数据分配和自动配置服务到我们数据中心的硬件中的方法的研究证明是耗时的，并且最终太困难了。

这导致我们考虑将微服务基础结构的批发转移到云（尤其是Amazon Web Services（AWS）），并完善不可变部署的概念，该概念的灵感来自于我们在函数式编程中使用不可变变量的经验。我们将基于数据中心的工具“ ION-Cannon”改编为新的即将开源的工具“ ION-Roller”。我们选择ION-Roller的动机是：

允许我们的团队以声明方式指定如何在AWS中部署其服务，例如可用的最小/最大节点数，实例大小等。
提供用于将服务和应用程序作为不可变的Docker映像部署到生产环境的管道，并分阶段推出并将流量从服务的旧版本迁移到新版本。
在恶意发行时支持快速回滚，可能会回滚到运行先前版本的本已“热”的实例集。

在本文中，我们将讨论ION-Roller中使用的核心概念，所涉及的技术和方法，并概述其用法。

基于ION-Roller云的微服务王国

我们设想微服务的世界是建立在独立的不可变环境之上的HTTP端点，它们通过REST API进行通信。

HTTP端点

Gilt使用HTTP作为系统之间通信的传输包装。 HTTP端点表示为用户的主机名/端口组合（在此之上具有发现层）。我们的想法是在软件和配置随时间的演变中将此端点用作组织概念。

虽然概念很简单，但可以实现许多有用的目标。通过使用适当的代理和/或网络，我们可以提供以下功能：

逐步推出新软件版本
安全回滚到以前版本的软件/配置
通过错误率和等待时间监视来检测异常
了解什么软件为端点服务
有关软件/配置随时间变化的信息

通过代码进行配置以描述环境

当操作规模很小时，部署中不受限制的灵活性似乎很有吸引力，但是随着规模的增加，它变得极其难以管理，监视和理解。

声明性配置是用于以结构化方式描述和管理部署的有用工具。作为配置，它比可能的代码要受限制的多，但可以分析和报告已请求的内容。

软件部署中的风险管理

发布软件涉及多个折衷：灵活性/简单性和速度/安全性。

大多数生产环境都在朝着部署过程发展，这些过程允许在完成功能/错误之间的时间缩短，并将这些更改交到用户手中。这意味着生产环境的变化率更高。鉴于每次发布都涉及风险，因此该政策存在一些弊端。为了弥补这一点，团队需要采用发布流程来减轻单个发布中的风险，并使发布成为例行的安全操作。

风险涉及多个方面：问题数量，问题严重性，受影响的用户数量/百分比以及故障恢复时间。

发行过程不会像开发过程中那样影响问题的数量或严重性，尽管频繁的发行通常可以更快地了解问题的原因（由于每个版本发生的更改较少）。

我们可以帮助的是受影响的用户数量和修复时间。在这里进行生产，部分推出和Canary发布的测试。在没有任何生产流量的情况下测试新版本的影响最小（或为零），但发现的问题最少。由于只有在正常流量下才会出现许多问题，因此在查看新版本是否适合使用时，金丝雀（运行新软件的单个实例）是一种有价值的工具。此时，对用户的影响可能仍然很小，这取决于您对服务进行分片的程度。然后，缓慢地继续推出将保持通过最小化受影响的百分比来最大程度地减少错误对用户的影响的想法。

故障恢复时间可能是不可变软件方法的主要优势，因为旧软件仍在“热”运行。如果发现问题，则可以使用最小的风险和时间返回到较早的版本。我们将在后面进一步讨论不可变的部署。

运行软件的期望状态与实时状态

我们要不断监视应该在端点后面运行的内容与实际运行之间的差异。如果存在差异，我们应该（随着时间的推移）将系统的活动状态移向所需状态。我们会针对环境（运行软件，负载平衡器设置，DNS等）持续进行大量测试，如果与要求不符，可能会更新其中的任何一项。

例如，如果我们知道应该从特定版本的软件提供流量，并且发现没有运行此版本的服务器可用（出于任何原因，包括某人意外删除了它们），我们应该请求将其部署。

不变的部署

“不变的环境”的思想是部署具有定义的，可理解的配置的软件，该配置不会随时间变化。该软件和配置都被“烘焙”到了发行版中，您更改软件的方式不是通过更新现有数据并重新启动，而是通过使用新详细信息设置软件的第二个副本来进行的。

这个想法提供了一个更可预测的环境，并且还提供了一些有趣的可能性，即在新发行版被证明是“糟糕”的情况下，无需完全重新启动就可以回滚到软件的旧版本。（即使可以使用旧版软件，有时如果要完全启动它，或者必须加载缓存等，也很昂贵且耗时）。

在较小规模的环境中，可能只有少量正在运行的服务器，只有在完成部署后才能发现新发行版的问题。使用传统的不可变发行版，该软件的所有旧版本将已经终止。

目前在我们的服务中实施的不变部署方法有一个缺点。由于每个环境都是按需设置的，因此设置时间取决于诸如启动新EC2实例以及下载适当的Docker映像的时间等因素。相比之下，需要现有计算机池的其他部署工具在安装软件之前不需要设置计算机。因此，我们将回滚的延迟时间降低了，而初始软件的延迟时间却有所提高。

Docker映像

对于微服务环境，从部署系统中抽象出工具选择和语言选择可能是一个有用的概念。这使各个团队在构建软件时拥有更大的自治权。尽管有很多选择使之成为可能，从特定于操作系统的打包平台（例如RPM）到特定于云提供商的打包器（例如Packer），我们还是决定使用Docker来实现此目的。 Docker在选择部署环境和策略时提供了很大的灵活性，很好地满足了我们的需求。

重新发明轮子？

当我们查看可用于轻松管理基于不可变 Web服务器的基础结构的当前选项时，这些选项似乎很有限。目前，大多数软件已针对就地更新软件进行了优化，而不是针对我们感兴趣的更新类型进行了优化。我们还对管理Web服务器流量的完整生命周期感兴趣，并且没有找到针对此任务的优化选项。

另一个考虑因素是，要求开发人员学习和理解现有部署工具集是否可能具有更大的价值，或者如果给定一个无摩擦的简化工具来满足将特定版本的软件部署到该工具的需求，那么他们是否实际上会更有生产力？生产。我们认为开发人员应该能够轻松发布软件，而无需了解底层机制的复杂性（同时在高级用例要求时保留自定义的可能性）。

为什么不伪造/厨师/等。

许多工具以机器为中心的世界观，并且配置是在每台机器的基础上完成的。取而代之的是，我们对系统状态进行了更广泛的了解（例如，我们希望该软件的四个副本为流量提供服务），并且实际上并不太在意单个计算机。我们利用AWS提供的更高层次的概念，例如替换不断失败的运行状况检查的计算机，以及在HTTP端点上有额外流量时动态地增加额外容量。

为什么不使用CodeDeploy

CodeDeploy是Amazon提供的软件推出管理系统；但是它不能满足我们在支持不变基础架构方面的需求。尽管将使用CodeDeploy发布软件的脚本放在一起很容易，但是您确实需要预先设置环境。另外，CodeDeploy也不提供现成的支持来部署Docker映像。

为什么不使用普通的Elastic Beanstalk

Elastic Beanstalk提供创建环境的能力，该环境允许运行Docker映像，并设置了许多支持系统，例如EC2实例，负载均衡器，自动扩展组（根据负载更改服务器数量）。它还允许访问日志文件以及对这些系统进行一定程度的管理。

但是，它对“不可变部署”概念的支持极为有限，在该概念中，一个软件的多个发行版可以向同一用户可见的端点提供流量，流量会随着时间的流逝逐渐移动。它唯一的支持是“交换CNAME”的能力，这是一种非常粗略的传输流量的方法-所有流量都立即转移到新环境。而且，由于DNS的性质，它存在可靠性问题；查找结果可以在DNS更改后缓存一段时间，而且错误的客户端也可以忽略DNS TTL值，从而导致流量在应移动的很长时间之后发送到旧环境。

而且，Elastic Beanstalk没有更高层次的结构来了解端点后面生产环境中正在运行的内容。 “正在运行什么，它的配置是什么”这个问题不容易回答，并且需要在其之上安装某种系统。

我们决定将Elastic Beanstalk用作部署Docker软件的有用方法，但在此之上分层适当的管理和控制层，以为我们的用户提供完整的工作流程。

ION-Roller简介

ION-Roller是一项服务（API，Web应用程序和CLI工具），它利用Amazon的Elastic Beanstalk和基础CloudFormation框架功能将Docker映像部署到EC2实例。

ION-Roller入门-您需要做的小事情

您开始部署软件所需要做的就是：

拥有授予ION-Roller代表您旋转实例并访问资源的权限的AWS帐户（如果您的组织在多个AWS帐户之间运行软件，只要有足够的权限，ION-Roller即可在所有这些帐户中提供部署的单一视图）。
Docker注册表中的Docker映像（hub.docker.com或您选择的私有Docker注册表）
您的软件的部署规范，包括HTTP端点，EC2实例的数量和类型，Docker映像的运行时参数，环境变量，安全设置等；这些作为服务配置的一部分提供，并通过其REST API发布到ION-Roller。

有关将ION-Roller安装到您的AWS账户中的详细信息和完整文档，请继续关注https://github.com/gilt/ionroller的开源。

使用ION-Roller部署软件

您可以使用提供的命令行工具轻松触发部署：

ionroller release <SERVICE_NAME> <VERSION>

该工具提供有关发行进度的持续反馈：

[INFO] NewRollout(ReleaseVersion(0.0.17))
[INFO] Deployment started.
[INFO] Added environment: e-k3bybwxy2f
[INFO] createEnvironment is starting.
[INFO] Using elasticbeanstalk-us-east-1-830967614603 as Amazon S3 storage bucket for environment data.
[INFO] Waiting for environment to become healthy.
[INFO] Created security group named: sg-682b430c
[INFO] Created load balancer named: awseb-e-k-AWSEBLoa-A4GOD7JFELTF
…

另外，由于ION-Roller提供REST API来完全控制您的配置和发布，因此您可以以编程方式触发部署。

在后台，ION-Roller发挥其全部优势触发了Elastic Beanstalk部署过程-包括创建负载均衡器，安全性和自动扩展组，设置CloudWatch监控并从Docker注册表中提取指定的Docker映像。

流量重定向

一旦检测到成功部署，ION-Roller就会随着时间的推移安全地将流量从服务的旧版本转移到新版本。

通过更改EC2实例集来进行流量重定向，该实例通过负载均衡器提供对HTTP请求的响应。随着部署的进行，新部署中的实例将添加到负载均衡器配置中，旧部署中的实例将被删除。发生此操作所需的时间是可配置的。

逐步的流量重定向使您可以监视最新版本，快速检测故障并在必要时回滚。

软件回滚

由于在推出期间旧环境仍然可用并且软件仍在运行，因此我们可以随时安全地回滚到软件的旧版本。经过一段可配置的时间后，将删除未使用的旧实例。由于这种延迟，我们仍可以在完成部署后回滚一段时间。

我们的目标是持续监视端点的运行状况，并在检测到问题时自动还原到旧版本；我们将使用Amazon的CloudWatch警报来发出应执行回滚的信号。

执行手动回滚就像运行一样容易：

ionroller release <SERVICE_NAME> <PREVIOUS_VERSION>

如果旧实例仍然可用，则只需几秒钟即可将流量移回先前的版本。当然，这假定您没有做任何事情来使旧软件中断（例如更新数据存储架构等）。如果您依赖于回滚软件的能力（无论部署系统是什么），请记住这一点很重要。

金丝雀的发布和生产测试

ION-Roller通过配置流量迁移过程来支持金丝雀释放的概念。在将新版本部署到初始实例集之后，该过程将停止，从而允许针对生产流量进行发布测试。在可配置的时间段后，将继续进行推广。

生产测试

对于您希望在不向其发送生产流量的情况下测试（或演示）新软件的用例中，我们希望ION-Roller允许设置单独的HTTP端点；这样就可以在更新生产终结点之前处理请求。

随时关注事物-ION-Trail

ION-Roller可以看到端点后面的环境/软件及其随时间的所有变化。在监视或更改环境时，它会记录与环境生命周期或部署活动有关的事件。这可以用于审核，监视和报告目的。 ION-Trail是一项支持服务，可为所有记录的部署活动提供事件源。

结论-分散DevOps

我们希望本文分享了一些有关将微服务架构部署到AWS的想法。 ION-Roller使我们能够分散DevOps组织的权力，并让工程师进行声明式部署。 ION-Roller为我们提供了阶段性推出，热回滚，并支持“ canary”和“生产中测试”等功能。要了解更多信息，请在Gilt Tech博客（http://tech.gilt.com）上关注即将公开宣布的ION-Roller开源发布的公告。

翻译自: https://www.infoq.com/articles/gilt-deploying-microservices-aws/?topicPageSponsorship=c1246725-b0a7-43a6-9ef9-68102c8d48e1