आर्किटेक्चरल शैली निवडणे (भाग 2)

हॅलो, हॅब्र. आज मी प्रकाशनांची मालिका सुरू ठेवतो जी मी विशेषतः अभ्यासक्रमाच्या नवीन प्रवाहाच्या प्रारंभासाठी लिहिलेली आहे. "सॉफ्टवेअर आर्किटेक्ट".

परिचय

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

В गेल्या वेळी आम्ही मोनोलिथचा सामना केला आणि निष्कर्षापर्यंत पोहोचलो की मोनोलिथमध्ये अनेक समस्या आहेत: आकार, कनेक्टिव्हिटी, उपयोजन, स्केलेबिलिटी, विश्वसनीयता आणि कडकपणा.

या वेळी मी मॉड्यूल्स/लायब्ररी (घटक-देणारं आर्किटेक्चर) किंवा सेवा (सेवा-देणारं आर्किटेक्चर) संच म्हणून प्रणाली आयोजित करण्याच्या शक्यतांबद्दल बोलण्याचा प्रस्ताव देतो.

घटक-देणारं आर्किटेक्चर

घटक-देणारं आर्किटेक्चरमध्ये घटकांचा एक संच म्हणून सिस्टम कार्यान्वित करणे समाविष्ट आहे जे वर्तमान आणि भविष्यातील दोन्ही प्रकल्पांमध्ये वापरले जाऊ शकते. घटकांमध्ये प्रणालीचे विभाजन करताना, खालील गोष्टी विचारात घेतल्या जातात: त्यांची पुन: उपयोगिता, त्यांची बदलण्याची क्षमता, संदर्भ स्वातंत्र्य, विस्तारक्षमता, एन्कॅप्सुलेशन आणि स्वातंत्र्य.

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

बहुतेकदा, मोनोलिथ्स मॉड्यूल्सचा संच म्हणून विकसित केले जातात. हा दृष्टिकोन स्वतंत्र विकासाकडे नेतो, परंतु स्वतंत्र स्केलिंग आणि उपयोजन, दोष सहिष्णुता आणि संपूर्ण तंत्रज्ञानाच्या स्टॅकपासून स्वातंत्र्याच्या समस्या कायम आहेत. म्हणूनच मॉड्यूल हा अंशतः स्वतंत्र घटक आहे.

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

"आदर्श" मोनोलिथ हा तार्किकदृष्ट्या विभक्त मॉड्यूलचा एक संच आहे, ज्यापैकी प्रत्येक त्याच्या स्वतःच्या डेटाबेसमध्ये पाहतो.

सेवा-देणारं वास्तुकला

जर प्रणाली सेवांच्या संचाच्या स्वरूपात आयोजित केली गेली असेल, तर आम्ही सेवा-देणारं आर्किटेक्चरबद्दल बोलत आहोत. त्याची तत्त्वे वापरकर्ता-केंद्रित अनुप्रयोग इंटरऑपरेबिलिटी, व्यवसाय सेवा पुनर्वापर, तंत्रज्ञान स्टॅक स्वातंत्र्य आणि स्वायत्तता (स्वतंत्र उत्क्रांती, स्केलेबिलिटी आणि उपयोजन) आहेत.

सर्व्हिस-ओरिएंटेड आर्किटेक्चर (SOA = सर्व्हिस ओरिएंटेड आर्किटेक्चर) मोनोलिथच्या सर्व ओळखल्या गेलेल्या समस्यांचे निराकरण करते: जेव्हा बदल होतो तेव्हा फक्त एक सेवा प्रभावित होते आणि एक सु-परिभाषित API घटकांच्या चांगल्या एन्कॅप्युलेशनला समर्थन देते.

परंतु सर्व काही इतके गुळगुळीत नाही: SOA नवीन समस्या निर्माण करते. स्थानिक कॉलपेक्षा रिमोट कॉल अधिक महाग आहेत आणि घटकांमधील जबाबदाऱ्यांचे पुनर्वितरण लक्षणीयरीत्या महाग झाले आहे.

तसे, स्वतंत्र तैनातीची शक्यता हे सेवेचे एक अतिशय महत्वाचे वैशिष्ट्य आहे. जर सेवा एकत्रितपणे तैनात केल्या पाहिजेत किंवा त्याशिवाय, एका विशिष्ट क्रमाने, सिस्टमला सेवा-देणारं मानले जाऊ शकत नाही. या प्रकरणात, ते वितरित मोनोलिथबद्दल बोलतात (फक्त SOA च्या दृष्टिकोनातूनच नव्हे तर मायक्रोसर्व्हिस आर्किटेक्चरच्या दृष्टिकोनातून देखील विरोधी नमुना मानले जाते).

सेवा-देणारं आर्किटेक्चरला आर्किटेक्चरल समुदाय आणि विक्रेत्यांचे चांगले समर्थन आहे. हे अनेक अभ्यासक्रम आणि प्रमाणपत्रे, तसेच विकसित नमुन्यांची उपस्थिती सूचित करते. नंतरच्यामध्ये, उदाहरणार्थ, सुप्रसिद्ध एंटरप्राइझ सेवा बस (ESB = एंटरप्राइझ सर्व्हिस बस) समाविष्ट आहे. त्याच वेळी, ESB हे विक्रेत्यांचे सामान आहे; ते SOA मध्ये वापरले जाणे आवश्यक नाही.

सेवा-देणारं आर्किटेक्चरची लोकप्रियता 2008 च्या आसपास शिगेला पोहोचली, त्यानंतर ती कमी होऊ लागली, जी मायक्रोसर्व्हिसेस (~2015) च्या आगमनानंतर लक्षणीयरीत्या अधिक नाट्यमय झाली.

निष्कर्ष

आम्ही सेवा आणि मॉड्यूल्सच्या स्वरूपात माहिती प्रणाली आयोजित करण्याच्या शक्यतांवर चर्चा केल्यानंतर, मी शेवटी मायक्रोसर्व्हिस आर्किटेक्चरच्या तत्त्वांकडे जाण्याचा आणि मायक्रोसर्व्हिस आर्किटेक्चर आणि सर्व्हिस-ओरिएंटेड आर्किटेक्चरमधील फरकांवर विशेष लक्ष देण्याचा प्रस्ताव पुढील भागात देतो.

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