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

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

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

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

आशुचित्र इसहाक स्मिथ अनस्प्लैश से

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

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

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

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

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

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

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

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

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

डेटा को संग्रहीत करने और पुनर्प्राप्त करने के बारे में ज्ञान बनाएँ

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

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

आशुचित्र सैमुअल ज़ेलर अनस्प्लैश से

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

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

संचार पैटर्न

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

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

आशुचित्र टोनी स्टोडर्ड अनस्प्लैश से

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

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

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

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

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

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

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

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

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

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

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

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

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

आशुचित्र कैलिडिको अनस्प्लैश से

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

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

स्रोत: www.habr.com