قابلية التوسع والتوافر العالي للتطبيق Java Standalone

Question

نقوم حاليا بتشغيل تطبيق تكامل Java على مربع Linux. أولا نظرة عامة على التطبيق.

تطبيق Java هو تطبيق مستقل (غير منتشر على أي خادم تطبيق Java EE مثل Oracleas، Weblogic، JBOSS ETC). من خلال الوقوف وحده أعني أنه ليس تطبيق سطح المكتب. ومع ذلك، يتم تشغيله من سطر الأوامر من فئة رئيسية. لا يتفاعل المستخدم مباشرة مع هذا التطبيق على الإطلاق. يتم إلقاء الرسائل في قائمة الانتظار باستخدام API الذي يتم قراءته بعد ذلك من خلال تطبيقي الذي يعمل باستمرار على مدار الساعة طوال أيام الأسبوع. لن أؤهل هذا كتطبيق سطح المكتب لأن المستخدم لا يوجد لديه تفاعل مباشر معه. (لست متأكدا مما إذا كان هذا هو السبب الصحيح للتأهل كواحد).

يستخدم الربيع والتواصل مع قاعدة بيانات WebSphere MQ و Oracle نستخدم مستمع الربيع (بروتوكور الربيع Pojos) يستمع إلى قائمة انتظار على WebSphere MQ. بمجرد وجود رسالة في قائمة الانتظار، يقوم التطبيق بقراءة الرسالة من MQ و Dumps (إدراج / تحديث) في قاعدة البيانات.

الآن السؤال هو:

1. كيف يمكننا أن نقياس هذا التطبيق أفقيا؟ أعني فقط وضع المزيد من الصناديق وتشغيل مثيلات متعددة من هذا التطبيق نفسه، هل هذا نهج قابل للحياة؟
2. يجب أن نفكر في الانتقال من MDPS الربيع إلى EJB MDBS؟ وبالتالي نشرها على خادم التطبيق. هل هناك أي فائدة إضافية من خلال القيام بذلك؟
3. هناك طلب لجعل التطبيق متاح (هكتار)؟ ما هي المنهجيات أو الاستراتيجيات المقترحة التي يمكن وضعها في مكانها لإجراء تطبيق مستقل هكتار؟

Answer 1

هل "مستقل" == "سطح المكتب"؟

كيف تتفاعل المستخدمون مع وحدة التحكم التي تمتلك الفاصوليا التي يحركها الرسالة؟

آرائي حول أسئلتك:

1. يمكنك التوسعات عن طريق إضافة المزيد من مستمعي الرسائل إلى تجمع المستمع، لأن كل واحد يعمل في مؤشر ترابطه الخاص. يجب أن تتطابق مع حجم تجمع اتصال قاعدة البيانات إلى مستمعي الرسائل، بحيث يتعين على ذلك زيادة كذلك. افعل ذلك قبل إضافة المزيد من الخوادم. تأكد من أن لديك ما يكفي من ذاكرة الوصول العشوائي في متناول اليد.
2. لا أرى ما يشتريه EJB MDB فوق MDB الربيع. يمكنك الاستمرار في الرجوع إلى "خوادم التطبيقات". هل تعني على وجه التحديد خوادم التطبيق Java EE مثل WeBlogic، WebSphere، JBoss، Glassfish؟ لأنه إذا كنت تقوم بنشر الربيع على Tomcat، فسوف أعتبر Tomcat "خادم التطبيق" في هذه المحادثة.
3. ها يعني تحميل موازنة وفشل. ستحتاج إلى وجود قواعد بيانات إما متزامنة أو إعادة تنظيم حديثة. نفسه مع قوائم الانتظار. F5 هو حل الأجهزة العظيمة لتحميل موازنة. سأتحدث مع أشخاص البنية التحتية الخاصة بك إذا كان لديك بعض.

Answer 2

خيار آخر هو Terracotta., ، إطار يدور على وجه التحديد ما تريد؛ تشغيل التطبيق الخاص بك على عدة آلات في وقت واحد وموازنة الحمل بينها.

Answer 3

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

حلول توافر عالية حقيقية مكلفة للغاية لتنفيذها. لقد رأيت درجات مختلفة من HA أيضا، ولكن بحكم التعريف، فهذا يعني الحد الأدنى المطلق أو عدم تعطل أو فقدان الوصول إلى مصدر البيانات. لتحقيق ذلك يتطلب الكثير من الأجهزة الزائدة والشبكات والبرامج التي تتمكن من استخدام الأجهزة الزائدة دون خسارة القدرة على الوصول إلى البيانات عندما تفشل أحد مصادر البيانات. فشل الأجهزة أمر لا مفر منه، وسوف يحدث ذلك، وكذلك انقطاع التيار الكهربائي وغيرها من أعمال الطبيعة العشوائية. اعتمادا على مدى أهمية هذه البيانات، سيتطلب حل HA أيضا مراكز بيانات متعددة على العديد من شبكات الطاقة المستقلة. الذي سيكون من الواضح أن يكون جدا باهظ الثمن، لذلك كل هذا يتوقف على مدى أهمية هذه البيانات على المستخدم النهائي.

لذلك، ها هو سيناريو متطرف يتطلب بنية باهظة الثمن. أجد أن معظم الوقت يهتم الناس بقليل التقليل من وقت التوقف، ويمكن تحقيق ذلك على حجم مصدر البيانات، حيث يمكن تحقيق ذلك إلى حد ما إلى حد ما مع إضافة قطع غيار ساخنة لمصادر البيانات.

Answer 4

1. التوسع الأفقي هو تطبيق مدفوع الرسالة سهل ... معظم الوقت. يمكنك بالتأكيد إضافة مستمع آخر آخر يعمل على نفس قائمة الانتظار. احترس، لأنك قد تكون لديك تبعيات خفية على طلب الرسائل. قد لا يكونوا مشكلة الآن، مع معالج واحد فقط، ولكن مع أكثر من واحد، من المضمون أن تتم معالجة الرسائل "خارج النظام" في مرحلة ما.
2. لا تقدم EJB MDPs أي شيء وراء MDBS الربيع. عصا مع ما يعمل.
3. تحجيم الأفقي المعالجات هي بداية، ولكن هذا يتطلب مناقشة أكثر قليلا.

بالنسبة إلى ها، تحتاج إلى توضيح المتطلبات. "توافر عالية" هو سؤال مثير للاهتمام للتطبيق القائم على قائمة الانتظار. إذا انخفض تطبيقك لبضع دقائق، فسوف يرتدي الرسائل في قائمة الانتظار. طالما يمكنك الحصول على التطبيق الخاص بك احتياطيا، ستظل هذه الرسائل معالجتها، فقط مع مزيد من الكمون. ربما يستحق السؤال، "ما هو الكمون الأقصى المقبول للرسالة؟"

ربما يكون هناك بعض مكونات القلق بشأن إخفاقات الأجهزة، وفقدان DataCenter، وما إلى ذلك، لن يتم تناولها من قبل القياس الأفقي في نفس الموقع. ستحتاج إلى تكرار جميع المكونات في كل طبقة: قائمة الانتظار نفسها، المعالجات وقاعدة بيانات الخلفية، وجميع أجهزة الشبكة التي توصلها.

إنه اقتراح باهظ الثمن، لذلك يستحق أيضا السؤال، "ما هي دلتا في حالة التوقع السنوية في التوقف بين سيناريو هكتار وسيناريو غير هكتار؟" يتضمن ALE سواء الخسائر المباشرة والتكاليف التنظيمية أو القانونية، لذلك فهي طريقة جيدة لالتقاط تكلفة التوقف.

Answer 5

.1. إنشاء المزيد من المستمعين في قائمة الانتظار يمكن أن يطاق عدد المستهلكين. كما يموت المستهلك، يمكن للمستهلكين الباقين الحفاظ على الجري. ملاحظة: تحتاج MQ وقاعدة البيانات إلى حلول توافر عالية أيضا.

.2. لست متأكدا من الفرق الذي سيجعله خادم التطبيق في قضيتك. ربما يمكنك شرح ما هي التي تنوي استخدامها؟

.3. انظر جوابي إلى 1. للحصول على هكتار.

Answer 6

هل حاولت صنع صناديق متعددة؟ أعتقد أنك قد ترى وثيقة MQ الخاصة بك؟ قد يحتاج تشغيل مربعات متعددة إلى بعض التكوين في MQ الخاص بك ولكنه سيتم تشغيل ISA