无中断服务迁移:你能从当地超市的收银员那里学到什么

原文：https://medium.com/hackernoon/interruption-free-service-migrations-how-you-can-learn-from-the-cashiers-at-your-local-supermarket-36c1fe72397b

亚马逊可以做到，谷歌 e 可以做到，很多其他公司也可以做到:无中断服务迁移。

那么，为什么这么多的企业、银行和其他机构做不到这一点呢？为什么我仍然会收到银行的通知，说周六下午 4 点到周日上午 10 点之间会有服务中断。为什么高级经理在收到变更请求时还会问这样一个问题:“该变更会造成中断吗？”20 年前，这可能是一个合理的问题，但你上一次去 google.com并得到“由于维护而停止服务”是什么时候？

我不知道为什么我们还在谈论这个。然而，我知道如何进行无中断的服务迁移。很简单:

观察并向当地超市的收银员学习

假设他们有 4 个柜台。#1、2、3 是开着的，后面有收银员。现在 2 号柜台后面的收银员下班了，需要换人。

下面是收银员不会做的事情:停下所有的事情，把现金抽屉拿出来，等待她的替代者，她必须把现金放进他的现金抽屉，而这一切都是在柜台上的整个顾客队列都在等待的时候。

事实上，这是将要发生的:第四个收银员将打开 4 号柜台，开始为顾客服务。接下来，2 号柜台的收银员将挂上关门的标志，以避免更多的顾客排队。她仍然会为她队列中剩下的顾客服务。然后她会关上它。

请注意这是一个 4 步流程:

开启新服务
将流量路由到新服务
为旧服务中的所有剩余流量提供服务
关闭旧服务

此外，请注意这是如何打开所有可能性的:2 号柜台的收银员可能会突然决定重新开业，或者根本不关门，而 4 号柜台的收银员仍然在服务。或者 4 号柜台的收银员可以决定这不是一个好主意，放一个关门的标志，在剩下的队列被服务后离开。都是天衣无缝的。

生产系统

那么，为什么我们在生产系统中仍然有这些令人紧张的升级过程呢？这些全有或全无的高风险无回滚升级过程，潜在的服务中断，当那些收银员为我们提供了如何做的完美蓝图？

好吧——我确实意识到生产系统比我上面描述的要复杂一些。但是和往常一样，处理复杂性的方法是把它分解成小的、易消化的块。这是最难的部分。一旦完成，任何服务升级都可以低风险地逐步完成，并在任何时间点回滚，就像上面的收银员可以做的那样。

下面让我试着用一些例子来阐明我的观点。

例子

更改证书

几乎所有重要的系统都需要处理证书。问题总是在于，你如何确保你的客户端和服务器同时更新？

答案是，他们没有。相反，验证证书有效性的一方应该允许一个新的和一个旧的作为过渡期。

以下是步骤:

将新证书添加到客户端上接受的证书列表中(假设这是验证方)
在服务器上，用新证书替换旧证书
等待所有使用旧证书的请求在客户端上完成
从客户端删除旧证书

更新数据库模式

假设您有 1000 台机器访问一个 SQL 数据库来支持一个 web 应用程序。新版本的 web 应用程序在数据库中使用了一个重命名的列。因此，您需要在数据库中重命名该列，同时将所有 1000 台机器升级到新的 web 应用程序版本。你怎么能这样做？

你不能。相反，您的新版本必须能够理解包含新列名和旧列名的模式。它必须总是首先尝试使用新的，并在必要时退回到旧的。编写时，应该始终使用新列名和旧列名。

以下是您的部署方式:

将新列添加到数据库中。(打开 4 号柜台)
以交错的方式将你的新 web 应用程序版本部署到你的机器上，可能用金丝雀(将流量重新路由到 4 号柜台，挂上关闭标志)
有一个将所有旧列值复制到新列值的后台作业。(在 2 号柜台为所有剩余顾客服务)
删除 web 应用程序中的回退机制，然后再次部署(再次交错)。(关闭 2 号柜台)
可选:删除旧列。(拆除 2 号柜台:-))

新的存储服务后端

与前一个非常相似。假设您目前使用的是 S3，但希望迁移到另一家供应商提供的另一种 S3 兼容存储服务。您的服务可能包含数千台机器。

同样，为了做到这一点，您引入了一个代码更改:写入现在转到新的和旧的存储服务。读取到新的，但是当没有找到资源时退回到旧的。删除也适用于两者。

迁移计划是这样的:

设置新的数据存储。(打开 4 号柜台)
将您更新的系统部署到您的机器上(将流量重新路由到 4 号柜台，挂上关闭标志
让后台将您的所有数据从旧的存储服务复制到新的存储服务(在 2 号柜台服务所有剩余的客户)
删除代码更改，只配置的新数据存储。(关闭 2 号柜台)

请注意，您可能需要临时增加服务的机器数量，因为数据存储操作的成本更高。

含义

看看这些例子，特别是最后一个，现在有一点已经很清楚了:要进行这样的迁移，您需要拥有代码。如果您正在操作一个您无法更改的系统，您将无法进行有助于无中断迁移的更改。

可能正是因为这个原因，与开发和运营严格分离的更经典的组织形式相比，遵循“你建立它，你运行它”文化的较新形式的组织，例如亚马逊的双披萨团队，更适合这种无中断的服务迁移。

同样显而易见的是，这种类型的迁移计划要求团队能够进行频繁的部署和小的更改。在此类迁移过程中的任何时间点，您都必须能够停止或回滚。当您的更新包含其他不相关的更改，并且您的部署过程是手动的和缓慢的时，这是很困难的。

有一种机制部署到所谓的“金丝雀”( canaries ):首先获得更新的单个机器，这也是有帮助的。只有当它们被证明工作正常时，更新才会被推广到更多的机器上。

如果您想知道什么可以帮助您完成这种部署，请使用 BOSH 。它可能无法在规模上与亚马逊的内部部署系统阿波罗竞争。但这是你目前能得到的最强大的东西之一，尤其是免费和开源的。

结论

当地超市的收银员可以为您提供实现无中断服务迁移的蓝图。使用这个蓝图，您可以将您的(潜在的巨大)迁移分解成小的变化，从而提供无缝、无中断的迁移。采用一种融合了开发人员和操作人员的组织结构有助于实现这样的小变化，从而有助于实际的迁移。最后，使用像 BOSH 这样强大的部署系统，以自动化的方式部署变更。