改善十年应用的部署体验

在2018年 , Etsy将它的服务基础设施从自我管理的数据中心迁移到云端配置(我们当时在博客上写了这件事) 。 这种改变提供了改善整个公司技术流程的机会 。 对于Search团队而言 , 云环境所带来的灵活扩展让我们可以完全重新评估一个有些繁琐的部署流程 。 在已有的金丝雀发布架构模式的启发下 , 我们编写了一个新的自定义工具来补充现有的部署基础设施 。
在三个月的努力之后 , 我们最终得到了一个更具可扩展性、对开发人员更友好、最终也是更健壮的方式来滚动发布对Search的改变 。
蓝绿部署
过去 , 我们把堆栈部署到两套独立的主机上 , 也就是所谓的“蓝绿策略” 。 在任何时候 , 只有一组主机是活动的;而另一组 , 或''侧端''则处于“黑暗”状态 。 这两边都是完全扩展的 , 并准备好为流量提供服务 , 但只有活动的那一组可以进入公共互联网 。
蓝绿部署策略虽然简单 , 但具有一些非常有用的特性:
对于搜索应用 , 我们可以在一边做重要的改变 , 因为它是有状态的 , 同时持续地使用另一边来提供流量 。 在将生产流量发送到它之前 , 我们有地方可以手动测试更改 。 我们总是有一个以前的Search版本 , 在紧急情况下 , 我们可以轻松恢复 。 还有一个内置的机制 , 可以测试和产生其他突破性的变化 , 比如软件版本升级 。 【改善十年应用的部署体验】我们将这两组主机称为“flip”和“flop” , 这是以现代计算机的基本构件——电路命名的 。 在配置文件中 , 我们通过几行代码 , 将单个PHPWeb应用指向哪一组 , 哪一组就应该处于活动状态 。
改善十年应用的部署体验
文章图片
图为我们之前的基础设施 。 一组(本例中的flop)始终处于活动状态 , 在部署过程中 , 我们会将所有的流量一次性转移到另一组(本例中的flip) 。
三年前 , Etsy向云端迁移时 , 这种蓝绿部署的方法被“提升和转移” 。 Search团队将搜索应用移至谷歌Kubernetes引擎(GoogleKubernetesEngine , GKE) , flip和flop成为两个独立的生产Kubernetes命名空间 。
撇开这一变化不谈 , 事情的运作与以往一样:部署Search会立即触发所有的流量从一个命名空间——活动端——重定向到另一个命名空间中运行的同一服务 。 为了确保黑暗端始终准备就绪 , 我们将继续在任何时候都保持200%的容量(每个生产命名空间100%) , 正如我们在企业内部时所做的那样 。
这种最初的部署策略对团队来说非常有用 , 尤其是为我们提供了一个安全的空间 , 可以测试和准备主要的软件更新和基础设施变更 。 然而 , 它也并非没有痛苦 。 突然间 , 所有流量都被转移到两边 , 这使得我们没有余地在全部投入之前测试少量生产流量的变化 。 甚至在一切顺利的时候 , 部署也是充满压力的 。 如果情况出了问题 , 工程师们就得进行分流 , 来决定是否要完全恢复原状 。 最重要的是 , 长时间维持双倍容量既昂贵又低效 。
因为云计算提供了灵活性 , 一旦我们安全地进入GKE , 我们就有机会重新考虑我们的蓝绿策略 , 并解决这些长期存在的问题 。
金丝雀(精简版)
我们的第一个想法是采用金丝雀部署策略 。 在“金丝雀发布”期间 , 在将所有流量切换到新服务之前 , 将一小部分流量发送到服务的新版本 , 以确定它是否“安全” 。
为什么叫这个名字?煤矿工人曾经使用金丝雀来检测一氧化碳的浓度 , 这种浓度可能会伤害一只小鸟 , 但仍不会对人造成伤害 。 软件工程师们也采取了类似的模式(尽管更加人性化) , 以树立新软件能够安全地服务于流量的信心 。