एक्सएपी (बुलशिट आर्किटेक्चर बस्ट)

कल, मैंने पहली बार हैबर पर एक लेख लिखा था, जो स्थानीय सूक्ष्मताओं को नहीं जानता था।

ठीक! अब सादे भाषा में और हास्य के साथ!

ब्लैक फ्राइडे कोहल के अमेरिकी इंटरनेट डिपार्टमेंट स्टोर के लिए वास्तव में काला हो गया। क्रिसमस की बिक्री के दिन सभी सर्वर तांबे के बेसिन से ढके थे। उस दिन अर्जित वार्षिक आय का सामान्य 20% एक हास्यास्पद तिपहिया के रूप में निकला, और सभी क्योंकि बोलीवर इस तरह के भार को बर्दाश्त नहीं कर सकता था।

Tomcat + WebLogic + DB की पारंपरिक वास्तुकला को पूरा किया गया है! सिस्टम प्रशासक व्यर्थ में इधर-उधर भागते रहे, अग्रणी प्रोग्रामर दहशत में रहे और वास्तुकारों ने बालों के अवशेषों को बाहर निकाल दिया ... सभी संभावित ग्राहकों को इसमें निचोड़ने के लिए बोतल की गर्दन बहुत संकीर्ण थी और लोचदार नहीं थी जो थोड़े समय में विस्तारित हो। बोतल ने चुदाई को चीर दिया। और एक लंबे समय के लिए उसके टुकड़े से बहने वाले घावों से खून बह रहा था ...

त्रिस्तरीय वास्तुकला मुद्दे

- बेटा, यह काम करता है - स्पर्श न करें!
- पिताजी, यह काम नहीं करता है, यह काम करता है !!!

आप सभी लोग पुराने के बारे में अच्छी तरह से जानते हैं, लेकिन किसी भी तरह से हमेशा तीन स्तरीय वास्तुकला नहीं होती है।




इस समाधान का विश्लेषण करके, आप आसानी से कई स्पष्ट समस्याओं की पहचान कर सकते हैं।

प्रबंधन की कठिनाइयों

सभी स्तरों में अलग-अलग क्लस्टरिंग मॉडल होते हैं। ऐसी प्रणाली का प्रबंधन करने के लिए उन सभी के साथ ज्ञान और अनुभव की आवश्यकता होती है। यह आवश्यकता है:

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

स्टेटिक रिसोर्स बाइंडिंग

जैसे कि हार्ड ड्राइव और सर्वर नाम। बादलों में इस तरह के अनुप्रयोगों को स्थापित करते समय कठिनाइयाँ उत्पन्न होती हैं, क्योंकि वे प्रकृति में बहुत गतिशील हैं।

उत्पादकता

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

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

कैश और डेटाग्रिड समस्या का समाधान क्यों नहीं करते हैं

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

• यह एक और परत जोड़ता है जिसके लिए अतिरिक्त लाइसेंस की आवश्यकता होती है। यदि एक खराबी होती है, तो अन्य सभी की तरह, एक नए स्तर को एकीकृत, कॉन्फ़िगर, मॉनिटर और हटा दिया जाना चाहिए। इस प्रकार, यह इस वास्तुकला के प्रबंधन की समग्र जटिलता और इसकी स्थापना, समर्थन और रखरखाव की लागत को बढ़ाता है।
• जैसा कि ऊपर उल्लेख किया गया है, ऐसे समाधान उन प्रणालियों के लिए मदद करेंगे जिनके पास कई रीड ऑपरेशन हैं। लेकिन यह उन प्रणालियों के लिए बिल्कुल बेकार है जहां कई लेखन कार्य हैं। इसके अलावा, कैश की उपस्थिति में, कैश और डेटाबेस के बीच सिंक्रनाइज़ेशन के लिए अतिरिक्त लागतें उत्पन्न होती हैं।

वास्तविक विश्व उदाहरण

ऑनलाइन बिक्री के लिए कोहल के वास्तविक बहु स्तरीय प्रणाली वास्तुकला पर विचार करें।


यह तुरंत स्पष्ट है कि इस प्रणाली का कोई भी हिस्सा अड़चन की भूमिका निभा सकता है। जाहिर है, "संकीर्ण" के अलावा किसी भी स्थान पर अतिरिक्त संसाधनों को जोड़ने से सिस्टम में ब्रेक से छुटकारा पाने में मदद नहीं मिलेगी।

कोहल के वेबलॉजिक के मामले में, अपाचे और ओरेकल डेटाबेस ने 50 भौतिक सर्वरों का उपयोग करके एक उत्कृष्ट कार्य किया। एक साथ जुड़े 30,000 उपयोगकर्ताओं को नियमित रूप से सभी अनुरोधों के जवाब मिले। यह भविष्य में काम करना जारी रखेगा यदि, उदाहरण के लिए, एक कंपनी को हर सेकंड एक निश्चित संख्या में लेनदेन की सेवा करनी थी, और सिस्टम के लिए आवश्यकताओं में कोई तेज बदलाव नहीं होगा।

हालांकि, वही "ब्लैक फ्राइडे" (ब्लैक फ्राइडे, जब लाखों अमेरिकियों ने दुकानों में भाग लिया, और खुदरा विक्रेताओं ने 2009 के एक दिन में 20 और कभी-कभी 30 प्रतिशत वार्षिक राजस्व की आवश्यकता होती है) कि सिस्टम 500,000 के भार का सामना करता है एक ही समय में उपयोगकर्ताओं। तीन स्तर की वास्तुकला इस तरह के एक झटका के लिए तैयार नहीं थी ...

परिणाम दसियों लाख डॉलर का नुकसान है। इसलिए सवाल:

क्या पुराने नायकों को बदलने का समय आ गया है?

इसलिए, हम एक आधुनिक प्लेटफॉर्म के लिए प्रमुख आवश्यकताएं तैयार करते हैं:

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

गिगास्पेस इंजीनियरों ने 10 साल पहले नए XAP प्लेटफॉर्म (eXtreme Application Platform) को विकसित करना शुरू किया था, जो इन आवश्यकताओं को पूरा करता था।

इस तरह वे सभी सामने आए

• सारा डेटा रैम में स्टोर होता है, न कि डिस्क पर। अगर कुछ भी है, तो रैम आज बहुत सस्ती है, ओरेकल डेटाबेस भी नहीं, यहां तक ​​कि सबसे सरल समर्थन भी
• एप्लिकेशन लॉजिक उसी डेटा कंटेनर में बैठता है। बेशक, विश्वविद्यालय के शिक्षक और शास्त्रीय वास्तुकला के अन्य प्रेमी इसे पसंद नहीं कर सकते हैं। एक और खाबरोवस्क नागरिक यह भी तय कर सकता है कि इस तरह के समाधान में तर्क के साथ डेटा के अस्वास्थ्यकर मिश्रण का योगदान होता है। हालांकि, अनुभव से पता चलता है कि कोई भी परतें वास्तविक कारीगरों को रोक नहीं सकती हैं, और उचित कौशल के साथ, किसी भी प्रकार के "आर्किटेक्चर" के साथ एक विनिगेट बनाया जा सकता है!
• सभी डेटा को असीमित संख्या में विभाजन में विभाजित किया गया है, जिनमें से प्रत्येक एक अलग मशीन में बैठ सकता है।
• कूटनीति को घोषित रूप से वर्णित किया जाता है! "मुझे सभी डेटा को 100,500 टुकड़ों में तोड़ दें, प्रत्येक टुकड़े के लिए 2 बैकअप बनाएं, एक डेटा सेंटर में डिप्लोमैटिक बैकअप न रखें, डिप्लोमा के लिए 146 प्रतिशत से अधिक लोड की गई मशीनों का उपयोग न करें"
• विशेष प्रेषणकर्ता एक साथ कई स्थानों पर डेटा लिखते हैं और विफलता के मामले में वे स्वचालित रूप से अन्य मशीनों के अनुरोधों को पुनर्निर्देशित करते हैं। इसके समानांतर, एक सुविधाजनक निगरानी प्रणाली है जो सभी संभावित समस्याओं, जैसे क्लस्टर में नोड्स की अपर्याप्त संख्या, सिस्टम विफलताओं, या मशीन की भीड़ को सूचित करती है।

और यहाँ वीडियो है

कोहल राख से उठ गया है

2009 के संकट के बाद, कोहल ने पूरी पुरानी वास्तुकला को XAP के साथ बदल दिया। परिणामस्वरूप, Google के अनुसार, आज उनकी साइट पेज डिलीवरी की गति के मामले में दुनिया में पहले स्थान पर है।


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

उपसंहार

कोई कहेगा: "और मैं बहु-स्तरीय वास्तुकला का उपयोग करता हूं और बहुत संतुष्ट हूं!" और बहुत अच्छी तरह से। लेकिन एक ऐसी दुनिया में रहना जहां डेटा की मात्रा तेजी से बढ़ रही है, हमें यह समझना चाहिए कि भले ही आज इन-मेमोरी कंप्यूटिंग प्लेटफॉर्म की कोई आवश्यकता नहीं है, तो हमें कम से कम उनके अस्तित्व के बारे में पता होना चाहिए और वे क्या लाभ लाते हैं। हो सकता है कि निकट भविष्य में आपके एप्लिकेशन द्वारा संसाधित डेटा की मात्रा के लिए आवश्यकताओं में वृद्धि हो और फिर, निश्चित रूप से, इन-मेमोरी कंप्यूटिंग प्लेटफॉर्म मदद कर सकते हैं, उन अनुप्रयोगों का उल्लेख नहीं करने के लिए जो वास्तविक समय में बड़ी मात्रा में डेटा के साथ काम करते हैं, जिसके लिए उनका उपयोग बस आवश्यक है।

उपसंहार

31 वें शनिवार को JUG में आइए, और मैं आपको XAP के बारे में बताऊंगा जो अपने काम के बहुत अधिक रंगीन और जीवंत शो में है।

और यहाँ वीडियो है: