9

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

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

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

  1. 如果我们对用于服务 spa 的 HTTP Api 进行重大更改，那么用户将无法保存他的文章（数据丢失！）或者在执行其他后端相关操作时可能会收到其他错误。
  2. 当用户在不重新加载 SPA 的情况下导航到新页面时，他可以收到下一页的模板或与外部旧容器不兼容的某些控件的模板。它可能会导致标记或应用程序逻辑损坏。
  3. 我们不能强迫用户重新登录，因为他可能正在输入他的文章，这只是一个糟糕的用户体验。

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

  1. 用户 1 将 SPA 的 v1 加载到他的浏览器中。
  2. 连同身份验证令牌一起，版本信息被发送到浏览器（例如使用 JWT）。
  3. 我们想要部署我们的应用程序的 v2 版本。我们启动了 v2 版本，但不禁用 v1。
  4. 用户 2 将 v2 的 SPA 加载到他的浏览器中
  5. 用户 1 转到 SPA 中的下一页。负载均衡器检查其令牌中的版本信息，并将用户 1 的流量路由到 v1 服务器。
  6. 用户 2 以相同的方式路由到 v2。
  7. 用户 1 注销应用程序并关闭浏览器。
  8. 用户 1 重新登录 - 这次他收到 v2。
  9. 在 v1 应用程序长时间没有收到任何流量后，它会被丢弃。

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

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

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

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

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

4

4 回答 4

6

我已经为这个问题苦苦挣扎了很长一段时间，并尝试了几种方法，其中一种特别有效：

  • 捆绑 SPA 时使用散列名称（包括图像等）
  • 使用静态资产存储桶（例如：AWS S3）并在部署过程开始之前将所有资产上传到其中
  • 强制执行内部准则以尽量减少 API 合同被破坏（即：端点的字段只能在 X 版本之后删除）
  • 使用通常的蓝/绿策略进行部署

基本原理

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

于 2018-05-09T20:05:21.383 回答
2

您可能会考虑的一种方法是在这样的时刻逐渐重新加载 SPA，此时它对最终用户来说不是负担（甚至不明显）。

建议的方法：

系统的彩色版本（提供后端服务、API 和前端的组件）“知道”（提供运行时）它们的“颜色”。为用户提供前端应用程序的组件将此颜色信息嵌入到 SPA 中。然后（通过 cookie 或自定义 HTTP 标头）将其与 SPA 向后端发出的每个请求一起发送。

路由 API 调用的组件（API 网关、负载均衡器、nginx、HAproxy、基于 Zuul 的自定义路由器等）知道此颜色信息，并使用它来将流量引导到适当颜色的基础设施。

此外，还有一个带有最新版本颜色的公共 URL（不是由“彩色”基础设施提供的 - 例如通过 CloudFront 或其他代理提供的 S3 文件）。SPA 每给定时间段（60 或 120 秒）检查此版本。如果版本与加载时提供的一个 SPA 不匹配，则在主要的下一个路由更改页面上“物理地”重新加载，而不是仅在浏览器中实现此导航。

您可以选择哪些路由更改正在验证此版本，以使其对用户来说最不显眼（可能几乎不引人注意）。

如果您选择所有用户每天使用的一些路线，那么很快所有用户都会迁移到最新的颜色。长时间不使用打开的浏览器窗口（计算机休眠两周？）可以通过在一段时间不活动后强制重新加载来处理。

我希望我终于设法让自己听起来有点凝聚力:-)

问候， Wojtek

于 2018-09-07T14:22:02.977 回答
0

不知道为什么要对 UI 进行全面检修，因为它们总是涉及到学习曲线。实际上，在现实世界中，立即切换到新 UI 是个坏主意。您将允许客户在一段时间内切换到新界面，然后在预警后禁用旧版本。不值得为这样的实时切换付出努力。A/B 测试可能是向客户介绍新界面然后进行实际部署的一种方式。

于 2018-01-26T16:02:19.430 回答
-2

您描述的技术称为蓝绿部署；您从现有服务器（蓝色）开始，然后添加更新的服务器（绿色）。从那时起，所有新流量都被重定向到绿色环境。蓝色环境仅用于为现有的 http 连接提供服务，也用于可选的“回滚”，以防绿色环境遇到重大问题。最终，当“蓝色”环境完成所有请求的服务后，它可以退役。

这种技术要求两个系统有些相似。例如，数据库模式可能使其不切实际。

于 2016-10-05T11:31:17.297 回答