Java 应用程序的零停机部署
我正在尝试构建非常轻量级的解决方案，以实现 Java 应用程序的零停机部署。为了简单起见，我们假设我们有两台服务器。我的解决方案是使用：
在“前面”——一些负载均衡器（软件）——我在这里考虑 HAProxy。
在“背面” - 两台服务器，都运行带有已部署应用程序的 Tomcat。
当我们即将部署新版本时
我们使用 HAProxy 禁用其中一台服务器，因此只有一台服务器（我们称之为服务器 A，它正在运行旧版本）可用。
在其他服务器（我们称之为服务器 B）上部署新版本，运行生产单元测试（如果我们有它们:-）并使用 HAProxy 启用服务器 B，同时禁用服务器 A。
现在我们再次只有一台服务器处于活动状态（服务器 B，带有新版本）。在服务器 B 上部署新版本，然后重新启用它。
有什么建议如何改进吗？如何自动化？
有现成的解决方案吗？还是我必须使用自己的自定义脚本？
谢谢！
I am trying to build the very lightweight solution for zero downtime deployment for Java apps. For the sake of simplicity lets think that we have two servers. My solution is to use:
On the "front" -- some load balancer (software) - I am thinking about HAProxy here.
On the "back" - two servers, both running Tomcat with deployed application.
When we are about to deploy new release
We disable one of the servers with HAProxy, so only one server (let's call it server A, which is running old release) will be available.
Deploy new release on other server (let's call it server B), run production unit tests (in case we have them :-) and enable server B with HAProxy, disabling server A at the same time.
Now we have again only one server active (server B, with the new release). Deploy new release on server B, and re-enable it.
Any advises how to improve? How automate?
Any ready made solutions or do I have to end up with my own custom scripts?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
滚动升级确实是一个很好的解决方案，前提是您的负载均衡器支持此选项（服务器饥饿）。
另一个解决方案是使用支持 OSGi 的应用程序服务器来热替换部分或整个应用程序。
我会推荐第一个。 SpringSource 的 AMS 监控控制台可以关闭 tcServer 集群（一个增强版的自定义 tomcat），IIRC 会自动进行滚动升级（但请检查文档）。
Rolling upgrade is indeed a good solution, provided your load-balancer supports this option (server starvation).
Another solution is to use OSGi-enabled application servers, to hot-replace parts or whole of your application.
I would recommend the first one. SpringSource's AMS supervision console can take down a cluster of tcServer (a custom tomcat on steroids), and IIRC do the rolling upgrade automatically (but check the docs).
我从这篇文章中找到了一些有趣的解决方案 关于零停机时间。我只想强调那篇文章中的几个解决方案。
1。 A/B切换：（滚动升级+回退机制）
我们应该有一组处于待机模式的节点。我们将把新版本部署到这些节点并立即将流量切换到它们。如果我们将旧节点保持在原始状态，我们也可以进行即时回滚。负载均衡器位于应用程序前端，负责根据请求进行此切换。
缺点：如果您需要X 个服务器来运行您的应用程序，那么使用这种方法就需要2X 个服务器。
2.零停机
通过这种方法，我们不需要保留一组机器；相反，我们延迟端口绑定。共享资源获取会延迟到应用程序启动为止。应用程序启动后会切换端口，旧版本也会保持运行（没有接入点），以便在需要时立即回滚。
3.并行部署 – Apache Tomcat：（仅适用于 Web 应用程序）
Apache Tomcat 已在其版本 7 中添加了并行部署功能。他们让应用程序的两个版本同时运行，并以最新版本作为默认值。
4。延迟端口绑定：
我们在这里建议能够在不绑定端口并且基本上不启动连接器的情况下启动服务器。稍后，一个单独的命令将启动并绑定连接器。当版本 1 正在运行并已绑定时，可以部署软件的版本 2。当版本2稍后启动时，我们可以解除版本1的绑定并绑定版本2。通过这种方法，节点实际上仅离线几秒钟。
5。高级端口绑定：
通过打破神话：“
地址已在使用中”，*旧进程和新进程均已使用。新进程将绑定到同一端口。 ON 模式下的 SO_REUSEPORT 选项允许两个（或更多）进程绑定到同一端口。一旦新进程绑定到端口，就杀死旧进程。SO_REUSEPORT 选项解决了两个问题：
应用程序版本切换之间的小故障：节点可以始终提供流量，从而有效地为我们提供零停机时间。
改进的调度：
总结：
通过结合后期绑定和端口重用< /em>，我们可以有效实现零停机。如果我们保留备用过程，我们也将能够进行即时回滚。
I have found some interesting solutions from this article regarding Zero downtime. I would like to highlight only few solutions in that article.
1. A/B switch: ( Rolling upgrade + Fallback mechanism )
We should have a set of nodes in standing by mode. We will deploy the new version to those nodes and switch the traffic to them instantly. If we keep the old nodes in their original state, we could do instant rollback as well. A load balancer fronts the application and is responsible for this switch upon request.
cons: If you need X servers to run your application, yon need 2X servers with this approach.
2. Zero downtime
With this approach, we don’t keep a set of machines; rather, we delay the port binding. Shared resource acquisition is delayed until the application starts up. The ports are switched after the application starts, and the old version is also kept running (without an access point) to roll back instantly if needed.
3. Parallel deployment – Apache Tomcat: ( For web applications only)
Apache Tomcat has added the parallel deployment feature to their version 7 release. They let two versions of the application run at the same time and take the latest version as default.
4. Delayed port binding:
we propose here is the ability to start the server without binding the port and essentially without starting the connector. Later, a separate command will start and bind the connector. Version 2 of the software can be deployed while version 1 is running and already bound. When version 2 is started later, we can unbind version 1 and bind version 2. With this approach, the node is effectively offline only for a few seconds.
5. Advanced port binding:
By breaking the myth: ‘
Address already in use’, *both old process & new process will bind to same port. SO_REUSEPORT option in ON mode lets two (or more) processes bind to the same port. Once the new process binds to the port, kill the old process.The SO_REUSEPORT option address two issues:
The small glitch between the application version switching: The node can serve traffic all the time, effectively giving us zero downtime.
Improved scheduling:
In Summary:
By combining both late binding and port reuse, we can effectively achieve zero downtime. And if we keep the standby process around, we will be able to do an instant rollback as well.
如果您可以容纳 OSGi 容器，请查看 OSGi 技术，因为它为 OSGi 包提供了良好的隔离和热部署。如果您使用 Spring 框架，您可以使用 Spring OSGi
Have a look at the OSGi technology if you can accommodate an OSGi container since it provides good isolation and hot deployment for OSGi bundles. If you are using the Spring framework you could use Spring OSGi
LiveRebel 提供滚动重启功能，提供 CLI API 和 Hudson/Jenkins 插件以实现自动化。
LiveRebel provides the functionality for rolling restarts, provides CLI API and Hudson/Jenkins plugin for automation.
easy-deploy 可以用 Docker 容器来实现这一点。
部署版本 1
要部署新版本，只需使用更新的标签名称运行命令即可。
披露：我构建了此工具。我构建它正是因为我找不到解决这个问题的简单解决方案。
There is easy-deploy that does exactly that with Docker containers.
Deploy version 1
To deploy a new version just run the command with the updated tag name
Disclosure: I built this tool. I built it exactly because I couldn't find a simple solution for this problem.