उच्च उपलब्धता अनुप्रयोग बनाने में कौन सा डिज़ाइन पैटर्न सबसे अधिक लीवरेज किए गए हैं?

Question

इसी तरह डिज़ाइन पैटर्न भी हैं जिन्हें टालना चाहिए?

Answer 1

मुझे लगता है कि आप एक सर्वर प्रकार का आवेदन लिख रहे हैं (कुछ समय के लिए वेब ऐप्स छोड़ दें - शेल्फ समाधान से कुछ अच्छे हैं जो वहां मदद कर सकते हैं, इसलिए देखते हैं कि "मुझे यह शानदार नया प्रकार मिला है सर्वर मैंने लिखा है ", लेकिन मैं इसे एचए समस्या होना चाहता हूं)।

सर्वर कार्यान्वयन में, क्लाइंट से अनुरोध आमतौर पर (किसी रूप में या किसी अन्य रूप में) कुछ ईवेंट या कमांड प्रकार पैटर्न में परिवर्तित होते हैं, और फिर एक या अधिक कतारों पर निष्पादित होते हैं।

तो, पहली समस्या - घटनाओं/आदेशों को क्लस्टर में जीवित रहने की आवश्यकता है (यानी जब एक नया नोड मास्टर के रूप में कार्य करता है, तो यह अगले आदेश को निष्पादित करने और शुरू करने की आवश्यकता है)। ।

एक भी लड़ी सर्वर impl के साथ शुरू (सबसे आसान करने देता है -। और अवधारणाओं अभी भी करने के लिए मल्टी-थ्रेडेड लेकिन इसकी issues0 के स्वयं के सेट मिल गया जब एक आदेश संसाधित किया जा रहा लेनदेन प्रसंस्करण के कुछ प्रकार की जरूरत लागू

एक और चिंता साइड इफेक्ट्स का प्रबंधन कर रही है और आप वर्तमान कमांड की विफलता को कैसे संभालेंगे? जहां संभव हो, लेनदेन के तरीके से दुष्प्रभावों को संभालें, ताकि वे सभी या कुछ भी न हों। यानी यदि आदेश राज्य चर बदलता है, लेकिन आधा रास्ते दुर्घटनाग्रस्त हो जाता है निष्पादन, "पिछला" स्थिति में वापस लौटने में सक्षम होना बहुत अच्छा है। यह नए मास्टर नोड को क्रैश किए गए कमांड को फिर से शुरू करने की अनुमति देता है और केवल आदेश को फिर से चलाता है।एक अच्छा तरीका फिर से छोटे कार्यों में दुष्प्रभाव तोड़ रहा है जो किसी भी नोड पर फिर से चलाया जा सकता है। अर्थात। मुख्य अनुरोध शुरू करें और अंत कार्य करें, जिसमें बहुत से छोटे कार्य हैं जो प्रति कार्य केवल एक तरफ प्रभाव को संभालने के लिए हैं।

यह अन्य मुद्दों को भी पेश करता है जो आपके डिजाइन को प्रभावित करेंगे। उन राज्य चर आवश्यक डेटाबेस अद्यतन नहीं हैं। उन्हें राज्य साझा किया जा सकता है (एक आंतरिक घटक के लिए एक सीमित राज्य मशीन कहें) जिसे क्लस्टर में भी वितरित करने की आवश्यकता है। तो परिवर्तनों के प्रबंधन के लिए पैटर्न जैसे कि मास्टर कोड को उस राज्य के एक सतत संस्करण को देखना चाहिए, जिसकी आवश्यकता है, और उसके बाद उस स्थिति को क्लस्टर में करना। अपरिवर्तनीय के कुछ रूपों का उपयोग करना (कम से कम मास्टर थ्रेड से अद्यतन करना) डेटा संग्रहण उपयोगी है। अर्थात। सभी अपडेट प्रभावी रूप से नई प्रतियों पर किए जाते हैं जिन्हें किसी प्रकार के मध्यस्थ या मुखौटा के माध्यम से जाना चाहिए जो क्लस्टर में अपडेट करने के बाद अपडेट के साथ स्मृति प्रतियों में स्थानीय अपडेट करता है (या डेटा स्थिरता के लिए क्लस्टर में सदस्यों की न्यूनतम संख्या)।

इनमें से कुछ मुद्दे मास्टर वर्कर सिस्टम के लिए भी मौजूद हैं।

राज्य त्रुटि अद्यतन पर गलत होने वाली चीजों की संख्या के रूप में भी अच्छी त्रुटि प्रबंधन की आवश्यकता है (जैसा कि आपके पास अब नेटवर्क शामिल है)।

मैं राज्य पैटर्न का बहुत उपयोग करता हूं। एक लाइन अपडेट के बजाय, साइड इफेक्ट्स के लिए आप अनुरोध/प्रतिक्रिया भेजना चाहते हैं, और प्रगति को ट्रैक करने के लिए वार्तालाप विशिष्ट एफएसएम का उपयोग करना चाहते हैं।

एक और मुद्दा अंतिम बिंदुओं का प्रतिनिधित्व है। अर्थात। मास्टर नोड से जुड़े क्लाइंट को नए मास्टर से पुनः कनेक्ट करने में सक्षम होना चाहिए, और फिर परिणामों के लिए सुनो? या आप बस सभी लंबित परिणामों को रद्द करते हैं और ग्राहकों को पुनः सबमिट करने देते हैं? यदि आप लंबित अनुरोधों को संसाधित करने की अनुमति देते हैं, तो एंडपॉइंट्स (क्लाइंट) की पहचान करने का एक अच्छा तरीका आवश्यक है (यानी लुकअप में किसी प्रकार का क्लाइंट आईडी)।

को क्लीनअप कोड आदि की भी आवश्यकता है (यानी नहीं। क्लाइंट के लिए हमेशा प्रतीक्षा करने के लिए क्लाइंट के लिए डेटा इंतजार करना चाहते हैं)।

बहुत सी कतार का उपयोग किया जाता है। इसलिए बहुत से लोग लेनदेन के तरीके से घटनाओं को धक्का देने के लिए कुछ संदेश बस (जावा के लिए जावा कहते हैं) का उपयोग करेंगे।

टेराकोटा (फिर जावा के लिए) आपके लिए बहुत कुछ हल करता है - बस मेमोरी अपडेट करें - टेराकोटा यहां आपका मुखौटा/मध्यस्थ है। उन्होंने सिर्फ आपके लिए पहलुओं को इंजेक्ट किया है।

टेराकोटा (मैं उनके लिए काम नहीं करता) - "सुपर स्थैतिक" की अवधारणा का परिचय देता है, इसलिए आपको इन क्लस्टर चौड़े सिंगलेट्स मिलते हैं जो शांत होते हैं, लेकिन आपको केवल यह पता होना चाहिए कि यह परीक्षण और विकास वर्कफ़्लो को कैसे प्रभावित करेगा - अर्थात। अच्छे पुन: उपयोग के लिए ठोस कार्यान्वयन की विरासत के बजाय, बहुत सारी रचनाओं का उपयोग करें।

वेब ऐप्स के लिए - एक अच्छा ऐप सर्वर सत्र परिवर्तनीय प्रतिकृति और एक अच्छा लोड बैलेंसर कार्यों के साथ मदद कर सकता है। किसी भी समय, इसका उपयोग एक आरईएसटी (या आपकी पसंद की वेब सेवा विधि) के माध्यम से एक बहु थ्रेडेड सेवा लिखने का एक आसान तरीका है। लेकिन इसमें प्रदर्शन प्रभाव होंगे। फिर से आपकी समस्या डोमेन पर निर्भर करता है।

संदेश सेवा करता है (जेएमएस कहते हैं) अक्सर विभिन्न सेवाओं के बीच ढीले युग्मन को पेश करने के लिए उपयोग किया जाता है। एक सभ्य संदेश सर्वर के साथ, आप बहुत सारे संदेश रूटिंग कर सकते हैं (फिर से अपाचे ऊंट या इसी तरह की एक अच्छी नौकरी होती है) यानी। जेएमएस उत्पादकों आदि के समूह के खिलाफ एक चिपचिपा उपभोक्ता कहें जो अच्छे विफलता की अनुमति भी दे सकता है। जेएमएस कतार इत्यादि मास्टर/दास के समूह से क्लस्टर में cmds वितरित करने का एक आसान तरीका प्रदान कर सकता है। (फिर यह इस बात पर निर्भर करता है कि आप LOB कर रहे हैं या स्क्रैच से सर्वर/उत्पाद लिख रहे हैं)।

Answer 2

उच्च उपलब्धता हार्डवेयर उपलब्धता और रिडंडेंसी के बारे में कोडिंग सम्मेलनों की तुलना में अधिक है। कुछ पैटर्न हैं जो मैं लगभग हर एचए मामले में उपयोग करता हूं: मैं अपने डेटाबेस ऑब्जेक्ट के लिए सिंगलटन पैटर्न चुनता हूं और सिंगलटन बनाने के लिए फैक्टरी पैटर्न का उपयोग करता हूं। कारखाने के पास डेटाबेस के साथ उपलब्धता के मुद्दों को संभालने के लिए तर्क हो सकता है (जहां सबसे अधिक उपलब्धता समस्याएं होती हैं)। उदाहरण के लिए, यदि मास्टर नीचे है, तो मास्टर वापस आने तक दोनों पढ़ और लिखने के लिए दूसरे मास्टर से कनेक्ट करें। मुझे नहीं पता कि ये सबसे ज्यादा लीवरेज पैटर्न हैं, लेकिन वे मेरे कोड में सबसे ज्यादा लीवरेज हैं।

बेशक इस तर्क को __construct विधि में संभाला जा सकता है, लेकिन एक कारखाना पैटर्न आपको अपने कोड को बेहतर ढंग से नियंत्रित करने और डेटाबेस कनेक्टिविटी समस्याओं को संभालने के निर्णय लेने के तर्क की अनुमति देगा। एक कारखाना आपको सिंगलटन पैटर्न को बेहतर तरीके से संभालने की अनुमति देगा।

मैं बिल्कुल डेकोरेटर पैटर्न, और पर्यवेक्षक पैटर्न से बच जाएंगे। वे दोनों आपके कोड में जटिलता बनाते हैं जो इसे बनाए रखना मुश्किल बनाता है। उनके मामले हैं जहां ये आपकी जरूरतों के लिए सबसे अच्छा विकल्प हैं, लेकिन अधिकांश समय वे नहीं हैं।

Answer 3

गलत:

... और वहाँ एक भंडारण सर्वर होगा

अच्छा:

... और वहाँ (एकाधिक) भंडारण के एक खेत हो जाएगा सर्वर (0) लोड बैलेंसर्स के साथ उनमें से

• सबकुछ के सामने भार संतुलन रखें। अभी के लिए आपके पास 4 बैकएंड हो सकते हैं, लेकिन भविष्य में आप उनमें से 400 हो सकते हैं, इसलिए बैकएंड का उपयोग करने वाले सभी ऐप्स नहीं, बल्कि एलबी पर इसे प्रबंधित करना बुद्धिमानी है।

• कैश के कई स्तरों का उपयोग करें।

• तेजी से थिग अप (उदाहरण के लिए memcached) पर लोकप्रिय समाधान की तलाश करें।

• यदि आप किसी सिस्टम को नवीनीकृत करने जा रहे हैं, तो इसे कई छोटे चरणों में भाग-भाग-भाग करें। यदि आप इसे एक बड़े चरण में करते हैं (पुराने को बंद करें, नया चालू करें और प्रार्थना करें कि यह काम करेगा) यह शायद असफल हो जाएगा।

• सामान के लिए DNS नाम का उपयोग करें, f.e. storage-lb.servicename सभी स्टोरेज लोडबलर्स के पते का समाधान करता है। यदि आप एक जोड़ना चाहते हैं, तो बस डीएनएस को संशोधित करें, सभी सेवाएं स्वचालित रूप से इसका उपयोग शुरू कर देगी।

• इसे सरल रखें। जितना अधिक सिस्टम आप निर्भर करते हैं, उतना ही आपकी सेवा इससे ग्रस्त होगी।

Answer 4

एक विश्वसनीय सॉफ्टवेयर का निर्माण करने के लिए दृष्टिकोण crash-only software है:

क्रैश-केवल सॉफ्टवेयर सॉफ्टवेयर है कि सुरक्षित रूप से दुर्घटनाओं और जल्दी से ठीक हो सकता है। इसे रोकने का एकमात्र तरीका इसे दुर्घटनाग्रस्त करना है, और इसे शुरू करने का एकमात्र तरीका पुनर्प्राप्त करना है। एक क्रैश-केवल सिस्टम क्रैश-केवल घटकों से बना है जो पुनः प्रयास करने योग्य अनुरोधों के साथ संवाद करते हैं; त्रुटियों को दुर्घटनाग्रस्त घटक को दुर्घटनाग्रस्त करने और पुन: प्रारंभ करने और किसी भी अनुरोध को पुनः प्रयास करने के द्वारा संभाला जाता है। परिणामस्वरूप प्रणाली अक्सर अधिक मजबूत और भरोसेमंद होती है क्योंकि दुर्घटना वसूली विकास प्रक्रिया में एक प्रथम श्रेणी के नागरिक है, जो बाद में विचार के बजाय है, और अब आपको स्पष्ट शट डाउन के लिए अतिरिक्त कोड (और संबंधित इंटरफेस और बग) की आवश्यकता नहीं है। सभी सॉफ़्टवेयर को सुरक्षित रूप से क्रैश करने और जल्दी से पुनर्प्राप्त करने में सक्षम होना चाहिए, लेकिन क्रैश-केवल सॉफ़्टवेयर में इन गुणों का होना चाहिए, या उनकी कमी जल्दी स्पष्ट हो जाती है।

Answer 5

जैसा कि मैं इसे समझता हूं, आप एचए आर्किटेक्चर के जावा एप्लिकेशन भाग में उपयोग करने के लिए विशिष्ट पैटर्न की तलाश में हैं। बेशक वहां कई पैटर्न और सर्वोत्तम प्रथाएं हैं जिनका उपयोग किया जा सकता है, लेकिन ये वास्तव में "एच पैटर्न" नहीं हैं। इसके बजाय, वे अच्छे विचार हैं जिनका उपयोग कई संदर्भों में किया जा सकता है।

मुझे लगता है कि मैं जो कहने की कोशिश कर रहा हूं वह यह है: एक उच्च उपलब्धता वास्तुकला कई छोटे हिस्सों से बना है। यदि हम इन छोटे हिस्सों में से एक चुनते हैं और उनकी जांच करते हैं, तो हम शायद पाएंगे कि इस छोटे से घटक में कोई जादुई एच विशेषता नहीं है। अगर हम अन्य सभी घटकों की जांच करते हैं तो हमें वही चीज़ मिल जाएगी। यह तब होता है जब वे एक बुद्धिमान तरीके से संयुक्त होते हैं, एक एचए आवेदन बन जाते हैं।

एक एचए एप्लिकेशन एक ऐसा एप्लिकेशन है जहां आप शुरुआत से सबसे खराब योजना बनाते हैं। यदि आप कभी भी "इस घटक के इतने स्थिर हैं कि हमें इसके लिए अतिरिक्त अनावश्यकता की आवश्यकता नहीं है" के संदर्भ में सोचते हैं, तो शायद यह एचए आर्किटेक्चर नहीं है। आखिरकार, समस्या परिदृश्यों को संभालना आसान है जिन्हें आप देखते हैं। यह वह है जो आपको आश्चर्यचकित करता है जो सिस्टम को लाता है।

इन सबके बावजूद, ऐसे पैटर्न हैं जो विशेष रूप से HA संदर्भों में उपयोगी हैं। उनमें से कई को मार्टिन फाउलर द्वारा क्लासिक पुस्तक "Patterns of Enterprise Application Architecture" में दस्तावेज किया गया है।

Answer 6

मैं माइकल Nygard द्वारा Release it! का रीड होने की सलाह देते हैं (अगर मैं समय मिलता बाद में मैं को साफ़ रखने, शायद ठीक वर्तनी व्याकरण आदि में कुछ और अधिक विस्तार कर दिया)। वह कई विरोधी पैटर्न को रेखांकित करता है जो पूरे सिस्टम को लेने से एक गलती घटक को रोकने में मदद के लिए उत्पादन प्रणालियों और पैटर्न को प्रभावित करते हैं। पुस्तक में तीन प्रमुख क्षेत्रों को शामिल किया गया है; स्थिरता, क्षमता और सामान्य डिजाइन (नेटवर्किंग, सुरक्षा, उपलब्धता और प्रशासन को कवर करना)।

मेरी पिछली कार्यस्थल काटा गया था (एक बार या किसी अन्य पर) हर एक विफलता परिदृश्य में न्यागार्ड रूपरेखा (प्रत्येक परिणामी आउटेज के लिए राजस्व के नुकसान के साथ)। उन्होंने सुझाए गए कुछ तकनीकों और पैटर्न को लागू करने के परिणामस्वरूप अधिक स्थिर और अनुमानित सिस्टम (और हां, पुस्तक एक छोटा जावा केंद्रित है, लेकिन सिद्धांत कई संदर्भों में लागू होते हैं)।

Answer 7

उच्च उपलब्धता (एचए) सिस्टम डिजाइनिंग एक सक्रिय अनुसंधान और विकास क्षेत्र है। यदि आप एसीएम या आईईईई देखते हैं, तो सेवा के गुणों (उपलब्धता, विश्वसनीयता, स्केलेबिलिटी इत्यादि) पर शोध पत्रों का एक टन है और उन्हें कैसे प्राप्त किया जाए (ढीला युग्मन, अनुकूलन इत्यादि)। यदि आप व्यावहारिक अनुप्रयोगों के लिए और अधिक देख रहे हैं, तो गलती सहनशील प्रणालियों और मिडलवेयर पर नज़र डालें जो क्लस्टरिंग, ग्रिड या क्लाउड जैसी कार्यक्षमता की अनुमति देने के लिए बनाया गया है।

प्रतिकृति और भार संतुलन (ए.के.ए. रिवर्स प्रॉक्सी) एचए सिस्टम प्राप्त करने के कुछ सबसे आम पैटर्न हैं, और अक्सर अंतर्निहित सॉफ़्टवेयर में कोड परिवर्तन किए बिना किया जा सकता है, यह मानते हुए कि यह बहुत कसकर नहीं है। यहां तक ​​कि हालिया क्लाउड प्रसाद भी प्रतिकृति और लोड संतुलन के माध्यम से अनिवार्य रूप से हासिल किए जाते हैं, हालांकि वे सिस्टम की मांग की विस्तृत श्रृंखला को संभालने के लिए लोच में निर्माण करते हैं।

सॉफ्टवेयर घटकों को बेकार बनाना प्रतिकृति के बोझ को आसान बनाता है, क्योंकि राज्य को सॉफ्टवेयर घटकों के साथ दोहराने की आवश्यकता नहीं होती है। स्टेटलेसनेस प्रमुख कारणों में से एक है कि HTTP स्केल इतनी अच्छी तरह से है, लेकिन अक्सर इसे अपने स्वयं के राज्य (उदा। सत्र) में जोड़ने की आवश्यकता होती है जिसे फिर दोहराने की आवश्यकता होती है।

इसलिए, कसकर युग्मित सिस्टमों की तुलना में कमजोर युग्मित सिस्टम अत्यधिक उपलब्ध करना आसान है। चूंकि सिस्टम के घटकों की विश्वसनीयता पूरी प्रणाली विश्वसनीयता को निर्धारित करती है, अविश्वसनीय घटकों को प्रतिस्थापित करने की आवश्यकता हो सकती है (हार्डवेयर विफलताओं, सॉफ़्टवेयर कीड़े, आदि)। रनटाइम पर गतिशील अनुकूलन की अनुमति देने से इन असफल घटकों को समग्र प्रणाली की उपलब्धता को प्रभावित किए बिना प्रतिस्थापित किया जा सकता है। लूज युग्मन विश्वसनीय संदेश प्रणाली के उपयोग के लिए एक और कारण है जहां प्रेषक और रिसीवर को एक ही समय में उपलब्ध नहीं होना चाहिए, लेकिन सिस्टम अभी भी उपलब्ध है।

Answer 8

मैं व्याख्या कर रहा हूँ के रूप में "उच्च उपलब्धता" "शून्य डाउनटाइम" `है, जो प्रति अन्य एसई प्रश्न के रूप में लागू किया जा सकता:

Zero downtime deployment for Java apps

1. ए/बी स्विच: (रोलिंग अपग्रेड + फ़ॉलबैक तंत्र)
2. समांतर तैनाती - अपाचे टॉमकैट: (वेब ​​ऐप के लिए lications केवल)
3. विलंबित बंदरगाह बाध्यकारी
4. उन्नत बंदरगाह बाध्यकारी

मैं उन अवधारणाओं से कुछ का उपयोग करेगा सॉफ्टवेयर परिप्रेक्ष्य है, जो ऊपर प्रशंसा दृष्टिकोण से उच्च उपलब्धता प्रणाली के लिए डिजाइन पैटर्न साथ आने के लिए।

पैटर्न का उपयोग करें:

Proxy/Factory:

एक प्रॉक्सी वस्तु और प्रॉक्सी तय करेगा जहां अनुरोध रीडायरेक्ट करने के लिए है। मान लें कि आपके पास संस्करण 1 & सॉफ़्टवेयर का संस्करण 2 है। यदि ग्राहक पुराने प्रोटोकॉल से जुड़ रहे हैं, तो उन्हें संस्करण 1 सॉफ़्टवेयर पर रीडायरेक्ट करें। नए ग्राहक सीधे संस्करण 2 से कनेक्ट कर सकते हैं। सॉक्सी के पास या तो सॉफ्टवेयर के नए संस्करण को प्रस्तुत करने के लिए फैक्टरी विधि या सार कारखाना हो सकता है।

Strategy

आप एल्गोरिदम के एक परिवार से एक एल्गोरिथ्म का चयन करके रन टाइम पर एल्गोरिथ्म बदल सकते हैं। यदि आप एयरलाइंस उदाहरण लेते हैं, तो आप गैर-चोटी और पीक ट्रैफिक महीनों के दौरान डिस्काउंटफायर और NormalFare एल्गोरिदम के बीच स्विच कर सकते हैं।

Decorator:

आप रन टाइम पर वस्तु के व्यवहार बदल सकते हैं। एक नई कक्षा जोड़ें और अतिरिक्त जिम्मेदारी सजाने के लिए।

Adapter:

उपयोगी आप इंटरफ़ेस या संस्करण 1 और संस्करण 2 एडाप्टर के बीच अनुबंध में बदलाव होने पर दोनों पुराने & नए ग्राहक को उचित रूप से अनुरोध का जवाब देंगे।

सामान्य दिशा-निर्देश:

1. वस्तुओं के बीच ढीला युग्मन
2. अपने आवेदन में S.O.L.I.D सिद्धांतों का पालन करें

बेहतर समझ के लिए ऊपर पैटर्न के लिए sourcemaking वेबसाइट लेखों का संदर्भ लें।

क्या उपयोग करने के लिए नहीं:

अलावा डिजाइन पैटर्न से, आप कुछ सावधानी बरतने की आपके आवेदन के लिए शून्य डाउनटाइम को प्राप्त करने के लिए है।

1. अपने सिस्टम में विफलताओं के एकल बिंदु को पेश न करें।
2. वितरित कैश (उदा। टेराकोटा)/ताले का उपयोग कम से कम करें।
3. सेवाओं के बीच हार्ड युग्मन निकालें। संदेश बस/ढांचे (जेएमएस, एक्टिवएमक्यू आदि) का उपयोग करके सेवाओं के बीच तंग युग्मन निकालें