2011-09-20 2 views
4

Notre production fonctionne sur LB + TOMCAT, Nous utilisons notre propre outil sur mesure SAFE-DEPLOY pour déployer les changements dans la production.Comme notre système est engagé à fournir la disponibilité 24/7, l'outil déploie les modifications comme suitComment faire grâce à déploiement à chaud sur Tomcat (non-stop)

Le nombre total de serveurs utilisés pour un service particulier est divisé en groupes. Supposons qu'il est divisé en 2 groupes et qu'ils arrêtent un groupe, déploient des changements et démarrent le groupe. Une fois le premier groupe terminé, ils déploient des modifications sur l'autre groupe. Dans la plupart des cas, cela fonctionne correctement sans problème.

Le problème est dû à un cas particulier. Un service génère un jeton que le client prend comme identifiant, maintenant nous avons changé le format du jeton, si nous utilisons la même approche de déploiement, il devrait y avoir des problèmes potentiels.ie.group1 arrêter et déployer le nouveau code puis redémarrer (c'est OK), stop group2 (Préparez-vous à déployer du nouveau code), maintenant erreur peut se produire lorsque groupe2 déploie, car pendant ce temps groupe1 peut recevoir l'ancien jeton de format généré par groupe2 (1.when groupe1 est en cours de déploiement, groupe2 ancien code, 2.group2 est arrêté ne peut pas demande de processus), le client reçoit une erreur qui indique que le jeton est incorrect, mais ce n'est pas un jeton erroné. J'ai une solution est, rendre notre code peut traiter à la fois nouveau jeton de format et ancien jeton de format, mais génère seulement un nouveau jeton de format, après un jour de fonctionnement, nous pouvons faire un déploiement qui traite uniquement nouveau jeton de format. Je suppose que cela fonctionne bien, mais ce n'est pas grâce.

Ma question, y at-il une approche de déploiement en grâce qui permet au serveur de gérer à la fois l'ancien jeton formaté qui a été généré et le nouveau jeton formaté sans aucun changement de code.

BTW: Je trouve une référence, best practice hot deploy on tomcat, cela ne fonctionne que pour tomcat 7, notre tomcat de travail est 6.0.26.

Répondre

0

Oui, il peut y avoir une seconde méthode. D'abord vous activez les sessions collantes sur le loadbalancern (apache + mod_jk). Cela signifie qu'un client se connecte toujours avec le même serveur. Deuxièmement, vous désactivez (n'arrêtez pas) le worker (serveur). Seules les sessions existantes seront servies, aucune nouvelle. Si le travailleur n'a plus de sessions ouvertes, vous arrêtez le travailleur, mettez à jour le travailleur et activez le travailleur sur les LB. C'est le cas, mais je suggère votre chemin.

Questions connexes