सॉफ्टवेयर आर्किटेक्चर एंड सिस्टम डिज़ाइन: द बिग पिक्चर एंड रिसोर्स गाइड

नमस्कार साथियों!

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


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



इसहाक स्मिथ ने अनप्लाश से शॉट लिया

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

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

• हम जिस समस्या को हल करने का प्रयास कर रहे हैं, वह क्या है?
• उन उपयोगकर्ताओं की चोटी संख्या क्या है जो हमारे सिस्टम के साथ बातचीत करेंगे?
• हमारे साथ डेटा लिखने और पढ़ने के कौन से पैटर्न का उपयोग किया जाएगा?
• अपेक्षित असफलताएं क्या हैं, हम उनसे कैसे निपटेंगे?
• स्थिरता और सिस्टम की उपलब्धता के लिए क्या उम्मीदें हैं?
• क्या आपको बाहरी सत्यापन और विनियमन से संबंधित किसी भी आवश्यकताओं को ध्यान में रखना है?
• हम किस प्रकार का गोपनीय डेटा स्टोर करने जा रहे हैं?

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

प्रारंभिक स्तर निर्धारित करें

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

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

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

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

डेटा संग्रहण और पुनर्प्राप्ति के बारे में ज्ञान प्राप्त करें

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

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



अनसप्लेश से सैमुअल ज़ेलर का स्नैपशॉट

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

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

संचार पैटर्न

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

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



टोनी स्टोडर्ड का स्नैपशॉट Unsplash से

बाहरी दुनिया के साथ संचार का आयोजन करते समय, सुरक्षा हमेशा बहुत महत्वपूर्ण होती है, जिसे गंभीरता के साथ संपर्क करना चाहिए और सक्रिय रूप से शामिल होना चाहिए।

कनेक्शन वितरण

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

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

यह वितरण प्रसिद्ध डोमेन नाम प्रणाली (डीएनएस) पर आधारित है। इस तरह की प्रणाली आपको एक डोमेन नाम बदलने की अनुमति देती है, उदाहरण के लिए, भारित राउंड रॉबिन और देरी के आधार पर तरीके, जो लोड को वितरित करने में मदद करते हैं।

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

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

व्यापार तर्क के बारे में बात करते हैं। संरचना व्यापार तर्क, कार्य प्रवाह, और घटक

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

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

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

सहयोगात्मक दृष्टिकोण

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



अनसप्लेश से कैलिडिको स्नैपशॉट

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

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