स्केलिंग आसान है

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

भाग एक सिद्धांत।

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

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

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

यहाँ एक उदाहरण है।

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

वास्तुकला - यह क्या है?

सही आर्किटेक्चर को खोजने के बारे में बात करने से पहले, जो लचीलेपन (स्केलेबिलिटी), स्केलेबिलिटी (स्केलेबिलिटी) और प्रबंधनीयता (नियंत्रणीयता) जैसी मानक आवश्यकताओं का समर्थन करेगा, आपको यह तय करने की आवश्यकता है: वास्तव में, क्या आर्किटेक्चर है? राय यहाँ अलग है। कुछ लोग वास्तुकला को सिस्टम आवश्यकताओं के विवरण, एक प्रकार का आवश्यकता विश्लेषण के रूप में मानते हैं; अन्य वर्ग के वितरण पैकेज की तरह हैं। सॉफ्टवेयर आर्किटेक्चर की विविध परिभाषाओं का विस्तृत चयन इस पृष्ठ पर पाया जा सकता है।
मैं इस प्रकार सबसे सफल मानता हूं:

आर्किटेक्चर (सॉफ्टवेयर) सिस्टम की संरचना है, जिसमें घटकों से मिलकर बनता है, इन घटकों के दृश्य गुण और उनके बीच के संबंध हैं।

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

बी 2 सी पोर्टल्स में लौटते हुए, हम वास्तुकला, गुणों के दृष्टिकोण से, उनके सामान्य पर ध्यान देते हैं:

• पढ़ने और लिखने के संचालन के बीच उच्च अनुपात: पाठकों की संख्या लिखने वालों की तुलना में 9-10 गुना अधिक हो सकती है;
• स्पष्ट रूप से अलग-अलग कार्यात्मकताएं - उदाहरण के लिए, आंतरिक संदेश या एक प्रोफ़ाइल;
• पोर्टल ट्रैफ़िक उन स्पाइक्स के अधीन है जो दिन, सप्ताह या वर्ष के समय के आधार पर सामान्य भार का बहुवचन बनाते हैं;
• पोर्टल्स लगातार और तेजी से बदल रहे हैं। यह कोड, और सामग्री और डेटा पर लागू होता है।

सामान्य स्थापत्य सिद्धांत

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

वास्तुकला के दृष्टिकोण से, SOA में घटक सेवाएँ और ग्राहक हैं, और प्रत्येक घटक एक ही समय में दोनों हो सकते हैं। किसी घटक के बाहरी रूप से दिखाई देने वाले गुण वे इंटरफ़ेस होते हैं जो इसे प्रकाशित करता है। घटकों के बीच संबंधों के लिए, उनमें से दो प्रकार हैं:

• डायरेक्ट या सिंक्रोनस कम्युनिकेशन एक मेथड कॉल है, जो एक क्लाइंट किसी सर्विस को एक्सेस करता है।
• अप्रत्यक्ष या अतुल्यकालिक संचार एक राज्य परिवर्तन (घटना) के बारे में एक चेतावनी है, जो एक घटक "पूरी दुनिया के लिए गुप्त रूप से" प्रकाशित करता है, इस बारे में चिंता किए बिना कि क्या इसके विशिष्ट श्रोता हैं।

प्रत्यक्ष संचार टैक्सी या पिज्जा ऑर्डर करने वाली सेवा के लिए एक फोन कॉल के समान है, अप्रत्यक्ष संचार एक स्टॉक बोर्ड पर टिकर के बराबर होता है जो किसी की परवाह किए बिना पढ़ता है या नहीं। साक्षात्कार के तरीके, जैसे डेटा सुनना, वास्तुकला के दृष्टिकोण से इंटरफेस है, अर्थात, घटक के साथ संचार के साधन।

अस्थि मज्जा को अलगाव (डेटाबेस के लिए)

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

सिस्टम आर्किटेक्चर के संदर्भ में वैश्विक डेटा मॉडल का स्वैच्छिक परित्याग का मतलब निम्नलिखित है:

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

SOA के लाभों का पूरी तरह से आनंद लेने के लिए, सेवाओं को सही ढंग से "कटा हुआ" होना चाहिए। बड़ी, राक्षसी सेवाएं अक्सर "एक आवेदन में एक आवेदन" में बदल जाती हैं, और स्वयं उन समस्याओं से ग्रस्त होती हैं जिन्हें हम दूर करने जा रहे थे। बहुत बारीक कटी हुई सेवाएं ओवरहेड संचार की ओर ले जाती हैं, जो सभी स्केलिंग को जड़ से मार देती है। सही सेवा आकार कैसे पाएं?

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


चित्र 1: सही सेवाएँ काटना

सेवाओं की सही पहचान करने के बाद, आपको यह सोचने की ज़रूरत है कि उन्हें एक दूसरे के साथ "संवाद" कैसे करना चाहिए।


चित्र 2: अनुमत (हरा) और निषिद्ध (लाल) संचार पथ

वैश्विक डेटा मॉडल से कैसे बचें?

परतों का आमतौर पर स्वीकृत मॉडल ऊर्ध्वाधर है। शीर्ष पर प्रस्तुति परत है, तल पर - लगातार। इसलिए, डेवलपर्स आमतौर पर दृढ़ता के साथ शुरू करते हैं और एक वैश्विक डेटा मॉडल बनाते हैं। वास्तव में, SOA में आपको बीच में शुरू करना होगा:


योजना 3: परतों के बीच निर्भरता

इस प्रकार, हम एक वास्तविक सेवा मॉडल बना सकते हैं जिसमें प्रत्येक विशिष्ट दृढ़ता इसकी सेवा की जरूरतों को पूरा करती है, और केवल इसे। यह पैमाने पर करने के लिए आवश्यक सख्त अलगाव की ओर जाता है:


चित्रा 4: दृढ़ता अलगाव

एक और प्रतिमान है, जो पालन करने के लिए बिल्कुल जरूरी है - KISS (यह सरल बेवकूफ रखें,) है। सॉफ्टवेयर वास्तुकला के बारे में, KISS मतलब यह है कि केवल अत्यंत आवश्यक घटक हमारे वास्तुकला का हिस्सा होना चाहिए। कुछ भी जो सीधे फायदेमंद नहीं है, और फैशनेबल तकनीक प्रासंगिक हो सकती है, को खारिज किया जाना चाहिए। दूसरे शब्दों में, केवल वे प्रौद्योगिकियां जो अपने समर्थन की लागतों को सही ठहराती हैं, अंतिम समाधान में प्रवेश करने का अधिकार रखती हैं।

अच्छी वास्तुकला में कई दलदल हैं

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

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