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