वास्तुकला चुंबन। माइक्रो सर्विस से लेकर मोनोलिथ तक

आंद्रेई कोपिलोव , हमारे तकनीकी निदेशक, क्या आवेदन वास्तुकला के दृष्टिकोण वेब डेवलपर्स के AREALIDEA टीम का उपयोग करता है बताते हैं, और इसलिए KISS आर्किटेक्चर, अपने स्वयं के विकास, की तुलना में अच्छा है।

एप्लिकेशन आर्किटेक्चर को डिजाइन करने के कई दृष्टिकोण हैं। MVC, DDD, क्लीन आर्किटेक्चर और कई अन्य।

MVC छोटे अनुप्रयोगों के लिए अच्छी तरह से अनुकूल है। जब आप स्केल करने की कोशिश करते हैं, तो एमवीसी आईटी की दुनिया में सबसे आम वास्तुकला में बदल जाता है - बिग गांठ की गंदगी ।

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

स्वच्छ वास्तुकला महान वास्तुकला है, लेकिन इसका पूर्ण कार्यान्वयन विशाल अनुप्रयोगों के लिए समझ में आता है। छोटे और मध्यम के लिए, यह मुझे बहुत जटिल लग रहा था।

वर्तमान रुझान - सेवाओं और माइक्रोसॉफ़्ट के लिए संक्रमण - इस पृष्ठभूमि के खिलाफ, क्लीन आर्किटेक्चर बहुत भारी हो रहा है।

तब ऐसा लगता है, चलो माइक्रो सर्विस के लिए MVC लेते हैं और इस पर रोक लगाते हैं। लेकिन नहीं, ऐसी साइकिल हमें शोभा नहीं देती।

के घटक

हमारी एजेंसी में परियोजनाओं के लिए साइकिल को अलग-अलग वास्तुशिल्प दृष्टिकोण से स्पेयर पार्ट्स से इकट्ठा किया जाता है।

यहां वे घटक हैं जिन्हें आपको समझने योग्य और सुविधाजनक संरचना बनाने की आवश्यकता है:

• राउटर्स
• नियंत्रकों
• दृश्य
• सेवाएं
• मॉडल

समूहों

रूटर

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

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

नियंत्रक

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

प्रत्येक नियंत्रक केवल एक इकाई को नियंत्रित करता है। यदि आपको अधिक संस्थाओं की आवश्यकता है, तो आपको एक और नियंत्रक जोड़ने की आवश्यकता है।

नियंत्रकों की संख्या और आकार अप्रत्यक्ष रूप से आपके आवेदन के आकार को इंगित करता है। कंट्रोलर के नीचे की वर्टिकल लेयर को एक अलग माइक्रोसॉर्क्स में अलग किया जा सकता है।

दृश्य

नियंत्रक के साथ दृश्य एक परत में है, डेटा के अंतिम प्रदर्शन के लिए जिम्मेदार है। सेवा से डेटा प्राप्त करने के बाद नियंत्रक डेटा को व्यू में स्थानांतरित करता है और डिस्प्ले के लिए व्यू लौटाता है।

चरम स्थिति में, देखें JSON, XML और इसी तरह के प्रारूप हैं।

सेवाएं

केवल एक सेवा में व्यावसायिक तर्क हो सकते हैं। एक सेवा आमतौर पर केवल एक मॉडल को संदर्भित करती है। एक सेवा दूसरी सेवा को कॉल कर सकती है।

सेवा परत को कमांड और प्रश्न (कमांड और क्वेरी) में विभाजित किया गया है। यह CQRS के लिए मानक दृष्टिकोण है।

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

क्वेरी में हम ऐसी सेवाएँ डालते हैं जो डेटाबेस को संशोधित नहीं करती हैं। क्वेरी में एक सार्वजनिक फ़ंक्शन होता है। कमांड्स में हम डेटाबेस को बदलने वाली सेवाएँ डालते हैं। कमांड में एक सार्वजनिक निष्पादन कार्य होता है।

मॉडल

मॉडल में केवल पढ़ने और डेटा सहेजने से जुड़े सबसे सरल तर्क हैं। इसके अलावा, ये जोड़तोड़ डेटाबेस से संबंधित नहीं हो सकते हैं।

यदि मॉडल डेटाबेस के साथ काम करता है, तो एक मॉडल केवल एक या कई टेबल पर कार्य करता है।

व्यंजनों

Mikroservis

मेरी समझ में, एक माइक्रोसेवा को केवल एक इकाई का प्रबंधन करना चाहिए। इसलिए, सरलतम माइक्रोसर्विस के लिए वास्तुकला इस तरह दिखाई देगा:

• एक राउटर;
• एक नियंत्रक;
• कई विचार;
• कई सेवाएं;
• एक मॉडल।

सेवा

सेवा एक मिनी अनुप्रयोग है। इसमें शामिल हैं:

• एक राउटर;
• कई नियंत्रक;
• कई विचार;
• कई सेवाएं;
• कई मॉडल।

केवल पत्थर का खंभा

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

मोनोलिथ में शामिल हैं:

• एक सुपर राउटर;
• कई साधारण राउटर;
• कई नियंत्रक;
• कई दृश्य, कई सेवाएँ;
• कई मॉडल।

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

वास्तुकला के सामंजस्य को बनाए रखने के लिए आपको आवश्यकता है:

1. एक शीर्ष-स्तरीय राउटर जोड़ें जो वैश्विक पथ - सुपर राउटर को हल करेगा।
2. मॉड्यूल द्वारा एक संरचना में फ़ाइलों को वितरित करें। अर्थात्, व्यक्तिगत सेवाओं में भविष्य में कटौती के अनुसार।

परीक्षण

विचाराधीन वास्तुकला के ढांचे के भीतर, केवल सेवाएं कठोर परीक्षण के अधीन हैं - केवल व्यापार तर्क उनमें अंतर्निहित है। और आपको केवल गीले मॉडल प्राप्त करने की आवश्यकता है।

यदि आपके पास सेवाओं के अलावा कुछ और परीक्षण करने की इच्छा है, तो संभवतः तर्क के लिए जगह गलत तरीके से चुनी गई है।

निष्कर्ष

मेरी राय में, परियोजनाओं के 80% के लिए वास्तुकला चुंबन और इस परियोजना के लिए एक चिकनी विकास प्रदान करता है।

यह वास्तुशिल्प दृष्टिकोण सभी डेवलपर्स के लिए स्पष्ट होगा और व्यवहार में इसके आवेदन के लिए, आपको डीडीडी के बारे में मोटी किताबें पढ़ने की आवश्यकता नहीं है।