最前端

Appearance

概念 ​

CI 的英文全称是 Continuous Integration，中文翻译为：持续集成。是在源代码变更后自动检测、拉取、构建的过程。

CD 对应两个概念：持续交付 Continuous Delivery，持续部署 Continuous Deployment。是将应用部署到生产环境中或发布给最终使用用户的过程。

Jenkins ​

Github Action ​

应用部署 ​

蓝绿发布 ​

蓝绿部署是一种应用发布模式，可将用户流量从先前版本的应用或微服务逐渐转移到几乎相同的新版本中（两者均保持在生产环境中运行）。

旧版本可以称为蓝色环境，而新版本则可称为绿色环境。一旦生产流量从蓝色完全转移到绿色，蓝色就可以在回滚或退出生产的情况下保持待机，也可以更新成为下次更新的模板。

部署过程如下：

  1. 部署版本 V1 的应用（初始的状态），所有外部请求的流量都打到这个版本上
  2. 部署版本 V2 的应用，版本 V2 的代码与版本 V1 不同（新功能、Bug修复等）
  3. 将流量从版本 V1 切换到版本 V2
  4. 如版本 V2 测试正常，就删除版本 V1 正在使用的资源（例如实例），从此正式用版本 V2

从过程不难发现，在部署的过程中，我们的应用始终在线。并且新版本上线的过程中，并没有修改老版本的任何内容，在部署期间，老版本的状态不受影响，这样风险很小。并且只要老版本的资源不被删除，理论上，我们可以在任何时间回滚到老版本。

蓝绿发布的注意事项：

  • 当你切换到蓝色环境时，需要妥当处理未完成的业务和新的业务。如果你的数据库后端无法处理，会是一个比较麻烦的问题
  • 可能会出现需要同时处理微服务架构应用和传统架构应用的情况，如果在蓝绿部署中协调不好这两者，还是有可能会导致服务停止
  • 需要提前考虑数据库与应用部署同步迁移/回滚的问题
  • 蓝绿部署需要有基础设施支持
  • 在非隔离基础架构（VM、Docker 等）上执行蓝绿部署，蓝色环境和绿色环境有被摧毁的风险

优势：升级切换和回退速度非常快

不足：

  • 切换是全量的，如果 V2 版本有问题，则对用户体验有直接影响
  • 需要两倍机器资源

适用场景：

  • 对用户体验有一定容忍度的场景
  • 机器资源有富余或者可以按需分配（AWS 云，或自建容器云）

总结：这种持续部署模式原本存在不足之处。并非所有环境都具有相同的正常运行时间要求或正确执行 CI/CD 流程（如蓝绿部署）所需的资源。但是，随着企业加大对数字化转型的支持，许多应用开始支持这种持续交付。

金丝雀发布 ​

金丝雀发布（Canary）也是一种发布策略，和国内常说的灰度发布是同一类策略。蓝绿部署是准备两套系统，在两套系统之间进行切换，金丝雀策略是只有一套系统，逐渐替换这套系统。

灰度发布是指在黑与白之间，能够平滑过渡的一种发布方式。 AB Test 就是一种灰度发布方式，让一部分用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。 灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。

「金丝雀部署」是增量发布的一种类型，它的执行方式是在原有软件生产版本可用的情况下，同时部署一个新的版本。同时运行同一个软件产品的多个版本需要软件针对配置和完美自动化部署进行特别设计。

金丝雀部署的步骤如下：

  1. 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件
  2. 从负载均衡列表中移除掉「金丝雀」服务器
  3. 升级「金丝雀」应用（排掉原有流量并进行部署）
  4. 对应用进行自动化测试
  5. 将「金丝雀」服务器重新添加到负载均衡列表中（连通性和健康检查）
  6. 如果「金丝雀」在线使用测试成功，升级剩余的其他服务器。（否则就回滚）

优势：用户体验影响小，发布过程出现问题只影响少量用户

不足：发布自动化程度不够，发布期间可引发服务中断

参考资料 ​