هل ترغب في النشر السريع لـ Java EAR لتقليل وقت توقف التطبيق على الخادم أو القضاء عليه؟

Question

لقد سمعت أن هذا هو ما يفعله JavaRebel ولكن هل هناك أي طريقة جيدة أخرى لنشر إصدار جديد من EAR مع السماح للمستخدمين بالبقاء نشطين في الإصدار السابق؟نستخدم JBoss لخادم التطبيقات ...

Answer 1

هذا ليس ما يفعله JavaRebel.يقوم JavaRebel (حسب الوصف) باستبدال الفئات الموجودة في الذاكرة بشكل سريع.وهذا غير مقبول في حالة الاتصالات الموجودة بالنظام، نظرًا لأن الفئات المحدثة قد تكسر منطق العميل.

ذات مرة واجهت إحدى الشركات التي كنت أعمل بها مشكلة مماثلة، وتم حلها بهذه الطريقة:

• تم استخدام جهاز التوجيه الذكي كموازن تحميل
• تم نشر الإصدار الجديد على 50% من عقد المجموعة (الجديدة).
• تم تسليم الاتصالات الجديدة بشكل صارم إلى هذه العقد المحدثة، وتمت موازنة الاتصالات القديمة بين العقد القديمة
• تم إخراج العقد القديمة من وضع عدم الاتصال (واحدة تلو الأخرى، للحفاظ على عدد العملاء لكل عقدة ضمن الحدود)
• وفي الوقت نفسه، تم نشر الإصدار الجديد على العقد "القديمة" غير المتصلة بالإنترنت وتم طرحها كعقد جديدة
• نظرًا لتجميع EJB، تم التقاط الجلسات والفاصوليا بواسطة العقد القديمة الأخرى
• في النهاية (في غضون ساعات قليلة)، لم يتبق سوى عقدة قديمة واحدة، تحتوي على نسخة واحدة من الإصدار القديم وتم توصيل جميع العملاء الذين يستخدمون الإصدار القديم بها
• عندما تم قطع اتصال آخر عميل قديم، تم إسقاط هذه العقدة أيضًا

الآن، أنا لست متخصصًا في الشبكات، ولا أستطيع أن أقدم لك الكثير من التفاصيل (مثل جهاز التوجيه وما إلى ذلك).ما أفهمه هو أنه يمكن إعداد هذا الأمر بسهولة تامة، باستثناء، إذا كنت أتذكر بشكل صحيح، كان علينا إعداد مجال Weblogic إضافي لنشر إصدارات جديدة من التطبيق (وإلا فإنه سيتعارض مع الإصدار القديم في أسماء JNDI).

امل ان يساعد.

ملاحظة.قدم Ichorus تعليقًا يقول فيه أن التطبيق منتشر على خوادم العملاء.لذلك قد تكون خدعة جهاز التوجيه غير ممكنة.الآن، أرى حلاً واحدًا قابلاً للتطبيق الآن (الساعة الآن 21:52، ربما أغفل بعض الأمور :)) --

• تطوير إصدار جديد بأسماء JNDI "ذات الإصدارات"؛على سبيل المثالإذا كانت وحدة العميل ضمن ejb/Customer في الإصدار 1، ففي الإصدار 2 ستكون ضمن ejb/Customer2
• لديك واجهة عمل في التطبيق بواجهة أساسية مستقرة (نمط المصنع) والتي، عند سؤالها عن وحدة العميل، تحاول العثور على اسم JNDI الأعلى إصدارًا (ليس في كل مكالمة، بالطبع، يمكن تخزينها مؤقتًا لمدة ساعة أو نحو ذلك) ).يمكن (ويجب) نشر هذه الواجهة كتطبيق منفصل - ولا يتم تحديثها مطلقًا أو نادرًا جدًا
• الآن سيتمكن كل عميل جديد من الوصول إلى أحدث التطبيقات المنشورة، ولن تتعارض التطبيقات.

يتطلب هذا النهج تخطيطًا واختبارًا دقيقًا، ولكن يجب أن يعمل IMHO.

لقد قمت مؤخرًا بتعديل بعض التطبيقات بطريقة مماثلة للسماح لها بالتواجد في نفس المجال (قبل استخدام نفس اسم JNDI لمصادر بيانات مختلفة).

Answer 2

كما أفهم، فإن WebLogic لديه ميزة تسمى النشر المتوازي للتخلص من وقت التوقف عن العمل أثناء ترقية إصدار EAR.يمكنك نشر الإصدار الجديد دون إيقاف التطبيق الحالي، وبمجرد نشر الإصدار الجديد بنجاح، يمكنك التبديل بشفافية من الإصدار القديم إلى الإصدار الجديد.

لست متأكدًا مما إذا كان خادم التطبيقات الآخر يدعم هذا أم لا.

المرجع: http://edocs.bea.com/wls/docs100/deployment/redeploy.html#wp1022490

Answer 3

واقتراح فلاديمير حول استخدام موازن تحميل هو وسيلة متأكد من تحقيق ما تريد. نضع في اعتبارنا، فإنه لا يلزم أن يكون بالضرورة الراقية تحميل الأجهزة موازن. بدلا من ذلك، إذا كنت أمام خادم جبوس مع خادم الويب الأصلي (أباتشي أو IIS) وmod_jk أو mod_proxy، يمكنك الحفاظ على واحد واجهة الويب المشتركة وتنفيذ التحميل والتوجيه الروتينية المعمول بها في وقت EAR الترقية.

و// نيكولاس

Answer 4

وأعتقد أنك قد ترغب في النظر في الربيع باستخدام إطار أو إس جي أي. http://www.springframework.org/osgi