现在的大多数应用程序都是可扩展的、分布式的，并主要部署在一些云基础设施上。对应用程序的更新也以狂热的速度推送到生产中。
一般来说，大多数的升级需要有这些特征
- 生产环境的零停机时间。
- 有能力回滚变化（如果需要）。
在这篇文章中，我们将研究一些这样的策略
-Rolling 部署
-Blue-Green 部署
-Canary 部署
-Shadow 部署
1.0 滚动式部署
- 这是一种分阶段的部署方式，新版本的应用程序以滚动的方式一次一次地部署在生产服务器上。
- 因此，可能有一段时间，当用户流量被重定向到新旧版本的代码时（在实时生产环境中并存）。
- 优点
- 零停机时间
- 易于设置，没有额外的基础设施成本 - 缺点
- 无法管理新旧节点之间的用户流量
- API/代码需要向后兼容（尤其是数据库模式的变化）--因为两个版本的代码应该能够同时在生产中工作。
- 回滚很慢。
2.0 蓝绿部署
- 创建一个完整的生产环境的新副本，并在其上部署新的应用程序。
- 新旧系统继续并行运行，所有的用户流量仍然流向旧的应用程序。
- 当应用团队对新环境的稳定性有信心时，负载平衡器/路由器就会把所有的用户流量导向新的应用。
- 两个应用程序可以使用相同的数据库后端，或者使用复制的数据库--这样两个环境就始终是同步的。
- 优点
- 生产部门一次只支持1个活动版本的应用程序。
- 通过将所有的用户流量再次路由到旧的应用程序，可以立即进行回滚。 - 缺点
- 基础设施成本（因为需要建立生产环境的完整副本）。
- 开销更大，因为在某些时候需要监控两个环境。
3.0 金丝雀部署
- 它几乎类似于蓝绿色部署--唯一的区别是只有一小部分用户首先被切换到新的应用程序。
- 而不是让新的应用程序版本完全上线--只有一小部分用户被慢慢转移到新的应用程序。
- 被转移到新应用程序的用户可以是
- 随机的 - 例如，将5%的用户流量转移到新应用程序
- 基于地理位置或IP地址范围。
- 或者可能只发布给一组内部用户，等等。 - 只有当子集的用户对新版本做了充分的测试后，该应用才会向所有人发布。
- 优点和缺点- 几乎与蓝绿色部署相同，缺点是升级到新的应用程序版本非常慢（上线时间）。
由于金丝雀部署的主要想法是只让一部分用户接触到新的应用程序，它并不总是需要通过创建一个全新的环境来完成。
金丝雀部署也可以通过 "instance-based"来完成，新版本的应用程序被部署在选定的应用程序实例上，所有来自子集用户的请求都被重定向到这个新实例。
下图描述了另一种我们可以做金丝雀部署的方式。
术语 "金丝雀部署 "来自于 一种古老的煤矿开采技术。
煤矿一般会含有像一氧化碳这样的危险气体，这些气体较难被人类发现，并会影响矿工。人们发现金丝雀更敏感，也是一个更有效的指标，因为它们显示出更明显的遇险迹象。
矿工就会派出金丝雀作为早期探测器，以确保矿工的安全。
4.0 影子部署
- 在影子部署中，为新版本的应用程序创建一个新的影子环境（就像在蓝绿部署中一样）。
- 然而，整个用户流量被路由到新的和旧的应用程序 - 基本上分叉出所有进入旧应用程序的请求，并将它们发送到新的应用程序。
- 优点
- 可以在实际生产负载下对新的应用程序进行性能测试。
- 可以推迟新应用程序的实际推出，直到完全稳定。 - 缺点
- 基础设施成本增加
- 设置复杂
- 必须避免副作用，例如，如果付款请求被路由到两个应用程序，那么付款不应该被扣除两次。
分享这一点。
喜欢这个。
Like Loading...
