在kubernetes和haproxy上部署带有java后端的单页web应用程序。

Question

我的团队(完全堆栈)团队开发单页web应用程序，使用react作为客户端，使用spring引导java应用程序作为后端。

我们将应用程序部署在kubernetes上。然而，我们有困难，使滚动更新库伯内特斯吊舱无缝。以下是我们的打包/部署过程：

1. CI管道构建一个码头映像，将java应用程序打包为一个可执行的jar文件，并编译形成react客户端的javascript/css资产。
2. 该映像有两个入口点:一个用于启动jar文件(java后端)，另一个用于启动为客户端资产(js/css)服务的nginx。
3. 基于URL路径的haproxy集群将请求路由到nginx或java后端。

到目前为止，这种方法工作得很好。

然而，在滚动更新过程中，将会有一些带有“旧”java后端的荚。这导致了新部署的react客户端向旧的java后端发出请求的情况，因为that只是将api流量路由到任何可用的java后端。

据我所知，have似乎支持基于某些规则的粘性后端，但这违背了为负载平衡而拥有一组后端的目的。

其他人是如何处理这个问题的？

Answer 1

在这个场景中实现无缝扩展的现代方法不是在负载平衡(即haproxy)方面，而是通过适当的部署规划、向后兼容性和/或特性标志。

负载均衡器修补的问题是，在一天的结束，即使你得到了棘手的会议正确，它不会解决你的问题。这样做的原因--想象一下，一个用户在浏览器中打开你的应用程序时会有旧的反应。在下面，部署新的java后端。如果用户不重新加载她的浏览器-她仍然将使用旧的反应应用程序与新的后端无论如何(仅仅因为javascript已经加载到浏览器)。

相反，看看下面的示例，您如何使用API版本控制来实现它：

• 让我们假设api端点上的数据模型将发生变化。
• 假设您以前的api是/v1 (甚至是非版本的)

下面是解决这个问题的方法：

1. 您可以创建api的/v2版本，在您的react应用程序中注册/v2版本。
2. 您的最新java后端仍然需要同时拥有/v1和/v2。
3. 首先使用/v2支持将所有java后端部署到后端部署(您的所有用户界面仍然是/v1，但这很好，因为最新的后端支持它)。
4. 一旦部署了所有后端，您就可以使用最新的映像启动用户界面部署(同样，由于所有后端都支持/v1和/v2，所以体验是无缝的)。

正如您所看到的，在上面的方法中，版本冲突是避免的，经验是无缝的。

附注：你可能想要考虑分割你的码头形象在2-这是有点奇怪，有一个多用途的图像与两个入口点。这种设计可能没有什么正当理由。