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

ger*_*ome 6 downtime usersession single-page-application blue-green-deployment docker

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

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

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

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

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

  1. 用户1将SPA的v1加载到他的浏览器中.
  2. 除了auth令牌之外,版本信息也会发送到浏览器(例如使用JWT).
  3. 我们想部署应用程序的v2版本.我们启动v2版本,但不禁用v1.
  4. 用户2将SPA的v2加载到他的浏览器中
  5. 用户1进入SPA的下一页.负载均衡器检查其令牌中的版本信息,并将用户1的流量路由到v1服务器.
  6. 用户2以相同的方式路由到v2.
  7. 用户1注销应用程序并关闭浏览器.
  8. 用户1登录 - 这次他收到v2.
  9. v1应用程序长时间没有收到任何流量后会被处理掉.

然而,在这种方法中,可以使多个版本存活,超过2个(例如,如果用户在一整天或两天内保持在线).这意味着在最后一个用户注销之前我们将无法将数据库迁移到新架构(图像如何对Facebook等网站起作用).拥有多个版本不是问题,但Docker和Rancher等工具可以让我们轻松完成.

同样在步骤7.用户需要重新加载页面或关闭浏览器 - 否则他仍将使用v1,我们不能强迫他进入下一个版本.

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

当您将流量切换到"绿色"版本时,如何管理应用程序的"蓝色"版本的生命周期,尤其是在现有的"蓝色"客户端应用程序方面.

你有没有解决这些问题,你知道其他任何解决方案吗?

小智 6

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

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

基本原理

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


Ber*_*ard -3

您所描述的技术称为蓝绿部署;您从现有服务器(蓝色)开始,然后添加更新的服务器(绿色)。从那时起,所有新流量都将被重定向到绿色环境。蓝色环境仅用于为现有的 http 连接提供服务,并且还可以在绿色环境遇到重大问题时进行可选的“回滚”。最终,“蓝色”环境可以在完成所有请求的服务后退出。

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