माइक्रोसर्विस ब्लिट्ज

Microservices का विचार नया नहीं है। पुराने लोगों ने ईजेबी के साथ काम किया होगा। यह क्या है, पहले से ही सैमुअल कोल्ट ने अपने रिवाल्वर के निर्माण के लिए एक मॉड्यूलर दृष्टिकोण का उपयोग किया था। उनकी पिस्तौल के मानक, सटीक-निर्मित हिस्से विनिमेय थे, जिन्होंने उत्पादन और रखरखाव दोनों को बहुत सरल बनाया। तो बुनियादी ढांचा क्यों नहीं होना चाहिए?

इस पर कोई मौलिक आपत्तियां नहीं हैं, और यह विचार सतह पर ही निहित है। लेकिन हाल ही में माइक्रोसर्विसेज का विषय अपेक्षाकृत लोकप्रिय हो गया है। और इसका एक कारण है।

लंबे समय तक, बुनियादी ढाँचे का रखरखाव एक श्रमसाध्य और बल्कि विशेष कार्य रहा। केवल कुशल व्यवस्थापक ही बुनियादी ढांचे में किसी भी कैश या कतार को तैनात कर सकते हैं। कि आवेदन के प्रत्येक भाग का अपना बुनियादी ढांचा था, और कोई सवाल नहीं था - इस पूरे चिड़ियाघर की सेवा कौन करेगा?

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

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

ऐसा लगता है कि यहाँ क्या गलत हो सकता है?

काश, एप्लिकेशन को भागों में विभाजित करना मुक्त नहीं है। सबसे पहले, बुनियादी ढांचे के अंदर एपीआई का समर्थन करने की लागत बढ़ रही है।

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

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

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

आवेदन को भागों में विभाजित करने से पहले, दो पहलुओं पर विचार किया जाना चाहिए।

पहले वाला। ये घटक एक ही ऑपरेशन में कितनी बार बातचीत करेंगे? क्या यह संभव है कि प्रत्येक क्रिया के लिए आपको सैकड़ों प्रदर्शन करने हों, यदि हजारों नेटवर्क कॉल न हों। यह अनुप्रयोग प्रदर्शन को मार सकता है।

दूसरा वाला। कितनी बार एपीआई घटकों के बीच बदल जाएगा? अगर git कहानी दिखाती है कि एपीआई हर दिन बदलेगा, तो उसके समर्थन की लागत निषेधात्मक होने की संभावना है। यह विकास उत्पादकता को मार सकता है।

फिर भी, सेवाओं में एप्लिकेशन के सही विभाजन के साथ, आप महत्वपूर्ण लाभ प्राप्त कर सकते हैं। बस इतना है कि इन सेवाओं को सूक्ष्म होने की आवश्यकता नहीं है।