[译] 部署!=发布（第二部分）

• 原文地址：Deploy != Release (Part 2)
• 原文做者：Art Gillespie
• 译文出自：掘金翻译计划
• 本文永久连接：github.com/xitu/gold-m…
• 译者：Starrier
• 校对者：jasonxia23

将部署和发布解耦以下降风险，并解锁功能强大的工做流

在这系列的第一部分，我解释了咱们在 Turbine Labs 上用于上线、部署、发布和回滚的定义。我解释了部署风险和发布风险之间的差别。并且我还谈到了本地发布 —— 一种经常使用的用于将生产请求暴露给部署风险的部署/发布策略。本文中，我将讨论解耦部署风险与发布风险的方法，并简介用于管理发布风险的工做流。

蓝/绿（或部署!=发布）

蓝/绿部署涉及到在生产中发布版本的同时部署服务的新版本。你能够为每种“颜色”使用专用硬件或虚拟机，并在它们之间交替进行后续部署，也可使用容器或像 Kubernetes 这样的编排框架来管理临时进程。不管如何，关键在于一旦部署了新的（绿色）版本，它就不会被发布 —— 也不会响应生产请求。这些服务仍由目前已知的（蓝色）版本处理。

蓝/绿设置中的发布一般涉及更改负载均衡器，以添加新版本的主机并删除已知运行良好版本的主机。虽然这种方法比本地发布要好得多，但它也存在必定的局限性，特别是与发布风险有关的问题。首先，咱们来看看你如今能够作的一些很是强大的事情 —— 部署和发布是两个单独的步骤。

什么也没有

若是你的部署在崩溃循环回退中挂起，或数据库密钥错误而且新部署的服务没法链接，那么你不会承受作任何事情的压力。你的团队能够在没有愤怒用户或执行主管的压力状况下诊断问题或构建新版本，而后进行部署。在你空闲时重复操做，直到你有一个良好的部署。与此同时，已知发布的版本继续愉快地处理生产请求，而且你没必要共享公司博客上残缺部署的报告。换句话说，你的部署风险被彻底包含。

健康检查和集成测试

当部署与发布被拆分时，你能够在将任何流量暴露给它以前，针对新部署的版本运行自动化健康检查和集成测试。我参加了许多过后分析，其中最重要的一点是，过后部署/预发布健康检查等简单的事情能够有效防止发生面向客户的事件。

健康检查和测试蓝/绿部署。若是 v1.2 出现问题，客户不会被暴露在其中。

更细粒度的发布风险暴露

因为在引入新的“绿色”主机时，你不必定须要替换现有的“蓝色”主机，因此你有一些能够控制暴露新版本生成流量的百分比。好比。若是你有三台运行已知良好的服务版本，则能够在负载均衡器中为混合主机添加一台“绿色”主机。如今只有 25% 的流量暴露新版本，而不是已暴露的 33% 的主机。这仍然是粗粒度的发布风险管理，但总比没有好。

当你使一个“绿色”主机可用时，暴露该版本中任何错误流量的百分比则取决于主机的总数。这里是 33%。

持续性发布

正如我以上的讨论，从部署风险角度看，蓝/绿部署赢了。但当咱们考虑发布风险时，典型的蓝/绿设置处理版本的方式并不能为咱们提供咱们正在寻找的细粒度控制。若是咱们赞成生产中的每一个发布都是测试（无论赞成与否，它一直如此），而咱们真正想要的是使用模式匹配规则来分割咱们的生产请求，并动态路由任意百分比的流量到咱们服务的任何版本。这是一个强大的概念，它是构成复杂发布工做流的基础，如内部测试、增量发布、回滚和黑暗流量。每篇文章都分为上下两部分（即将推出！），但我在这里会尽量地总结它们。

内部测试是仅向员工发布新版本服务的流行技术。经过强大的发布服务，你能够编写诸如“将内部员工流量的 50% 发送到版本为 x.x 实例”的规则。在个人职业生涯中，生产中的内部测试捕获到了了比我不肯意认可的更多使人尴尬的错误。

增量发布是一个过程，从发送到新版本服务的一些小百分比生成请求开始，同时监视这些请求的性能 —— 错误、延迟、成功率等 —— 与以前的产品版本相比而言。当你确信新版本不会出现任何与已知良好版本相关的意外行为时，你能够增长百分比并重复此过程，直至到达 100%。

回滚使用持续性发布系统，只是将生产中的请求路由转发到仍然运行最后一个已知良好版本的实例。它速度快、风险低，而且像发布自己同样，能够经过细粒度方式有针对地完成。

黑暗流量是一种功能强大的技术。你发布的系统会复制生产请求，并将一个副本发送到你的服务已知的良好“轻量级”版本，另外一个发送到新的“重量级”版本。“轻量级”版本负责实际响应用户请求。“重量级”版本处理请求，但其响应会被忽略。当您须要在生产负载下测试新软件时，这很是有效。

在 Turbine Labs 中，咱们使用本身的产品 Houston 来完成内部测试，增量发布、回滚，并很快进行黑暗流量。对我来讲，像 Houston 这样复杂的发布系统对个人平常工做来讲是一种革命性改变。如此轻量级、低风险的发布，使得我能够常常这样作。做为一个团队，咱们将在之后的文章中更详细地介绍咱们在 Turbine Labs 的内部发布流程。

结论

在过去的五年中，上线软件的大部分技术和流程进展 —— 按需云计算、容器、编排框架、持续交付等 —— 都集中在部署原语上。有了这些进步，为你的服务设计和实现一个健壮的部署流程变得垂手可得，但设计和实现一个能够支持你服务需求的可靠性发布流程仍然十分困难。Facebook、Twitter 和 Google 致力于设计、实现和持续维护像 Gatekeeper、TFE 和 GFE 这样成熟的发布系统。这些系统不只在服务可靠性方面屡次证实了它们的价值，还包括开发者生产、产品速度和用户体验方面。

复杂的发布系统不只能够下降部署风险，还能够直接提升产品速度和用户体验。

咱们开始关注为各类规模的公司提供的便利的产品（Houston、LaunchDarkly）和开源工具（Envoy、Linkerd、Traefik、Istio），以及最近才向大型公司提供的原语和工做流。这些产品和工具使得人们能够更快速地发布功能，而且使咱们有信心不会对用户体验产生负面影响。

我是 Turbine Labs 的一名工程师，咱们正在构建 Houston —— 一项使构建和监控复杂的实时发布工做流程变得很是简单的服务。若是你但愿交付更多而且不用担忧，那么你绝对应该联系咱们！咱们很乐意与你交流。

感谢 Glen Sanford、Mark McBride、Emily Pinkerton、Brook Shelley、Sara 和 Jenn Gillespie 阅读本文的草稿。

另外一个翻译版本请见：juejin.im/post/5b03d4…

---

掘金翻译计划 是一个翻译优质互联网技术文章的社区，文章来源为 掘金 上的英文分享文章。内容覆盖 Android、iOS、前端、后端、区块链、产品、设计、人工智能等领域，想要查看更多优质译文请持续关注 掘金翻译计划、官方微博、知乎专栏。