मोनोलिथ की रक्षा में कुछ शब्द

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

5 साल पहले भी, किसी ने भी माइक्रोसॉर्क्स के बारे में नहीं सुना था। हालाँकि, Google Trends के आंकड़ों के अनुसार, साल-दर-साल उनकी लोकप्रियता बढ़ रही है।

मोनोलिथ और माइक्रोसर्विसेज: उदाहरण

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



माइक्रोसैसवर्क आर्किटेक्चर में अलग-अलग प्रक्रियाओं के रूप में चलने वाले मॉड्यूल में टूटना और अलग सर्वर हो सकते हैं। प्रत्येक माइक्रोसिस्ट अपने डेटाबेस के साथ काम करता है, और ये सभी सेवाएँ एक दूसरे के साथ सिंक्रोनाइज़ (http) और एसिंक्रोनस रूप से संवाद कर सकते हैं। इसके अलावा, वास्तुकला को अनुकूलित करने के लिए, सेवाओं के बीच संबंध को कम करना वांछनीय है।

नीचे दिया गया आरेख सरल है, यह दर्शाता है, सबसे पहले, व्यावसायिक घटक।

माइक्रोसर्विसेज: लाभ

माइक्रोसर्विस आर्किटेक्चर के कम से कम चार फायदे हैं:

स्वतंत्र स्केलिंग और तैनाती

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

स्वतंत्र विकास

सॉफ़्टवेयर उत्पाद बनाने की गति बढ़ाने के लिए प्रत्येक माइक्रोसेर सर्विस (उदाहरण के लिए, एक मेमोरी मॉड्यूल) को एक टीम द्वारा विकसित किया जा सकता है।

स्थिरता

एक माइक्रोसेवा की विफलता अन्य मॉड्यूल के प्रदर्शन को प्रभावित नहीं करती है।

विविधता

प्रत्येक टीम माइक्रोसर्विस को लागू करने के लिए अपनी भाषा और तकनीक चुनने के लिए स्वतंत्र है, हालांकि, यह वांछनीय है कि उनके पास संगत इंटरफेस है।

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

आइए देखें कि क्या सभी को वास्तव में सबसे बड़े ब्रांडों के उदाहरण के बाद एक मोनोलिथ से माइक्रोसर्विस पर स्विच करना चाहिए?

Microservices के लिए स्विचन: संभव कठिनाइयों

समस्या एक: अपघटन

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

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



समस्या दो: लेन-देन

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

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

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



समस्या तीन: रिपोर्टिंग

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

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



समस्या चार: उच्च विकास जटिलता

वितरित सेवाओं पर काम अधिक जटिल है: सभी अनुरोध नेटवर्क पर किए जाते हैं और इसे बंद किया जा सकता है, आपको कॉलबैक तंत्र प्रदान करना होगा (क्या यह कॉल फिर से करेगा? कितनी बार?)। ये "ईंटें" हैं जो धीरे-धीरे जमा होती हैं और परियोजना की जटिलता को बढ़ाने में योगदान करती हैं।

सेवाओं को कई अलग-अलग टीमों द्वारा विकसित किया जा सकता है, और आपको उन्हें दस्तावेज बनाने की आवश्यकता है, संस्करण को बदलते समय अन्य टीमों को चेतावनी देने के लिए दस्तावेज रखें। ये अतिरिक्त श्रम लागत हैं।

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

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





पांचवीं समस्या: परीक्षण, अनुरेखण और डिबगिंग की जटिलता

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

माइक्रोसर्विस या मोनोलिथ: चयन मानदंड

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

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



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

प्रत्येक मॉड्यूल का अपना एपीआई होना चाहिए, ताकि बाद में इसे आवंटित किया जा सके और मॉड्यूल को एक माइक्रो सर्विस बनाया जा सके।



मॉड्यूल की सीमाओं को निर्धारित करने के बाद, यदि आवश्यक हो, तो आप विघटन को माइक्रोसर्विस में आगे बढ़ा सकते हैं। लगभग 90% मामलों में मोनोलिथ पर रहना संभव होगा, लेकिन यदि आवश्यक हो तो वास्तुकला को बदलना आसान और सस्ता होगा।

मोनोलिथ और माइक्रोसर्विस के साथ काम करने के हमारे अभ्यास में, हम निम्नलिखित निष्कर्ष पर आए:

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