What Is Service Discovery in Microservices

सेवा खोज (Service Discovery) क्या है? आपको इसकी आवश्यकता क्यों है?

इंटरनेट के शुरुआती दिनों में, लोगों को ऑनलाइन सेवा तक पहुंचने के लिए IP पते की एक लंबी स्ट्रिंग दर्ज करनी पड़ती थी। IP पते लंबे नहीं थे, लेकिन संख्याओं की एक अर्थहीन स्ट्रिंग के रूप में, किसी विशिष्ट सेवा का विशिष्ट पता याद रखना एक चुनौती थी, जिसके कारण डोमेन नाम प्रणाली (Domain Name System) का आविष्कार हुआ। प्रत्येक ऑनलाइन सेवा ने एक डोमेन नाम प्रदाता के साथ एक डोमेन नाम पंजीकृत किया और फिर DNS (डोमेन नाम प्रणाली) के माध्यम से डोमेन नाम और एक विशिष्ट IP के बीच एक लिंक स्थापित किया। इस तरह, लोग केवल एक यादगार डोमेन नाम टाइप करके एक विशिष्ट IP पर ऑनलाइन सेवा तक पहुंच सकते थे, जो सेवा खोज का सबसे पुराना रूप था।

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

IP पते में परिवर्तन आगंतुकों को भ्रमित कर सकता है।

DNS को एक सेवा खोज तंत्र के रूप में शामिल करके, IP परिवर्तनों को अब लचीले ढंग से संभाला जा सकता है।

सामान्य सेवा खोज प्रणालियों का परिचय

एक सेवा खोज प्रणाली के रूप में, इसे कम से कम चार कार्यों को पूरा करना होगा:

1. पंजीकरण के लिए API
2. क्वेरी करने के लिए API
3. उच्च उपलब्धता: आखिरकार, सेवा खोज प्रणाली पूरे सिस्टम की नस है और इसे पंगु या क्रैश नहीं होना चाहिए
4. इकोसिस्टम: जैसा कि हम सभी जानते हैं, प्रोग्रामर आलसी होते हैं और वे एक लाइब्रेरी पसंद करेंगे जो APIs के साथ आसानी से इंटरैक्ट कर सके

आइए बाजार में कुछ मुख्यधारा के ओपन-सोर्स सेवा खोज प्रणालियों पर एक नज़र डालें:

Consul

Consul Hashicorp द्वारा विकसित एक सेवा खोज प्रणाली है, जो एक प्रमुख ओपन-सोर्स कंपनी है। 17 अप्रैल 2014 को अपना पहला संस्करण जारी करने वाले एक लंबे समय से स्थापित सॉफ्टवेयर के रूप में, Consul के पास सबसे समृद्ध इकोसिस्टम में से एक है और इसमें तीसरे पक्ष के डेवलपर्स भी हैं जो इसके लिए Haskell का SDK विकसित करते हैं। Consul के अधिकांश SDK इसके HTTP API के लिए केवल एक रैपर हैं, इसलिए इसमें ज्यादा विकास कार्य नहीं है।

Consul HTTP API के माध्यम से सेवाओं के पंजीकरण और क्वेरी का समर्थन करता है। यह क्वेरी के दौरान समय पर डेटा पुश करने के लिए HTTP लॉन्ग पोलिंग का समर्थन करता है ताकि पोलिंग से बचा जा सके। साथ ही, Consul DNS के माध्यम से संबंधित सेवा के उदाहरण को क्वेरी करने का समर्थन करता है।

Consul का तैनाती तरीका दिलचस्प है कि Consul के प्रत्येक उदाहरण को एक एजेंट कहा जाता है, जो एक क्लाइंट या सर्वर हो सकता है। क्लाइंट साइड पर, Consul एक क्लाइंट-साइड स्थिति बनाए रखता है; सर्वर साइड पर, Consul Raft सहमति एल्गोरिदम के माध्यम से वितरित तैनाती का समर्थन करता है, ताकि उच्च उपलब्धता प्राप्त की जा सके।

Eureka

Eureka Netflix द्वारा ओपन-सोर्स किया गया एक प्रोजेक्ट है, जो काफी पुराना भी है (2012 के कमिट के निशान हैं)। हालांकि, यह प्रोजेक्ट एक साल से अधिक समय से बनाए नहीं रखा गया है। कई उपयोगकर्ताओं ने Nacos में माइग्रेट कर लिया है, जिसका उल्लेख नीचे किया जाएगा।

Eureka HTTP API और Java SDK के माध्यम से इंटरैक्शन का समर्थन करता है। Eureka के कई उपयोगकर्ता वास्तव में Java इकोसिस्टम के प्रोजेक्ट्स जैसे Spring Cloud के माध्यम से आए थे। Eureka की उच्च उपलब्धता डिजाइन, यदि आप इसे CAP (CAP प्रमेय कहता है कि एक वितरित सिस्टम एक साथ केवल तीन गुणों में से दो प्रदान कर सकता है: Consistency, Availability, और Partition tolerance) के संदर्भ में वर्णित करना चाहते हैं, तो यह AP है, जो नेटवर्क विभाजन होने पर क्लाइंट को समाप्त डेटा देखने की अनुमति देता है, ताकि नेटवर्क समस्याओं के कारण द्वितीयक आपदाओं से बचा जा सके।

Nacos

Nacos Alibaba द्वारा विकसित एक सेवा खोज प्रणाली है, जिसका नाम Naming और Configuration Service के पहले कुछ अक्षरों के समुच्चय से आता है। 20 जुलाई 2018 को संस्करण 0.1.0 जारी होने के बाद से, Nacos अब संस्करण 2.1 तक विकसित हो चुका है।

Alibaba के कई ओपन-सोर्स प्रोजेक्ट्स की तरह, Nacos चीन में Java डेवलपर्स के बीच काफी लोकप्रिय है, और इसकी लोकप्रियता Eureka से भी काफी अधिक है।

यह HTTP API और Java/Go/Python/NodeJS/C# जैसे SDKs के माध्यम से सेवाओं के पंजीकरण और क्वेरी का समर्थन करता है। वर्तमान में, Nacos डेवलपर्स gRPC पर आधारित नए APIs पर भी काम कर रहे हैं। HTTP API के लिए, Nacos वर्तमान में केवल सेवाओं की सूची के लिए पोलिंग का समर्थन करता है। इसलिए Nacos आधिकारिक तौर पर SDK तरीके को पसंद करता है, जो पोलिंग + UDP-आधारित पुश तरीका है जिसमें बेहतर रियल-टाइम प्रदर्शन होता है। Nacos gRPC पर आधारित नए APIs पर भी काम कर रहा है, जो सर्वर-साइड पुश क्षमताओं को पेश करेगा, जो उन सिस्टम्स के लिए एक बड़ा लाभ होगा जिनके पास SDK तक पहुंच नहीं है।

Nacos की उच्च उपलब्धता आंशिक रूप से क्लाइंट SDK में प्रदान की गई दृढ़ता क्षमताओं के कारण है, और आंशिक रूप से सर्वर साइड की सहमति Raft और Distro प्रोटोकॉल दोनों के माध्यम से है।

सामान्य इंटरफेसिंग तरीके और उनके फायदे और नुकसान

निजी प्रोटोकॉल को छोड़कर, सेवा खोज इंटरफेसिंग तरीकों को तीन श्रेणियों में विभाजित किया जा सकता है:

1. HTTP पोलिंग
2. DNS
3. HTTP लॉन्ग पोलिंग या gRPC सर्वर स्ट्रीमिंग

HTTP पोलिंग को लागू करना सरल है लेकिन यह रियल-टाइम नहीं है।

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

HTTP लॉन्ग पोलिंग या gRPC सर्वर स्ट्रीमिंग तीनों में सबसे अधिक रियल-टाइम है। चूंकि ये दोनों HTTP-आधारित हैं, प्रतिक्रिया को आसानी से अनुकूलित किया जा सकता है। नुकसान यह है कि ये क्लाइंट साइड पर लागू करने में अपेक्षाकृत कठिन हैं।

APISIX सेवा खोज प्रणालियों के साथ कैसे इंटरफेस करता है

एक क्लाउड-नेटिव गेटवे के रूप में, APISIX सेवा खोज प्रणाली से अपस्ट्रीम नोड्स प्राप्त करने का समर्थन करता है और डेटा प्लेन और कंट्रोल प्लेन दोनों पर सेवा खोज प्रणाली के साथ इंटरफेस करने के लिए डिज़ाइन किया गया है।

डेटा प्लेन

APISIX डेटा प्लेन पर DNS, Eureka, Consul (KV मोड), Nacos, और K8s के साथ इंटीग्रेशन का समर्थन करता है।

DNS सेवाओं के साथ इंटरफेस करते समय, APISIX DNS के SRV या A/AAAA रिकॉर्ड्स का उपयोग करके किसी सेवा के विशिष्ट अपस्ट्रीम नोड को प्राप्त करेगा। जब अपस्ट्रीम तक पहुंचने के लिए अनुरोध किया जाता है, तो यह पहले DNS कैश से इसे प्राप्त करने का प्रयास करेगा। यदि नहीं, तो यह संबंधित रिकॉर्ड के अंदर विशिष्ट IP पता प्राप्त करने के लिए एक DNS क्वेरी शुरू करेगा।

अन्य सेवा खोज प्रकारों के लिए, वे पृष्ठभूमि में सिंक्रनाइज़ होते हैं। जब अपस्ट्रीम तक पहुंचने के लिए अनुरोध किया जाता है, तो सेवा नाम के अनुरूप डेटा का हिस्सा वर्तमान में सिंक्रनाइज़ किए गए डेटा से प्राप्त किया जाता है। K8s और Consul KV के लिए, हम इस तरह से बदले हुए IP पते को रियल-टाइम में प्राप्त कर सकते हैं, क्योंकि वे HTTP लॉन्ग पोलिंग का समर्थन करते हैं। Eureka और Nacos के लिए हम वर्तमान में केवल डेटा के लिए पोलिंग कर रहे हैं।

कंट्रोल प्लेन

APISIX कंट्रोल प्लेन पर भी सेवा खोज का समर्थन करता है। हम apisix-seed पर काम कर रहे हैं, जो सेवा खोज प्रणाली से डेटा को etcd में सिंक्रनाइज़ करेगा ताकि डेटा प्लेन etcd से नवीनतम अपस्ट्रीम नोड्स को सिंक्रनाइज़ कर सके।

हमने अब कंट्रोल प्लेन पर Nacos और Zookeeper के लिए समर्थन लागू किया है। चूंकि कंट्रोल प्लेन पर सेवा खोज समर्थन आधिकारिक SDK के माध्यम से लागू किया गया है, इसलिए इसमें सामान्य HTTP तरीके से उपलब्ध नहीं होने वाले फायदे हैं। उदाहरण के लिए, Nacos के apisix-seed कार्यान्वयन में, हम UDP-आधारित पुशिंग का समर्थन करते हैं, इसलिए डेटा HTTP पोलिंग की तुलना में अधिक समय-कुशल है।

APISIX के सेवा खोज परिदृश्यों के लिए समर्थन के फायदे

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

यह एक ऐसा फायदा है जो गेटवे को माइग्रेट करते समय, उदाहरण के लिए, Spring Cloud Gateway से APISIX में, आवश्यक कार्यभार को काफी कम कर सकता है। यदि Spring Cloud Gateway का उपयोग Eureka या Nacos के लिए सेवा खोज लागू करने के लिए किया जाता है, तो नए सिस्टम में संक्रमण APISIX के भीतर Eureka या Nacos के लिए समर्थन को सक्षम करके किया जा सकता है।

Huan Bei Loan के पास इस क्षेत्र में व्यापक अनुभव है, और Spring Cloud Gateway के प्रतिस्थापन का उद्देश्य स्थिरता, पर्यवेक्षण, सटीकता और प्रभावशीलता को और बेहतर बनाना है।

Huan Bei Loan के मूल पाठ का उद्धरण:

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

इसके अलावा, APISIX एक साथ कई सेवा खोजों को कॉन्फ़िगर करने का समर्थन करता है। कई कंपनियां, ऐतिहासिक कारणों से, कई सेवा खोज प्रणालियों का उपयोग कर सकती हैं। उदाहरण के लिए, जहां तक मुझे पता है, कुछ कंपनियों में पुरानी Eureka सेवा खोज और नई Nacos सेवा खोज दोनों होंगी। APISIX को केवल Eureka और Nacos दोनों को सक्षम करने की आवश्यकता है ताकि इस स्थिति से निपटा जा सके।

यदि आप वर्तमान में APISIX पर सीधे अपस्ट्रीम नोड्स को कॉन्फ़िगर कर रहे हैं, तो आप एक अलग सेवा खोज प्रणाली तैनात करने और सेवा खोज प्रणाली को विशिष्ट नोड कॉन्फ़िगरेशन को संग्रहीत करने पर विचार कर सकते हैं। APISIX से अपस्ट्रीम नोड कॉन्फ़िगरेशन को एक समर्पित सेवा खोज प्रणाली में स्थानांतरित करने का फायदा यह है कि क्लाइंट स्वयं सेवा पंजीकरण कर सकता है, और समर्पित सेवा खोज प्रणाली अक्सर अतिरिक्त कार्यक्षमता प्रदान करती है जैसे कि समृद्ध स्वास्थ्य जांच।

भविष्य में, हम APISIX Ingress Controller पर विभिन्न सेवा पंजीकरण और खोज घटकों के इंटीग्रेशन का भी समर्थन करेंगे ताकि उपयोगकर्ताओं के लिए उपयोग करना आसान हो। उस समय, उपयोगकर्ता न केवल APISIX Ingress Controller पर K8s सेवा के एंडपॉइंट्स को अपस्ट्रीम नोड्स के रूप में निर्दिष्ट कर सकेंगे, बल्कि सेवा खोज द्वारा प्राप्त नोड्स को भी इंटीग्रेट कर सकेंगे।