सॉफ्टवेअर आर्किटेक्चर आणि सिस्टम डिझाइन: बिग पिक्चर आणि रिसोर्स गाइड

नमस्कार सहकारी.

आज आम्ही तुमच्या विचारार्थ Tugberk Ugurlu यांच्या एका लेखाचे भाषांतर ऑफर करतो, ज्याने आधुनिक सॉफ्टवेअर सिस्टम डिझाइन करण्याच्या तत्त्वांची रूपरेषा तुलनेने कमी प्रमाणात मांडली. थोडक्यात लेखक स्वतःबद्दल काय म्हणतो ते येथे आहे:

2019 मधील आर्किटेक्चरल पॅटर्न + डिझाइन पॅटर्न यासारख्या प्रचंड विषयावर हॅब्रो लेखात कव्हर करणे पूर्णपणे अशक्य असल्याने, आम्ही केवळ श्री. उरुग्लूचा मजकूरच नव्हे तर त्यांनी त्यात दयाळूपणे समाविष्ट केलेल्या असंख्य लिंक्सची देखील शिफारस करतो. तुम्हाला ते आवडल्यास, आम्ही वितरित प्रणालीच्या डिझाइनबद्दल अधिक उच्च विशिष्ट मजकूर प्रकाशित करू.

स्नॅपशॉट आयझॅक स्मिथ अनस्प्लॅश कडून

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

मला असे वाटते की सिस्टम डिझाइन करण्यास सुरुवात करणार्‍या कोणालाही मी सर्वात चांगला सल्ला देऊ शकतो: कोणतेही गृहितक बनवू नका! अगदी सुरुवातीपासून, आपल्याला या प्रणालीबद्दल ज्ञात तथ्ये आणि त्याच्याशी संबंधित अपेक्षा निर्दिष्ट करणे आवश्यक आहे. आपल्या डिझाइनसह प्रारंभ करण्यास मदत करण्यासाठी विचारण्यासाठी येथे काही चांगले प्रश्न आहेत:

• आम्ही कोणती समस्या सोडवण्याचा प्रयत्न करीत आहोत?
• आमच्या सिस्टमशी संवाद साधणाऱ्या वापरकर्त्यांची सर्वोच्च संख्या किती आहे?
• आम्ही डेटा लिहिण्याचे आणि वाचण्याचे कोणते नमुने वापरू?
• अपेक्षित अपयशाची प्रकरणे कोणती आहेत, आम्ही त्यांना कसे हाताळणार आहोत?
• सिस्टम सुसंगतता आणि उपलब्धतेसाठी काय अपेक्षा आहेत?
• काम करत असताना तुम्हाला बाह्य पडताळणी आणि नियमन संबंधित कोणत्याही आवश्यकता विचारात घ्याव्या लागतील का?
• आम्ही कोणत्या प्रकारचा संवेदनशील डेटा संचयित करणार आहोत?

हे फक्त काही प्रश्न आहेत जे मला आणि ज्या संघांमध्ये मी अनेक वर्षांपासून व्यावसायिक क्रियाकलापांमध्ये भाग घेतला आहे त्यांच्यासाठी उपयुक्त ठरले आहेत. जर तुम्हाला या प्रश्नांची उत्तरे माहित असतील (आणि तुम्हाला ज्या संदर्भात काम करायचे आहे त्या संदर्भाशी संबंधित इतर कोणतेही), तर तुम्ही हळूहळू समस्येच्या तांत्रिक तपशीलांचा शोध घेऊ शकता.

प्रारंभिक स्तर सेट करा

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

मला वाटते की मी तुम्हाला हे पटवून देऊ शकलो की जर एखाद्या तज्ञाने काही आश्चर्यकारक सॉफ्टवेअर सिस्टमचे आर्किटेक्चरल घटक काय आहे हे आत्मविश्वासाने समजून घेतले तर हे ज्ञान वास्तुविशारदाच्या कलेमध्ये प्रभुत्व मिळविण्यासाठी आणि या क्षेत्रात ठोस आधार विकसित करण्यासाठी अपरिहार्य असेल.

ठीक आहे, तर कुठून सुरुवात करायची? यू डोना मार्टिना GitHub वर एक भांडार आहे ज्याला म्हणतात सिस्टम-डिझाइन-प्राइमर, ज्यातून तुम्ही मोठ्या प्रमाणावर प्रणाली कशी डिझाइन करावी हे शिकू शकता, तसेच या विषयावरील मुलाखतीची तयारी करू शकता. रेपॉजिटरीमध्ये उदाहरणांसह एक विभाग आहे वास्तविक आर्किटेक्चर, जेथे, विशेषतः, ते त्यांच्या सिस्टमच्या डिझाइनकडे कसे पोहोचतात याचा विचार केला जातो काही प्रसिद्ध कंपन्याउदा. Twitter, Uber इ.

तथापि, या सामग्रीकडे जाण्यापूर्वी, आपण सरावात तोंड देत असलेल्या सर्वात महत्त्वाच्या वास्तुशिल्पीय आव्हानांवर जवळून नजर टाकूया. हे महत्त्वाचे आहे कारण तुम्हाला हट्टी आणि बहुआयामी समस्येचे अनेक पैलू निर्दिष्ट करावे लागतील आणि नंतर दिलेल्या प्रणालीमध्ये लागू असलेल्या नियमांच्या चौकटीत त्याचे निराकरण करावे लागेल. जॅक्सन गॅबार्ड, माजी फेसबुक कर्मचारी, लिहिले सिस्टम डिझाइन मुलाखतींबद्दल 50-मिनिटांचा व्हिडिओ, जिथे त्याने शेकडो अर्जदारांची तपासणी करण्याचा स्वतःचा अनुभव शेअर केला. व्हिडिओ मोठ्या सिस्टीम डिझाइनवर आणि अशा पदासाठी उमेदवार शोधताना महत्त्वाच्या असलेल्या यशाच्या निकषांवर जास्त लक्ष केंद्रित करत असताना, सिस्टम डिझाइन करताना कोणत्या गोष्टी सर्वात महत्त्वाच्या आहेत यावरील सर्वसमावेशक संसाधन म्हणून काम करेल. मी पण सुचवतो सारांश हा व्हिडिओ.

डेटा संचयित आणि पुनर्प्राप्त करण्याबद्दल ज्ञान तयार करा

सामान्यतः, तुम्ही तुमचा डेटा दीर्घकाळ कसा संग्रहित आणि पुनर्प्राप्त करता याविषयीच्या तुमच्या निर्णयाचा सिस्टीमच्या कार्यक्षमतेवर गंभीर परिणाम होतो. म्हणून, आपण प्रथम आपल्या सिस्टमची अपेक्षित लेखन आणि वाचन वैशिष्ट्ये समजून घेणे आवश्यक आहे. मग तुम्हाला या निर्देशकांचे मूल्यमापन करण्यात आणि केलेल्या मूल्यांकनांच्या आधारे निवड करण्यास सक्षम असणे आवश्यक आहे. तथापि, आपण विद्यमान डेटा संचयन पद्धती समजून घेतल्यासच आपण या कार्याचा प्रभावीपणे सामना करू शकता. तत्वतः, हे संबंधित ठोस ज्ञान सूचित करते डेटाबेस निवड.

डेटाबेसचा डेटा स्ट्रक्चर्स म्हणून विचार केला जाऊ शकतो जो अत्यंत स्केलेबल आणि टिकाऊ आहे. म्हणून, विशिष्ट डेटाबेस निवडताना डेटा संरचनांचे ज्ञान आपल्यासाठी खूप उपयुक्त असले पाहिजे. उदाहरणार्थ, Redis एक डेटा संरचना सर्व्हर आहे जो विविध प्रकारच्या मूल्यांना समर्थन देतो. हे आपल्याला डेटा स्ट्रक्चर्स जसे की सूची आणि सेटसह कार्य करण्यास आणि सुप्रसिद्ध अल्गोरिदम वापरून डेटा वाचण्याची परवानगी देते, उदाहरणार्थ, एलआरयू, टिकाऊ आणि अत्यंत प्रवेशजोगी शैलीमध्ये अशा कामाचे आयोजन करणे.

स्नॅपशॉट सॅम्युअल झेलर अनस्प्लॅश कडून

एकदा तुम्हाला विविध डेटा स्टोरेज पॅटर्नची पुरेशी माहिती मिळाल्यानंतर, डेटाची सुसंगतता आणि उपलब्धतेचा अभ्यास करण्यासाठी पुढे जा. सर्व प्रथम, आपण समजून घेणे आवश्यक आहे CAP प्रमेय किमान सामान्य शब्दात, आणि नंतर स्थापित नमुन्यांची जवळून पाहणी करून हे ज्ञान पॉलिश करा सुसंगतता и प्रवेशयोग्यता. अशा प्रकारे, तुम्ही फील्डची समज विकसित कराल आणि समजून घ्याल की डेटा वाचणे आणि लिहिणे या दोन भिन्न समस्या आहेत, प्रत्येकाची स्वतःची अद्वितीय आव्हाने आहेत. काही सुसंगतता आणि उपलब्धता नमुन्यांसह सशस्त्र, तुम्ही तुमच्या ऍप्लिकेशन्समध्ये सुरळीत डेटा प्रवाह सुनिश्चित करताना सिस्टम कार्यप्रदर्शन लक्षणीयरीत्या वाढवू शकता.

शेवटी, डेटा स्टोरेज समस्यांबद्दल संभाषण संपवून, आम्ही कॅशिंगचा देखील उल्लेख केला पाहिजे. ते क्लायंट आणि सर्व्हरवर एकाच वेळी चालले पाहिजे? तुमच्या कॅशेमध्ये कोणता डेटा असेल? आणि का? तुम्ही कॅशे अवैधीकरण कसे आयोजित कराल? ठराविक अंतराने ते नियमितपणे केले जाईल का? होय असल्यास, किती वेळा? मी या विषयांचा अभ्यास सुरू करण्याची शिफारस करतो पुढील विभाग उपरोक्त प्रणाली डिझाइन प्राइमर.

संप्रेषण नमुने

सिस्टममध्ये विविध घटक असतात; या एकाच भौतिक नोडमध्ये चालणाऱ्या वेगवेगळ्या प्रक्रिया असू शकतात किंवा तुमच्या नेटवर्कच्या वेगवेगळ्या भागांवर चालणाऱ्या वेगवेगळ्या मशीन असू शकतात. तुमच्या नेटवर्कमधील यापैकी काही संसाधने खाजगी असू शकतात, परंतु इतर सार्वजनिक आणि बाहेरून प्रवेश करणार्‍या ग्राहकांसाठी खुली असावीत.

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

स्नॅपशॉट टोनी स्टॉडार्ड अनस्प्लॅश कडून

बाह्य जगाशी संप्रेषण आयोजित करताना, हे नेहमीच खूप महत्वाचे असते सुरक्षा, ज्याच्या तरतुदीचा देखील गांभीर्याने आणि सक्रियपणे पाठपुरावा करणे आवश्यक आहे.

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

मला खात्री नाही की हा विषय वेगळ्या विभागात टाकणे प्रत्येकाला न्याय्य वाटेल. तरीसुद्धा, मी ही संकल्पना येथे तपशीलवार मांडणार आहे, आणि मला विश्वास आहे की या विभागातील सामग्रीचे वर्णन “कनेक्शन वितरण” या शब्दाने केले आहे.

सिस्टम अनेक घटकांना योग्यरित्या जोडून तयार केले जातात आणि त्यांचा एकमेकांशी संवाद स्थापित प्रोटोकॉलच्या आधारावर आयोजित केला जातो, उदाहरणार्थ, TCP आणि UDP. तथापि, हे प्रोटोकॉल आधुनिक प्रणालींच्या सर्व गरजा पूर्ण करण्यासाठी अपुरे असतात, जे बर्‍याचदा उच्च भाराखाली चालवले जातात आणि वापरकर्त्याच्या गरजांवर देखील अवलंबून असतात. सिस्टमवरील अशा उच्च भारांचा सामना करण्यासाठी कनेक्शनचे वितरण करण्याचे मार्ग शोधणे आवश्यक आहे.

हे वितरण सुप्रसिद्धांवर आधारित आहे डोमेन नाव प्रणाली (DNS). अशी प्रणाली भार वितरीत करण्यात मदत करण्यासाठी भारित राउंड रॉबिन आणि लेटन्सी-आधारित पद्धतींसारख्या डोमेन नावाच्या परिवर्तनास अनुमती देते.

लोड बॅलन्सिंग मूलभूतपणे महत्त्वाचे आहे, आणि आज आपण हाताळत असलेली प्रत्येक मोठी इंटरनेट प्रणाली एक किंवा अधिक लोड बॅलन्सर्सच्या मागे स्थित आहे. लोड बॅलन्सर्स अनेक उपलब्ध उदाहरणांमध्ये क्लायंट विनंत्या वितरित करण्यात मदत करतात. लोड बॅलन्सर्स हार्डवेअर आणि सॉफ्टवेअर दोन्हीमध्ये येतात, तथापि, सराव मध्ये, आपल्याला बर्‍याचदा सॉफ्टवेअरशी सामोरे जावे लागते, उदाहरणार्थ हाप्रोक्सी и ईएलबी. उलट प्रॉक्सी संकल्पनात्मकदृष्ट्या देखील लोड बॅलन्सरसारखेच आहे, जरी प्रथम आणि द्वितीय दरम्यान श्रेणी आहे वेगळे फरक. तुमच्या गरजांवर आधारित प्रणाली तयार करताना हे फरक विचारात घेतले पाहिजेत.

बद्दल देखील माहित असणे आवश्यक आहे सामग्री वितरण नेटवर्क (CDN). CDN हे प्रॉक्सी सर्व्हरचे जागतिक वितरित नेटवर्क आहे जे भौगोलिकदृष्ट्या विशिष्ट वापरकर्त्याच्या जवळ असलेल्या नोड्सवरून माहिती वितरीत करते. तुम्ही JavaScript, CSS आणि HTML मध्ये लिहिलेल्या स्टॅटिक फाइल्ससह काम करत असल्यास CDN वापरणे अधिक श्रेयस्कर आहे. याव्यतिरिक्त, रहदारी व्यवस्थापक प्रदान करणार्‍या क्लाउड सेवा आज सामान्य आहेत, उदाहरणार्थ, Azure वाहतूक व्यवस्थापक, डायनॅमिक सामग्रीसह कार्य करताना तुम्हाला जागतिक वितरण आणि कमी विलंबता देते. तथापि, अशा सेवा सामान्यतः अशा प्रकरणांमध्ये उपयुक्त असतात जेथे तुम्हाला स्टेटलेस वेब सेवांसह काम करावे लागते.

चला व्यवसायाच्या तर्कशास्त्राबद्दल बोलूया. व्यवसाय तर्कशास्त्र, कार्य प्रवाह आणि घटकांची रचना करणे

म्हणून, आम्ही प्रणालीच्या विविध पायाभूत पैलूंवर चर्चा करण्यात व्यवस्थापित केले. बहुधा, वापरकर्ता आपल्या सिस्टमच्या या सर्व घटकांचा विचार देखील करत नाही आणि स्पष्टपणे, त्यांची अजिबात काळजी घेत नाही. वापरकर्त्याला तुमच्या सिस्टमशी संवाद साधायला काय आवडते, हे करून काय साध्य केले जाऊ शकते आणि सिस्टम वापरकर्त्याच्या आज्ञा कशा कार्यान्वित करते, वापरकर्त्याच्या डेटासह काय आणि कसे करते याबद्दल स्वारस्य आहे.

या लेखाच्या शीर्षकानुसार मी सॉफ्टवेअर आर्किटेक्चर आणि सिस्टम डिझाइनबद्दल बोलणार होतो. त्यानुसार, सॉफ्टवेअर घटक कसे तयार केले जातात याचे वर्णन करणारे सॉफ्टवेअर डिझाइन पॅटर्न कव्हर करण्याची माझी योजना नाही. तथापि, मी त्याबद्दल जितका अधिक विचार करतो तितकेच मला असे वाटते की सॉफ्टवेअर डिझाइन पॅटर्न आणि आर्किटेक्चरल पॅटर्नमधील रेषा खूप अस्पष्ट आहे आणि दोन संकल्पना जवळून संबंधित आहेत. उदाहरण घेऊ कार्यक्रम नोंदणी (इव्हेंट सोर्सिंग). एकदा तुम्ही हा आर्किटेक्चरल पॅटर्न स्वीकारला की, ते तुमच्या सिस्टमच्या जवळजवळ प्रत्येक पैलूवर परिणाम करेल: डेटाचे दीर्घकालीन स्टोरेज, तुमच्या सिस्टममध्ये स्वीकारलेली सातत्य पातळी, त्यातील घटकांचा आकार इ. इ. म्हणून, मी काही आर्किटेक्चरल नमुन्यांची उल्लेख करण्याचे ठरवले जे थेट व्यावसायिक तर्काशी संबंधित आहेत. जरी हा लेख स्वतःला एका सोप्या सूचीपर्यंत मर्यादित ठेवावा लागेल, तरीही मी तुम्हाला त्याच्याशी परिचित होण्यासाठी आणि या नमुन्यांशी संबंधित कल्पनांबद्दल विचार करण्यास प्रोत्साहित करतो. येथे तुम्ही आहात:

• ठोस तत्त्वे
• संकल्पनेची डोमेन-चालित डिझाइन, विशेषतः, युनिट्स, संघ आणि कार्यक्रम
• षटकोनी वास्तुकला
• आज्ञा आणि विनंत्या (CQRS) मध्ये जबाबदाऱ्यांचे पृथक्करण
• कार्यक्रम नोंदणी
• अभिनेता मॉडेल
• MVC, MVVM आणि MVP डिझाइन नमुने

सहयोगी दृष्टिकोन

सिस्टीम डिझाईन प्रक्रियेसाठी पूर्णपणे जबाबदार असणारा सहभागी म्हणून तुम्ही स्वतःला प्रकल्पात सापडण्याची शक्यता फारच कमी आहे. उलटपक्षी, तुम्हाला तुमच्या कामाच्या आत आणि बाहेर काम करणाऱ्या सहकाऱ्यांशी संवाद साधावा लागेल. या प्रकरणात, तुम्हाला सहकाऱ्यांसोबत निवडलेल्या तंत्रज्ञान उपायांचे मूल्यमापन करावे लागेल, व्यवसायाच्या गरजा ओळखाव्या लागतील आणि कार्यांना समांतर कसे करावे हे समजून घेणे आवश्यक आहे.

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

पहिली पायरी म्हणजे तुम्ही जे व्यावसायिक ध्येय साध्य करण्याचा प्रयत्न करत आहात आणि तुम्हाला कोणत्या हलत्या भागांना सामोरे जावे लागेल याची अचूक आणि सामायिक समज विकसित करणे. गट मॉडेलिंग तंत्र, विशेषतः वादळी घटना (इव्हेंट स्टॉर्मिंग) या प्रक्रियेला लक्षणीयरीत्या गती देण्यास मदत करते आणि तुमच्या यशाची शक्यता वाढवते. हे काम तुम्ही रुपरेषा करण्यापूर्वी किंवा नंतर केले जाऊ शकते तुमच्या सेवांच्या सीमा, आणि नंतर उत्पादन परिपक्व झाल्यावर ते खोल करा. येथे प्राप्त होणार्‍या सुसंगततेच्या स्तरावर आधारित, आपण देखील तयार करू शकता सामान्य भाषा तुम्ही ज्या मर्यादित संदर्भात काम करता. जेव्हा तुम्हाला तुमच्या सिस्टमच्या आर्किटेक्चरबद्दल बोलायचे असते, तेव्हा तुम्हाला ते उपयुक्त वाटू शकते मॉडेल C4, प्रस्तावित सायमन ब्राउन, विशेषत: जेव्हा हे समजते की तुम्हाला समस्येबद्दल किती तपशीलवार जावे लागेल, तुम्हाला ज्या गोष्टी संवाद साधायच्या आहेत त्या दृश्यमान करा.

या विषयावर कदाचित आणखी एक परिपक्व तंत्रज्ञान आहे जे डोमेन चालित डिझाइनपेक्षा कमी उपयुक्त नाही. तथापि, आम्ही कसे तरी विषय क्षेत्र समजून परत, त्यामुळे ज्ञान आणि क्षेत्रातील अनुभव डोमेन-चालित डिझाइन आपल्यासाठी उपयुक्त असावे.

स्त्रोत: www.habr.com