煤矿php源码技巧_改进十年应用的支配体验

在三个月的努力之后，我们终极得到了一个更具可扩展性、对开拓职员更友好、终极也是更健壮的办法来滚动发布对 Search 的改变。

过去，我们把堆栈支配到两套独立的主机上，也便是所谓的“蓝绿策略”。
在任何时候，只有一组主机是活动的；而另一组，或 "侧端"则处于“阴郁”状态。
这两边都是完备扩展的，并准备好为流量供应做事，但只有活动的那一组可以进入公共互联网。

蓝绿支配策略虽然大略，但具有一些非常有用的特性：

对付搜索运用，我们可以在一边做主要的改变，由于它是有状态的，同时持续地利用另一边来供应流量。
在将生产流量发送到它之前，我们有地方可以手动测试变动。
我们总是有一个以前的 Search 版本，在紧急情形下，我们可以轻松规复。
还有一个内置的机制，可以测试和产生其他打破性的变革，比如软件版本升级。

我们将这两组主机称为“flip”和“flop”，这因此当代打算机的基本构件——电路命名的。
在配置文件中，我们通过几行代码，将单个 PHP Web 运用指向哪一组，哪一组就该当处于活动状态。

图为我们之前的根本举动步伐。
一组（本例中的 flop）始终处于活动状态，在支配过程中，我们会将所有的流量一次性转移到另一组（本例中的 flip）。

三年前，Etsy 向云端迁移时，这种蓝绿支配的方法被“提升和转移”。
Search 团队将搜索运用移至谷歌 Kubernetes 引擎（Google Kubernetes Engine，GKE），flip 和 flop 成为两个独立的生产 Kubernetes 命名空间。

撇开这一变革不谈，事情的运作与以往一样：支配 Search 会立即触发所有的流量从一个命名空间——活动端——重定向到另一个命名空间中运行的同一做事。
为了确保阴郁端始终准备就绪，我们将连续在任何时候都保持 200% 的容量（每个生产命名空间 100%），正如我们在企业内部时所做的那样。

这种最初的支配策略对团队来说非常有用，尤其是为我们供应了一个安全的空间，可以测试和准备紧张的软件更新和根本举动步伐变更。
然而，它也并非没有痛楚。
溘然间，所有流量都被转移到两边，这使得我们没有余地在全部投入之前测试少量生产流量的变革。
乃至在统统顺利的时候，支配也是充满压力的。
如果情形出了问题，工程师们就得进行分流，来决定是否要完备恢复原状。
最主要的是，永劫光坚持双倍容量既昂贵又低效。

由于云打算供应了灵巧性，一旦我们安全地进入 GKE，我们就有机会重新考虑我们的蓝绿策略，并办理这些长期存在的问题。

我们的第一个想法是采取金丝雀支配策略。
在“金丝雀发布”期间，在将所有流量切换到新做事之前，将一小部分流量发送到做事的新版本，以确定它是否 “安全”。

为什么叫这个名字？煤矿工人曾经利用金丝雀来检测一氧化碳的浓度，这种浓度可能会侵害一只小鸟，但仍不会对人造成侵害。
软件工程师们也采纳了类似的模式（只管更加人性化），以树立新软件能够安全地做事于流量的信心。

虽然 Kubernetes 的架构和灵巧的扩展意味着金丝雀发布是一个非常盛行的支配办理方案，但是 Etsy 的搜索系统的设计意味着我们不能利用任何现成的金丝雀发布办理方案。
我们必须为自己建造一些新的东西，一种金丝雀精简版。

在考虑重新构建整合金丝雀组件的支配流程时，存在两个关键的限定。

第一个限定是，我们不能利用单一的负载均衡器活 API 断电来掌握流入流量的数量。
这样，我们就不能利用 Kubernetes 标签在单个 Kubernetes 支配上为任何搜索做事做基本的金丝雀发布，由于 Search 是由许多不同的 Kubernetes 支配组成的。
我们没有地方来设置路由逻辑来检讨标签，以及相应的路由到金丝雀 Pod。

但是，Etsy 的 PHP Web 运用是搜索运用的唯一客户端。
对付 Etsy，这是一种常见模式，因此，配置负载平衡常日是直接在 Web 运用本身中进行管理。
任何新的支配办理方案或者必须对 Web 运用管理流量到 web 运用内部的 Search，或者实现某种全新的网状网络（比如 Istio），捕获并勾引 Web 运用到 Search 的所有流量。
这两个方案在分配给该项目的韶光范围内都不可行。

第二个限定是，搜索运用假定要求路径中所有搜索做事的相同版本都会为任何单一 Web 要求做事。
以是，任何新办理方案的支配都须要确保所有搜索做事的旧版本都能知足正在进行的搜索要求。
乃至像 Istio 这样繁芜的金丝雀发布办理方案，也哀求你的运用场置不同做事之间的版本不匹配，这是我们无法担保的。

那么，我们如何为所有新版本的搜索做事创建一个逐步推出的过程，同时管理从 Web 运用到滚动发布的所有部分的负载平衡，并担保搜索做事只能和其他搜索做事的相同版本对话？对付这种 Etsy 特定问题，没有现成的办理方案。
因此我们开拓了一种全新的工具，叫做 Switchboard。

Switchboard 的紧张功能是管理流量：它通过逐步增加供应给新的活动真个百分比，并按比例减少进入旧的活动真个数量，将一个支配滚动发布莅临盆。

具有预先定义的流量比例的支配阶段被硬编码到系统中，当在当前滚动发布阶段中添加的所有 Pod 都完备创建并正常运行时，Switchboard 就会过渡到下一个阶段。
这是通过编辑和提交新的流量比例到 Web 运用中的配置文件来实现这一目标的。
Web 运用对每一个心情求都重新检讨这个文件，并利用这些信息在两个不同的生产 Kubernetes 命名空间之间进行负载均衡搜索流量，这两个命名空间仍旧被称为 flip 和 flop。

利用 Switchboard 的一端开关的例子。
Smoke 测试在 16:57 和 17:07 进行。

Switchboard 在支配过程中很大程度上实现了流量从一个搜索端到另一个搜索真个自动迁移。
Smoke 测试在支配的不同阶段运行，向新的一端发送人工创建的和真实的历史搜索查询要求。
开拓职员只需监控图表，以确保滚动发布的事情顺利进行。

推动支配的工程师通过显示当前滚动发布状态的用户界面来管理 Switchboard，它还可以选择停息或者回滚支配。

在 Switchboard 中，我们紧张依赖 Kubernetes 内置的自动伸缩功能来扩展支配期间的新集群。
在开始向集群发送生产流量之前，我们已经创造，我们只须要先将集群的规模扩大到我们当前容量的 25%。

Kubernetes 内置的自动伸缩是被动的，因此与我们逼迫 Search 在须要额外容量之提高行伸缩比较，速率肯定要慢。
这样，它可以帮助提前扩展新的活动端，从而在该端上线并开始吸收流量时更快地相应初始转换。
通过 Switchboard，Kubernetes 可以管理自己的自动伸缩功能，只需监控 Kubernetes 的滚动发布，可以确保所有做事在当前阶段是康健的，然后再决定升级。

我们设计 Switchboard 是为了改进我们 Search 系统的资源花费，它已经做到了这一点。
然而，分步支配的方法也给开拓者带来了许多不错的事情流程改进。

Switchboard 使我们能够将搜索虚拟机的总容量掌握在或靠近 100%，而非我们以前所支持的 200% 的容量，随着 Search 流量的增加，我们再也不必供应双倍的容量了。
如今，适应流量的不安华变得更加随意马虎，由于任何额外的的被动（自动）或主动（手动）扩展只须要为我们的真实容量保留打算做事，而不是两倍。
以是，我们在发布 Switchboard 期间，云虚拟机的利用率有了明显的提高。

几个月来，每个搜索要求的云本钱（云计费总额 / 要求数）显示，我们在 Switchboard 之后，利用效率有所提高。

Switchboard 的第二大成功在于，它使得我们在 Staging 环境中的支配速率不断提高。
我们第一次考试测验放弃传统的双重配置方法，便是在两次支配之间完备缩减未利用的搜索集群，然后预先对其进行重新配置，作为下一个支配的第一步。
这种方法的一个问题便是，开拓职员必须等待我们的 Search 系统内的所有做事被扩展到足以接管流量，然后他们才能在我们的 Staging 环境中进行测试。

每个 Staging 环境支配所用的韶光。
每个单独的行是一个单独的支配。

总的来说，在履行 Switchboard 后，我们看到利用率的提高与中间办理方案相似，但却不必在较慢的支配韶光上做出妥协。
Switchboard 乃至还提高了中间办理方案的利用效率。

现在，在支配过程中创造和相应问题也变得更加随意马虎。
从技能上讲，Search 支配的韶光比我们掩护两个完备扩展的集群时要长，但是这个额外的韶光是由于自动流量滚动发布过程的渐进性造成的。
人类搜索支配职员常日是被动地监控滚动发布阶段，根本没有交互。
但是，如果他们须要的话，可以停息滚动发布，检讨当前的结果。
Search 支配职员至少每月利用一次 Switchboard 来停息滚动发布。
我们以前根本就没有这个选项。
由于 Switchboard 个别支配变得更加安全和可靠。

末了，重新架构我们的蓝绿支配流程，包括通过 Switchboard 进行金丝雀式的逐步流量提升，使我们的系统更具可扩展性和效率，同时也为开拓者供应了更好的体验设计。
为了充分利用 Kubernetes 和云环境的灵巧性，我们成功地调度了搜索运用的架构。