开发者

Best practices in terms of replacing a web service?

开发者 https://www.devze.com 2023-01-04 18:17 出处:网络
So we have a busy legacy web service that needs to be replaced by a new one. The legacy web service was deployed using a WAR file on an apache tomcat server. That is it was copied over into the web ap

So we have a busy legacy web service that needs to be replaced by a new one. The legacy web service was deployed using a WAR file on an apache tomcat server. That is it was copied over into the web apps folder under tomcat and all went well. I have been delegated with the task to replace it and would like to do it ensuring

  1. I have a back up of the old service
  2. the service gets replaced by another WAR file with no down time

Again I know I am being overly cautious however it is production level and I would like everything to go smooth. Step by step 开发者_StackOverflowinstructions would help.


  1. Make a test server
  2. Read tutorials and play around with the test server until it goes smoothly
  3. Replicate what you did on the test server on the prod server.

If this really is a "busy prod server" with "no down time", then you will have some kind of test server that you can get the configuration right on.


... with no down time

If you literally mean zero downtime, then you will need to replicate your webserver and implement some kind of front-end that can transparently switch request streams to different servers. You will also need to deal with session migration.

If you mean with minimal downtime, then most web containers support hot redeployment of webapps. However, this typically entails an automatic shutdown and restart of the webapp, which may take seconds or minutes, depending on the webapp. Furthermore there is a risk of significant memory leakage; e.g. of permgen space.

The fallback is a complete shutdown / restart of the web container.

And it goes without saying that you need:

  • A test server that replicates your production environment.
  • A rigorous procedure for checking that deployments to your test environment result in a fully functioning system.
  • A preplanned, tested and hopefully bomb-proof procedure for rolling back your production system in the event of a failed deployment.

All of this (especially rollback) gets a lot more complicated when you system includes other stuff apart from the webapp; e.g. databases.

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号