सेवाओं के बीच संचार
FastAPI माइक्रोसर्विस के बीच संचार के विभिन्न पैटर्न लागू करें, जैसे HTTP या संदेश कतारें।
सेवाओं के बीच संचार, CoddyKit पर FastAPI बैकएंड डेवलपमेंट बूटकैंप का एक निःशुल्क पाठ है। यह 4 में से 2वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह FastAPI बैकएंड डेवलपमेंट बूटकैंप सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। FastAPI बैकएंड डेवलपमेंट बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
Services आपस में क्यों संवाद करती हैं
माइक्रोसर्विस आर्किटेक्चर में आपका एप्लिकेशन एक बड़ा प्रोग्राम नहीं होता। इसके बजाय, यह कई छोटी, स्वतंत्र सेवाओं से मिलकर बना होता है, जो मिलकर काम करती हैं। किसी साझा लक्ष्य को प्राप्त करने के लिए इन सेवाओं को एक-दूसरे से संवाद करना पड़ता है।
एक ई-कॉमर्स सिस्टम की कल्पना कीजिए: एक सेवा उपयोगकर्ता खातों को संभालती है, दूसरी उत्पादों के भंडार का प्रबंधन करती है, और तीसरी ऑर्डर संसाधित करती है। जब कोई उपयोगकर्ता ऑर्डर देता है, तो ऑर्डर सेवा को स्टॉक की जाँच करने के लिए भंडार सेवा से और भुगतान का विवरण प्राप्त करने के लिए उपयोगकर्ता सेवा से संवाद करना पड़ता है।
एचटीटीपी: सीधे संवाद
माइक्रोसर्विस के बीच संवाद करने का सबसे सामान्य तरीका एचटीटीपी अनुरोधों के माध्यम से है। यह ऐसा है जैसे एक सेवा सीधे दूसरी सेवा के एपीआई एंडपॉइंट को कॉल कर रही हो।
- समकालिक: कॉल करने वाली सेवा आगे बढ़ने से पहले उत्तर की प्रतीक्षा करती है।
- सरल: इसे समझना और लागू करना आसान है, विशेष रूप से अनुरोध-उत्तर पैटर्न के लिए।
- परिचित: इसमें वही एचटीटीपी प्रोटोकॉल इस्तेमाल होता है, जिससे आप वेब ब्राउज़िंग के दौरान पहले से परिचित हैं।
FastAPI सेवाएँ स्वाभाविक रूप से एचटीटीपी एंडपॉइंट उपलब्ध कराती हैं, इसलिए यह एक सीधी विधि है।
एचटीटीपी अनुरोध करना
Python में, requests लाइब्रेरी एचटीटीपी कॉल करने के लिए उत्कृष्ट है। यहाँ बताया गया है कि एक FastAPI सेवा उपयोगकर्ता का डेटा प्राप्त करने के लिए दूसरी सेवा को कैसे कॉल कर सकती है।
मान लीजिए कि Service B एक /users/{user_id} एंडपॉइंट उपलब्ध कराती है और Service A उसे कॉल करती है:
import requests
def get_user_from_service_b(user_id: int):
# In a real scenario, 'service_b_url' would be a config variable
service_b_url = f"http://localhost:8001/users/{user_id}"
try:
response = requests.get(service_b_url)
response.raise_for_status() # Raises HTTPError for bad responses (4xx or 5xx)
return response.json()
except requests.exceptions.RequestException as e:
print(f"Error calling Service B: {e}")
return None
if __name__ == "__main__":
print("Simulating a call to Service B for user 1...")
user_data = get_user_from_service_b(1)
if user_data:
print(f"Received user data: {user_data}")
else:
print("Failed to get user data.")
print("\nNote: For this to truly work, a service B needs to be running at http://localhost:8001.")एचटीटीपी उत्तरों को संभालना
एचटीटीपी अनुरोध करने के बाद, उत्तर को सही तरीके से संभालना बेहद महत्वपूर्ण है। इसमें एचटीटीपी स्थिति कोड की जाँच करना और उत्तर के मुख्य भाग का विश्लेषण करना शामिल है।
- स्थिति कोड:
200 OKका अर्थ सफलता है,404 Not Foundका अर्थ है कि संसाधन मौजूद नहीं था, और500 Internal Server Errorसर्वर की ओर हुई समस्या दर्शाता है। - उत्तर का मुख्य भाग: इसमें अक्सर जेएसओएन प्रारूप में डेटा होता है, जिसे आप
response.json()का उपयोग करके पार्स कर सकते हैं। - त्रुटि प्रबंधन: नेटवर्क संबंधी समस्याओं या सर्वर की त्रुटियों को पकड़ने के लिए अपने अनुरोधों को हमेशा
try-exceptब्लॉक में रखें।
लचीला एचटीटीपी: समय-सीमा और पुनः प्रयास
नेटवर्क संबंधी समस्याओं या धीमी सेवाओं के कारण आपके एचटीटीपी कॉल अटक या विफल हो सकते हैं। अपने संवाद में लचीलापन बनाना अत्यंत आवश्यक है।
- समय-सीमा: उत्तर की प्रतीक्षा करने की अधिकतम अवधि निर्धारित करें। यदि सेवा इस अवधि के भीतर उत्तर नहीं देती, तो अनुरोध विफल हो जाता है और आपकी सेवा अनिश्चित समय तक अटकने से बचती है।
- पुनः प्रयास: यदि कोई अनुरोध अस्थायी त्रुटि के कारण विफल हो जाए, जैसे नेटवर्क में क्षणिक समस्या या सेवा पर अस्थायी अधिक भार, तो आप कुछ बार थोड़े अंतराल के साथ अनुरोध का स्वचालित रूप से पुनः प्रयास कर सकते हैं।
tenacityजैसी लाइब्रेरी इसे आसानी से लागू करने में सहायता कर सकती हैं।
ये रणनीतियाँ आपकी माइक्रोसर्विस को अधिक मजबूत बनाती हैं।
संदेश कतारें: सेवाओं को अलग करना
कभी-कभी सीधे एचटीटीपी कॉल सबसे उपयुक्त विकल्प नहीं होते। ऐसे कार्यों के लिए जिनमें तुरंत उत्तर की आवश्यकता नहीं होती, या जब आप सेवाओं के बीच सीधे निर्भरताएँ कम करना चाहते हैं, संदेश कतारें बहुत उपयोगी होती हैं।
संदेश कतार मध्यस्थ की तरह काम करती है और संदेशों को तब तक संग्रहीत रखती है, जब तक कोई उपभोक्ता सेवा उन्हें संसाधित करने के लिए तैयार न हो। लोकप्रिय उदाहरणों में RabbitMQ और Apache Kafka शामिल हैं।
- असमकालिक: प्रेषक (उत्पादक) संदेश को संसाधित करने के लिए प्राप्तकर्ता (उपभोक्ता) की प्रतीक्षा नहीं करता।
- अलग-अलग: सेवाओं को एक-दूसरे के सीधे नेटवर्क स्थानों की जानकारी रखने की आवश्यकता नहीं होती।
- मापनीय: अधिक उपभोक्ता जोड़कर भार में अचानक बढ़ोतरी को आसानी से संभाला जा सकता है।
उत्पादक-उपभोक्ता मॉडल
संदेश कतारें एक सरल सिद्धांत पर काम करती हैं:
- उत्पादक: वह सेवा जो कतार में संदेश बनाकर भेजती है। यह संदेश को "भेजकर भूल जाती है"।
- कतार: एक अस्थायी भंडारण बफ़र, जो संदेशों को संसाधित होने तक संभालकर रखता है।
- उपभोक्ता: वह सेवा जो कतार पर नज़र रखती है, संदेश प्राप्त करती है और उन्हें संसाधित करती है।
यह मॉडल विशेष रूप से पृष्ठभूमि कार्यों या इवेंट-आधारित आर्किटेक्चर के लिए मजबूत, मापनीय और त्रुटि-सहिष्णु संवाद संभव बनाता है।
सैद्धांतिक संदेश उत्पादक
पूरी तरह चलने योग्य संदेश कतार का उदाहरण जटिल होता है, लेकिन यहाँ एक सैद्धांतिक Python फ़ंक्शन दिया गया है, जो दर्शाता है कि कोई सेवा कतार में संदेश कैसे "भेज" सकती है। वास्तविकता में इसमें pika (RabbitMQ के लिए) या confluent-kafka जैसी क्लाइंट लाइब्रेरी शामिल होगी।
ध्यान दें कि प्रेषक संदेश के संसाधित होने की प्रतीक्षा नहीं करता; वह बस उसे कतार में रख देता है।
import json
import time
# This is a simplified, conceptual representation.
# In a real app, 'queue_client' would be an actual library client.
class MockQueueClient:
def publish(self, queue_name: str, message: dict):
print(f"[{time.time():.2f}] PRODUCER: Sending message to '{queue_name}'...")
print(f" Message content: {json.dumps(message)}")
# In a real scenario, this would send to a message broker
print(" (Message sent to broker, producer continues its work)")
def send_new_order_event(order_details: dict):
queue_client = MockQueueClient()
queue_client.publish("order_processing_queue", order_details)
print("PRODUCER: Order event sent successfully.")
if __name__ == "__main__":
order_info = {"order_id": "ORD001", "item": "Laptop", "quantity": 1}
send_new_order_event(order_info)
print("\nPRODUCER: Service continues other tasks while order processes.")एचटीटीपी कब चुनें
एचटीटीपी संवाद आम तौर पर इन स्थितियों में पसंद किया जाता है:
- समकालिक अनुरोध: जब कॉल करने वाली सेवा को अपना कार्यप्रवाह जारी रखने के लिए तुरंत उत्तर चाहिए, जैसे उपयोगकर्ता की प्रोफ़ाइल का डेटा प्राप्त करना या ऑर्डर की पुष्टि से पहले भंडार की जाँच करना।
- अनुरोध-उत्तर पैटर्न: सरल प्रश्नों, डेटा प्राप्त करने या ऐसे कार्यों के लिए जहाँ क्लाइंट सीधे परिणाम की अपेक्षा करता है।
- घनिष्ठ जुड़ाव स्वीकार्य हो: जब सेवाओं को साथ मिलकर काम करने के लिए डिज़ाइन किया गया हो और सीधे कॉल प्रभावी हों।
- रीयल-टाइम उपयोगकर्ता संवाद: अक्सर फ्रंटएंड से बैकएंड संवाद के लिए या तत्काल यूआई अपडेट आवश्यक होने पर इस्तेमाल किया जाता है।
सही उपकरण चुनना
आपने सेवाओं के संवाद करने के दो प्रमुख तरीके देखे हैं। दोनों की अपनी खूबियाँ हैं। इस स्थिति पर विचार कीजिए:
एक उपयोगकर्ता जटिल रिपोर्ट बनाने का अनुरोध भेजता है, जिसे पूरा होने में कई मिनट लग सकते हैं। उपयोगकर्ता को इसके लिए प्रतीक्षा करने की आवश्यकता नहीं है, लेकिन वह कार्य पूरा होने पर सूचना पाना चाहता है।
प्रारंभिक अनुरोध भेजने के लिए कौन-सा संवाद पैटर्न सबसे उपयुक्त है?
पुनरावलोकन: सेवाओं का संवाद
बहुत अच्छा! आपने माइक्रोसर्विस के संवाद करने के मूलभूत तरीकों का अध्ययन किया है।
- एचटीटीपी: समकालिक, अनुरोध-उत्तर संवाद के लिए सर्वोत्तम, जहाँ तुरंत प्रतिक्रिया आवश्यक हो।
requestsजैसी लाइब्रेरी का उपयोग करके इसे सीधे और आसानी से लागू किया जा सकता है। - संदेश कतारें: असमकालिक और अलग-अलग संवाद, लंबे समय तक चलने वाले कार्यों तथा इवेंट-आधारित आर्किटेक्चर को सक्षम करने के लिए आदर्श हैं। मजबूत संदेश वितरण के लिए वे उत्पादक-उपभोक्ता मॉडल का उपयोग करती हैं।
सही पैटर्न का चुनाव आपकी जुड़ाव, विलंबता और विश्वसनीयता संबंधी विशेष आवश्यकताओं पर निर्भर करता है। अगले पाठ में हम एपीआई गेटवे बनाना सीखेंगे!
एआई शिक्षक के साथ FastAPI बैकएंड डेवलपमेंट बूटकैंप सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 21
- पाठ
- 84
अक्सर पूछे जाने वाले प्रश्न
क्या “सेवाओं के बीच संचार” पाठ निःशुल्क है?
हाँ — FastAPI बैकएंड डेवलपमेंट बूटकैंप अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “सेवाओं के बीच संचार” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। FastAPI बैकएंड डेवलपमेंट बूटकैंप पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“सेवाओं के बीच संचार” में मैं क्या सीखूँगा?
FastAPI माइक्रोसर्विस के बीच संचार के विभिन्न पैटर्न लागू करें, जैसे HTTP या संदेश कतारें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ FastAPI बैकएंड डेवलपमेंट बूटकैंप का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या FastAPI बैकएंड डेवलपमेंट बूटकैंप शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर FastAPI बैकएंड डेवलपमेंट बूटकैंप शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 2वाँ पाठ है।
“सेवाओं के बीच संचार” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस FastAPI बैकएंड डेवलपमेंट बूटकैंप पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर FastAPI बैकएंड डेवलपमेंट बूटकैंप पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- माइक्रोसर्विस आर्किटेक्चर का डिज़ाइन
- सेवाओं के बीच संचार
- FastAPI के साथ API गेटवे लागू करना
- सेवा खोज और स्वास्थ्य जाँच