सेवा खोज और संचार
वितरित माइक्रोसर्विस वातावरण में सेवाएँ एक-दूसरे को कैसे खोजती हैं और प्रभावी रूप से संचार कैसे करती हैं, यह समझिए।
सेवा खोज और संचार, CoddyKit पर AI-संचालित SaaS: Stripe + प्रमाणीकरण + बिलिंग + तैनाती का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह AI-संचालित SaaS: Stripe + प्रमाणीकरण + बिलिंग + तैनाती सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। AI-संचालित SaaS: Stripe + प्रमाणीकरण + बिलिंग + तैनाती पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
सेवा खोज का परिचय
माइक्रोसर्विस आर्किटेक्चर में एप्लिकेशन कई छोटी, स्वतंत्र सेवाओं में बाँटे जाते हैं। साथ मिलकर काम करने के लिए इन सेवाओं को एक-दूसरे को खोजकर उनसे संचार करना होता है।
सेवा खोज वह स्वचालित प्रक्रिया है जिसके द्वारा सेवाएँ नेटवर्क पर एक-दूसरे का पता लगाती हैं।
- यह उस समस्या का समाधान करती है जिसमें सेवाओं को एक-दूसरे के नेटवर्क स्थान (IP पते और पोर्ट) जानने पड़ते हैं।
- यह गतिशील, विस्तार योग्य और लचीले सिस्टम के लिए आवश्यक है।
खोज के बिना समस्या
मान लीजिए आपके पास 'User Service' और 'Order Service' हैं। यदि Order Service को उपयोगकर्ता का डेटा चाहिए, तो उसे User Service का पता मालूम होना चाहिए।
सेवा खोज के बिना:
- आप IP पते और पोर्ट को सीधे कोड में लिख सकते हैं।
- यदि कोई सेवा बड़े पैमाने पर बढ़ती है या अपना स्थान बदलती है, तो उसका पता बदल जाता है और संचार टूट जाता है।
- मैन्युअल अपडेट में गलतियाँ होने की संभावना रहती है और उनमें बहुत समय लगता है।
गतिशील क्लाउड वातावरण के लिए यह तरीका व्यवहार्य नहीं है।
सेवा रजिस्ट्री का परिचय
सेवा खोज के केंद्र में Service Registry होती है। इसे अपनी सेवाओं की फोन डायरेक्टरी की तरह समझिए।
- यह एक केंद्रीय डेटाबेस है जिसमें सभी सक्रिय सेवा इंस्टेंस के नेटवर्क स्थान संग्रहीत होते हैं।
- सेवा शुरू होने पर वह स्वयं को रजिस्ट्री में पंजीकृत करती है।
- जब किसी सेवा को संचार करना होता है, तो वह लक्ष्य सेवा का पता ढूँढ़ने के लिए रजिस्ट्री से पूछताछ करती है।
लोकप्रिय उदाहरणों में HashiCorp Consul, Netflix Eureka और etcd शामिल हैं।
सेवाएँ कैसे पंजीकृत होती हैं
सेवाओं को रजिस्ट्री को यह बताने का तरीका चाहिए कि वे मौजूद हैं और उनसे कहाँ संपर्क किया जा सकता है। इसके दो मुख्य पैटर्न हैं:
- स्व-पंजीकरण: सेवा स्वयं को सेवा रजिस्ट्री में पंजीकृत और अपंजीकृत करती है। यह समय-समय पर हार्टबीट भी भेजती है ताकि यह साबित कर सके कि वह अभी सक्रिय है।
- तृतीय-पक्ष पंजीकरण: एक अलग घटक (जिसे अक्सर 'Registrar' या 'Agent' कहा जाता है) सेवा की ओर से पंजीकरण सँभालता है। इससे सेवा और खोज तंत्र अलग-अलग हो जाते हैं।
दोनों विधियाँ सुनिश्चित करती हैं कि रजिस्ट्री में अद्यतन जानकारी मौजूद रहे।
क्लाइंट-साइड खोज की व्याख्या
क्लाइंट-साइड खोज में क्लाइंट सेवा उपलब्ध लक्ष्य सेवा इंस्टेंस ढूँढ़ने के लिए सेवा रजिस्ट्री से पूछताछ करने की जिम्मेदारी निभाती है।
- क्लाइंट खोज क्लाइंट लाइब्रेरी का उपयोग करता है (जैसे, Spring Cloud Netflix Eureka Client)।
- यह रजिस्ट्री से सेवा इंस्टेंस की सूची प्राप्त करता है।
- फिर यह किसी इंस्टेंस का चयन करने और सीधे अनुरोध भेजने के लिए भार-संतुलन एल्गोरिदम (जैसे राउंड-रॉबिन) का उपयोग करता है।
इस तरीके में खोज का तर्क प्रत्येक क्लाइंट सेवा में शामिल होता है।
सर्वर-साइड खोज की व्याख्या
सर्वर-साइड खोज में एक समर्पित घटक (आमतौर पर भार-संतुलक, API Gateway या राउटर) सेवा खोज सँभालता है।
- क्लाइंट एक सुविख्यात पते (जैसे, भार-संतुलक) पर अनुरोध भेजता है।
- भार-संतुलक लक्ष्य सेवा का उपलब्ध इंस्टेंस ढूँढ़ने के लिए सेवा रजिस्ट्री से पूछताछ करता है।
- फिर यह क्लाइंट के अनुरोध को उस इंस्टेंस तक अग्रेषित कर देता है।
यह पैटर्न क्लाइंट के तर्क को सरल बनाता है, क्योंकि क्लाइंट को खोज लाइब्रेरी की आवश्यकता नहीं होती।
सेवा संचार की मूल बातें
जब कोई सेवा दूसरी सेवा का पता खोज लेती है, तो उन्हें आपस में संचार करना होता है। इसमें आमतौर पर अनुरोध भेजना और प्रतिक्रियाएँ प्राप्त करना शामिल होता है।
- संचार तुल्यकालिक (अनुरोध-प्रतिक्रिया) या अतुल्यकालिक (इवेंट-प्रेरित) हो सकता है।
- चयन इस बात पर निर्भर करता है कि अनुरोध भेजने वाली सेवा को तुरंत प्रतिक्रिया चाहिए या वह अपना प्रसंस्करण जारी रख सकती है।
पहले सामान्य तुल्यकालिक विधियों को देखते हैं।
तुल्यकालिक संचार का उदाहरण
तुल्यकालिक संचार का अर्थ है कि अनुरोध भेजने वाली सेवा, जिस सेवा को अनुरोध भेजा गया है उसकी प्रतिक्रिया की प्रतीक्षा करती है। सबसे सामान्य प्रोटोकॉल HTTP/REST और gRPC हैं।
यहाँ एक वैचारिक Java उदाहरण दिया गया है, जिसमें दिखाया गया है कि कोई सेवा स्वयं को कैसे पंजीकृत कर सकती है और कोई क्लाइंट उसे खोजकर 'अनुरोध' कैसे भेज सकता है:
public class Main {
// Mock Service Registry
static class ServiceRegistry {
private String serviceAddress = "http://localhost:8080/my-service"; // Example address
public void register(String serviceName, String address) {
System.out.println("Service '" + serviceName + "' registered at: " + address);
this.serviceAddress = address; // Simplified: in real system, this is a map
}
public String lookup(String serviceName) {
System.out.println("Client looking up service: " + serviceName);
if (serviceName.equals("MyService")) {
return serviceAddress;
}
return null;
}
}
// Mock Service
static class MyService {
private String name = "MyService";
private String address = "http://localhost:8081/api/data";
public void startAndRegister(ServiceRegistry registry) {
System.out.println(name + " starting up...");
registry.register(name, address);
System.out.println(name + " ready to receive requests at " + address);
}
}
// Mock Client
static class MyClient {
private ServiceRegistry registry;
public MyClient(ServiceRegistry registry) {
this.registry = registry;
}
public void makeRequest(String serviceName) {
System.out.println("Client needs to call '" + serviceName + "'");
String serviceAddress = registry.lookup(serviceName); // Discovery step
if (serviceAddress != null) {
System.out.println("Found service at: " + serviceAddress);
System.out.println("Making HTTP request to " + serviceAddress + "...");
System.out.println("Response: Hello from MyService!"); // Simulating response
} else {
System.out.println("Service '" + serviceName + "' not found.");
}
}
}
public static void main(String[] args) {
ServiceRegistry registry = new ServiceRegistry();
MyService dataService = new MyService();
dataService.startAndRegister(registry); // Service registers itself
System.out.println("\n--- Client Interaction ---");
MyClient appClient = new MyClient(registry);
appClient.makeRequest("MyService"); // Client discovers and communicates
}
}अतुल्यकालिक संचार
जहाँ तुल्यकालिक संचार प्रत्यक्ष होता है, वहीं अतुल्यकालिक संचार संदेश कतारों या इवेंट स्ट्रीम का उपयोग करता है (जैसा कि पिछले पाठ में बताया गया है)।
- सेवाएँ तुरंत प्रतिक्रिया की प्रतीक्षा नहीं करतीं।
- वे किसी कतार में इवेंट या संदेश प्रकाशित करती हैं और अन्य सेवाएँ तैयार होने पर उनका उपभोग करती हैं।
- इससे सेवाएँ अलग-अलग हो जाती हैं तथा लचीलापन और विस्तारक्षमता बेहतर होती है।
सेवा खोज यह सुनिश्चित करती है कि इवेंट उत्पादक और उपभोक्ता संदेश ब्रोकर को खोज सकें।
लाभ: भार संतुलन और लचीलापन
सेवा खोज केवल सेवाओं को ढूँढ़ने तक सीमित नहीं है; यह माइक्रोसर्विस के महत्वपूर्ण लाभों को सक्षम बनाती है:
- भार संतुलन: यदि किसी सेवा के कई इंस्टेंस पंजीकृत हों, तो खोज तंत्र (क्लाइंट-साइड या सर्वर-साइड) अनुरोधों को उनके बीच समान रूप से बाँट सकता है।
- लचीलापन: यदि किसी सेवा का इंस्टेंस विफल हो जाता है, तो वह हार्टबीट भेजना बंद कर देता है या अपंजीकृत हो जाता है। रजिस्ट्री अपडेट हो जाती है और क्लाइंट/भार-संतुलक स्वचालित रूप से विफल इंस्टेंस को अनुरोध भेजना बंद कर देते हैं।
यह गतिशील अनुकूलन मज़बूत माइक्रोसर्विस के लिए महत्वपूर्ण है।
अपनी समझ जाँचें
एक ऐसी माइक्रोसर्विस व्यवस्था पर विचार कीजिए जिसमें 'Product Service' को 'Review Service' को कॉल करना है। Review Service के कई इंस्टेंस चल रहे हैं।
इस परिस्थिति में Service Registry की भूमिका का सबसे अच्छा वर्णन निम्नलिखित में से कौन-सा करता है?
पुनरावलोकन: खोज और संचार
इस पाठ में हमने माइक्रोसर्विस में सेवा खोज और संचार की महत्वपूर्ण अवधारणाओं का अध्ययन किया।
- Service Discovery सेवाओं को गतिशील रूप से एक-दूसरे को खोजने की सुविधा देती है।
- Service Registry सेवा इंस्टेंस के लिए केंद्रीय 'फोन डायरेक्टरी' है।
- हमने क्लाइंट-साइड और सर्वर-साइड खोज पैटर्न के बारे में सीखा।
- सेवाएँ तुल्यकालिक (जैसे, HTTP/REST) या अतुल्यकालिक (जैसे, संदेश कतारें) रूप से संचार करती हैं।
- खोज, भार संतुलन और लचीलेपन जैसे महत्वपूर्ण लाभ सक्षम करती है।
विस्तार योग्य और आसानी से बनाए रखी जा सकने वाली माइक्रोसर्विस आर्किटेक्चर बनाने के लिए इन पैटर्न को समझना अत्यंत आवश्यक है।
एआई शिक्षक के साथ AI-संचालित SaaS: Stripe + प्रमाणीकरण + बिलिंग + तैनाती सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 12
- पाठ
- 48
अक्सर पूछे जाने वाले प्रश्न
क्या “सेवा खोज और संचार” पाठ निःशुल्क है?
हाँ—“सेवा खोज और संचार” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और AI-संचालित SaaS: Stripe + प्रमाणीकरण + बिलिंग + तैनाती पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। AI-संचालित SaaS: Stripe + प्रमाणीकरण + बिलिंग + तैनाती पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“सेवा खोज और संचार” में मैं क्या सीखूँगा?
वितरित माइक्रोसर्विस वातावरण में सेवाएँ एक-दूसरे को कैसे खोजती हैं और प्रभावी रूप से संचार कैसे करती हैं, यह समझिए। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ AI-संचालित SaaS: Stripe + प्रमाणीकरण + बिलिंग + तैनाती का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या AI-संचालित SaaS: Stripe + प्रमाणीकरण + बिलिंग + तैनाती शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर AI-संचालित SaaS: Stripe + प्रमाणीकरण + बिलिंग + तैनाती शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।
“सेवा खोज और संचार” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस AI-संचालित SaaS: Stripe + प्रमाणीकरण + बिलिंग + तैनाती पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर AI-संचालित SaaS: Stripe + प्रमाणीकरण + बिलिंग + तैनाती पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।