Deploy Strategy

Deploy Strategy

  • 2019-02-25

Table of content:

About

因为工作的一部分是提供 CI， CD，PaaS 平台，所以这篇文章主要是做一些部署策略的归类和分析总结，同时对业其他公司的方案进行调研。

部署模式

大爆炸

「大爆炸」部署一次性更新整个应用或者其中的大部分, 要求企业在发布之前进行广泛的开发和测试，通常和大型有序发布的「瀑布模型」有关。

大爆炸部署的特点包括：

所有的主要部件都打包在一个部署中；

  • 用新的软件版本整个替换现有的版本，或者替换大部分；
  • 部署通常会导致长时间的开发和测试周期；
  • 假定失败的可能性很小，因为回滚是不可能和不现实的；
  • 完成时间通常需要很久，需要多个团队的共同努力；
  • 需要客户采取措施来更新客户端安装。

持续集成，持续交付，持续部署

使用更敏捷的方式进行变更，比如持续集成，持续部署。更小而快的方式进行迭代, 提前发现问题。

  • 持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，确定新代码和原有代码能否正确地集成在一起。
  • 持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
  • 持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。

Ref:

常见的部署策略

部署策略描述优势劣势适用场景
Rolling upgrade滚动部署, 每次发布时，先将老版本 V1 流量从 Load Balance 上摘除，然后清除老版本，发新版本 V2，再将 Load Balance 流量接入新版本。用户体验影响小，体验较平滑, 相对蓝绿发布节省机器或者容器资源发布和回退时间比较缓慢适用于资源比较紧张，对速度没有太大要求，但是服务又不能中断的部署场景
Blue/Green Deployment不能中断的业务场景升级切换和回退速度非常快需要两倍的资源机器资源有富余或者可以按需分配
Canary Deployment金丝雀发布, 先发布小流量作为验证出现问题影响的比例较小这样的发布会耗费一定的时间正式发布之前的验证
Reckless Deployment先将老版本 V1 全部下掉，再将新版本发到机器上去。这种方式会引入服务中断简单成本低服务中断用户受影响，出了问题回滚也慢测试环境或者一些不重要的服务

Rolling Upgrade


滚动部署，逐渐用新版本替换旧版本, 最大限度的降低相关风险，包括面向用户的停机时间。
在此期间，新旧版本会共存，而不会影响功能和用户体验。这个过程可以更轻易的回滚和旧组件不兼容的任何新组件。

每次发布时，先将老版本 V1 流量从 LB 上摘除，然后清除老版本，发新版本 V2，再将 LB 流量接入新版本。

Blue/Green Deployment

蓝绿部署，也就是会同时存在两个版本，如果绿色版本激活后发现了问题，则将流量路由回到蓝色版本中。
蓝绿部署依赖流量路由。这可以通过更新主机的 DNS CNAMES 来完成, 也可以通过 HAProxy。

老版本通常会保留一定时间用作快速回滚。

Canary Deployment

金丝雀部署的主要挑战是设计一种路由部分用户到新应用的方法。

探索一些技术，来考虑路由新用户的方法：

  • 在允许外部用户访问之前，将内部用户暴露给金丝雀部署；
  • 基于源 IP 范围、特定地理区域发布应用，或者直接按照一定比例随机

在实践过程中发现，要做好金丝雀有以下的经验总结：

  • 用不同的金丝雀的规模来达到不同的效果，比如小金丝雀用来验证是否有 typo，key error 以及其他错误，大金丝雀用来验证性能以及一些不明显的问题
  • 提供清晰的金丝雀报表，让金丝雀等待的时间更有价值，同时让金丝雀期间发现的问题重复被发现
  • 增加核心的指标，让金丝雀期间的表现更全面分析，同时提供自动回滚的机制，减少人工参与。

Reckless Deployment

简单粗暴，先杀后起，不管杀掉之后后果是什么。会带来服务的中断，通常用在测试环境或者是不是很重要的应用上。

其他发布方式

功能开关

利用代码中的功能开关（Feature Flag/Toggle/Switch）来控制发布逻辑，一般不需要复杂的发布工具和智能 Load Balance 配合，是一种相对比较低成本和简单的发布方式。

优势是切换比较灵活可控，切换成本也比较低。但是对代码有侵入，需要定期清理老的逻辑，代码维护成本大。适用于一些需要灰度新功能，或者针对部分用户开发的功能。

A/B 测试

和功能开关很相似，但是通常会是两组或多组方案上线，对比。通常需要一个专门的 A/B 测试的管理平台。

流量复制

对于一些涉及核心业务的遗留系统的升级改造，为了确保万无一失，有一种称为影子测试的大招，采用比较复杂的流量复制、回放和比对技术实现

影子测试因为旁路在独立测试环境中进行，可以对生产流量完全无影响, 实施的成本也比较高。适用于一些核心的组件升级。

比如一些开源的方案：

业内的方案 (持续更新)

Netflix 金丝雀

Netflix 开源了一个自动的金丝雀分析工具, 叫 kayenta,

kayent 会根据一些关键的指标来判断金丝雀的版本是否通过，如果不能就将金丝雀自动回滚。如上图，接受生产流量的会有三个集群：

  • production cluster，当前的生产环境的版本，instance 数量比较多且由用户配置
  • canary cluster, 金丝雀的版本，通常是新的代码或者配置改动，通常也只有三个 instances
  • baseline cluster, 和生产环境是一个版本，只有三个 instances。（用来作 canary cluster 的对照组）

部署系统 Spinnaker 会来决定当前金丝雀是否满足标准以及是否要回滚，基于 httpcode, load avg, 错误，响应等指标, 同时提供一些金丝雀质量的分析。


相关文章：

Reference

关于头图

拍摄自水魔方

Run sshd in Docker container
2019 年 2 月摘要