Linux环境下Spring Boot可执行Jar在线替换运行版本方案咨询

Hey Avi, great question! Yes, there are several practical ways to swap out a running Spring Boot JAR for a new one without a full stop-and-restart cycle that causes downtime. Let’s walk through the most reliable approaches, sorted by use case:

If you’re running your app as a systemd service (the standard for Linux), you can configure it to handle graceful shutdown and automatic restart with the new JAR. Here’s how:

• First, ensure your Spring Boot app is set up for graceful shutdown. Add these lines to your application.properties or application.yml:

  server.shutdown=graceful
  spring.lifecycle.timeout-per-shutdown-phase=30s
  

  This tells the app to finish processing in-flight requests before shutting down, instead of terminating abruptly.
• Update your systemd service file (usually located at /etc/systemd/system/your-app.service) to include a reload command that triggers a graceful restart. Modify the [Service] section:

  [Service]
  ExecStart=/usr/bin/java -jar /opt/your-app/your-app.jar
  ExecReload=/bin/sh -c 'cp /opt/your-app/new-your-app.jar /opt/your-app/your-app.jar && kill -SIGTERM $MAINPID'
  Restart=always
  

• Now, when you’ve copied the new JAR to /opt/your-app/new-your-app.jar, run this command to trigger the swap:

  sudo systemctl reload your-app.service
  

  Systemd will replace the old JAR with the new one, send a SIGTERM to the running process (triggering graceful shutdown), then automatically restart the service with the updated JAR.

This is the gold standard for production environments because it eliminates any risk of downtime or failed reloads. Here’s the workflow:

• Keep your existing (blue) instance running on its usual port (e.g., 8080).
• Start the new (green) instance of your app on a different port (e.g., 8081) using the new JAR.
• Run thorough tests on the green instance to confirm it’s working correctly.
• Update your reverse proxy (like Nginx) to route all incoming traffic to the green instance instead of the blue one.
• Once traffic is fully shifted, you can stop the blue instance, replace its JAR with the new version (in case you need to roll back later), or retire it entirely.
• If you run into issues with the green instance, just switch the proxy back to the blue instance—rollback is instant.

If you’re working in a dev or staging environment and want quick reloads, Spring Boot’s DevTools is perfect:

• Add the DevTools dependency to your build file. For Maven:

  <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-devtools</artifactId>
      <scope>runtime</scope>
      <optional>true</optional>
  </dependency>
  

• Build your new JAR and copy it to the same location as the old one. Then use the Maven restart goal to reload the app:

  mvn spring-boot:restart
  

  DevTools will detect the JAR change and reload the application context without a full system service restart. Note: This is not recommended for production—it’s designed for rapid development cycles, not stability.

• Always test any of these approaches in a staging environment before deploying to production.
• Ensure your app handles state properly (e.g., uses external caches/databases instead of in-memory storage) so that a reload or instance swap doesn’t cause data loss.
• For microservices setups, you can extend the blue-green approach using service registries (like Eureka) and dynamic routing (Spring Cloud Gateway) to gradually shift traffic to new instances.

内容的提问来源于stack exchange，提问作者Avi Elgal