docker - 单页应用程序 (SPA) 的零停机/蓝绿部署

Question

昨天，我们与团队一起讨论了使用零停机时间部署来支持我们的单页应用程序的可能性。

在讨论它时，我们确定了它的一个边缘案例。
用户在浏览器中加载页面后，在重新加载页面之前无法将其从内存中删除。这意味着如果用户加载页面并开始使用网站(例如开始像我现在所做的那样开始输入长文章)，那么在他重新加载页面之前，他无法接收到它的更新版本。

我们可以忽略用户在其浏览器中看到旧应用程序版本的事实，但下面列出了 2 点。

如果我们对用于服务 spa 的 HTTP Api 进行了重大更改，那么用户将无法保存他的文章(数据丢失!)或者在执行其他后端相关操作时可能会收到其他错误。

当用户在不重新加载 SPA 的情况下导航到新页面时，他可以收到下一页的模板或与外部旧容器不兼容的某些控件的模板。它可能会导致标记或应用程序逻辑损坏。

我们不能强制用户重新登录，因为他可能正在输入他的文章，这只是一个糟糕的用户体验。

考虑到所有这些要点，可以提出以下解决方案:

用户 1 将 SPA 的 v1 加载到他的浏览器中。

连同身份验证 token 一起，版本信息被发送到浏览器(例如使用 JWT)。

我们想要部署我们的应用程序的 v2 版本。我们启动了 v2 版本，但不禁用 v1。

用户 2 将 v2 的 SPA 加载到他的浏览器中

用户 1 转到 SPA 中的下一页。负载均衡器检查其 token 中的版本信息，并将用户 1 的流量路由到 v1 服务器。

用户 2 以相同的方式路由到 v2。

用户 1 注销应用程序并关闭浏览器。

用户 1 重新登录 - 这次他收到 v2。

在 v1 应用程序长时间没有收到任何流量后，它会被丢弃。

然而，在这种方法中，可以有多个版本，超过 2 个(例如，如果用户在一两天内保持在线)。这意味着在最后一个用户注销之前，我们将无法将数据库迁移到新模式(想象一下它如何适用于 Facebook 等网站)。拥有多个版本不是问题，但是像 Docker 和 Rancher 这样的工具让我们可以轻松地做到这一点。

同样在第 7 步中。用户需要重新加载页面或关闭浏览器——否则他仍将使用 v1，我们无法强制他进入下一个版本。

我的问题是您使用什么方法来进行零停机/蓝绿部署 单页应用程序 ?

您如何管理 生命周期 当您将流量切换到“绿色”版本时，应用程序的“蓝色”版本，尤其是对于现有的“蓝色”客户端应用程序。

你解决了这些问题，你知道其他的解决方案吗？

Answer 1

我一直在努力解决这个问题并尝试了几种方法，其中一种特别有效:

捆绑 SPA 时使用散列名称(包括图像等)

使用静态 Assets 存储桶(例如:AWS S3)并在部署过程开始之前将所有 Assets 上传到其中

强制执行内部准则，以尽量减少 API 契约(Contract)被破坏(即:端点的字段只能在 X 版本之后删除)

使用通常的蓝/绿策略部署

基本原理

使用带有散列捆绑包的存储桶可确保如果客户获得旧版本的 SPA，其所有 Assets 将在任何部署过程之前/期间/之后可用。
强制执行内部准则以不破坏 API 兼容性有时很棘手，但它来自适用于任何公共(public) API 的相同原则。通过具体示例与团队沟通时，接受/调整来自大玩家的 API 弃用政策会有所帮助。