मेरे बाद दोहराएँ:
बाकी और अतुल्यकालिक घटनाएं विकल्प नहीं हैं। वे पूरी तरह से रूढ़िवादी हैं।
आपके पास एक, या दूसरे, या दोनों, या दोनों हो सकते हैं। वे पूरी तरह से अलग समस्या डोमेन के लिए पूरी तरह से अलग उपकरण हैं। वास्तव में, सामान्य प्रयोजन अनुरोध-प्रतिक्रिया संचार अतुल्यकालिक, घटना-चालित, और दोष सहिष्णु होने में बिल्कुल सक्षम है ।
एक तुच्छ उदाहरण के रूप में, एएमक्यूपी प्रोटोकॉल एक टीसीपी कनेक्शन पर संदेश भेजता है। टीसीपी में, प्रत्येक पैकेट को रिसीवर द्वारा स्वीकार किया जाना चाहिए । यदि किसी पैकेट के प्रेषक को उस पैकेट के लिए ACK प्राप्त नहीं होता है, तो वह उस पैकेट का तब तक संशोधन करता रहता है जब तक कि वह ACK'd या जब तक कि आवेदन की परत "छोड़ नहीं देता" और कनेक्शन छोड़ देता है। यह स्पष्ट रूप से एक गैर-दोष-सहिष्णु अनुरोध-प्रतिसाद मॉडल है क्योंकि हर "पैकेट भेजने का अनुरोध" के साथ एक "पैकेट स्वीकार प्रतिक्रिया" होनी चाहिए , और पूरे कनेक्शन में परिणाम का जवाब देने में विफलता विफल रही। फिर भी AMQP, अतुल्यकालिक दोष सहिष्णु संदेश के लिए एक मानकीकृत और व्यापक रूप से अपनाया गया प्रोटोकॉल, टीसीपी पर संप्रेषित है! क्या देता है?
यहाँ खेलने की मुख्य अवधारणा यह है कि स्केलेबल शिथिल-युग्मित दोष-सहिष्णु संदेश को आप जो संदेश भेजते हैं , उससे परिभाषित होता है , न कि आप उन्हें कैसे भेजते हैं । दूसरे शब्दों में, अनुप्रयोग परत पर ढीली युग्मन को परिभाषित किया गया है ।
आइए दो पार्टियों को सीधे Restful HTTP के साथ या परोक्ष रूप से एक AMQP संदेश ब्रोकर के साथ संवाद करते हुए देखें। मान लीजिए कि पार्टी A पार्टी को JP B में JPEG इमेज अपलोड करना चाहती है जो इमेज को शार्प, कंप्रेस या अन्यथा बढ़ाएगी। पार्टी ए को तुरंत संसाधित छवि की आवश्यकता नहीं है, लेकिन भविष्य में उपयोग और पुनर्प्राप्ति के लिए इसे संदर्भ की आवश्यकता है। यहाँ एक तरीका है जो REST में जा सकता है:
- पार्टी ए
POSTपार्टी बी के साथ एक HTTP अनुरोध संदेश भेजता हैContent-Type: image/jpeg
- पार्टी ए छवि को संसाधित करता है (लंबे समय तक अगर यह बड़ा है) जबकि पार्टी ए इंतजार करती है, संभवतः अन्य चीजें कर रही हैं
- पार्टी बी
201 Createdपार्टी ए को एक Content-Location: <url>हेडर के साथ एक HTTP प्रतिक्रिया संदेश भेजता है जो संसाधित छवि से लिंक करता है
- पार्टी ए अपने काम पर विचार करती है क्योंकि इसमें अब संसाधित छवि का संदर्भ है
- भविष्य में कभी-कभी जब पार्टी ए को संसाधित छवि की आवश्यकता होती है, तो यह पहले के
Content-Locationहेडर से लिंक का उपयोग करके इसे प्राप्त करता है
201 Createdप्रतिक्रिया कोड एक ग्राहक है कि न केवल उनके अनुरोध सफल रहा बताता है, यह भी एक नया संसाधन बनाया। 201 की प्रतिक्रिया में, Content-Locationहेडर निर्मित संसाधन की एक कड़ी है। यह RFC 7231 धारा 6.3.2 और 3.1.4.2 में निर्दिष्ट है।
अब, देखते हैं कि यह बातचीत AMQP के शीर्ष पर एक काल्पनिक RPC प्रोटोकॉल पर कैसे काम करती है:
- पार्टी A एक AMQP संदेश ब्रोकर भेजता है (इसे मैसेंजर कहते हैं) एक संदेश जिसमें छवि होती है और इसे प्रोसेस करने के लिए पार्टी B को रूट करने के निर्देश दिए जाते हैं, फिर छवि के लिए किसी प्रकार के पते के साथ पार्टी A को जवाब देते हैं।
- पार्टी ए इंतजार कर रही है, संभवतः अन्य चीजें कर रही हैं
- मैसेंजर पार्टी बी को मूल संदेश भेजती है
- पार्टी बी संदेश को संसाधित करती है
- पार्टी बी मैसेंजर को एक संदेश भेजती है जो संसाधित छवि के लिए एक पता है और उस संदेश को पार्टी ए को रूट करने के निर्देश है
- मैसेंजर पार्टी बी को संदेश भेजती है जिसमें प्रोसेस्ड इमेज एड्रेस होता है
- पार्टी ए अपने काम पर विचार करती है क्योंकि इसमें अब संसाधित छवि का संदर्भ है
- भविष्य में पार्टी ए को छवि की आवश्यकता होने पर, यह पता का उपयोग करके छवि को पुनः प्राप्त करता है (संभवतः किसी अन्य पार्टी को संदेश भेजकर)
क्या आप यहाँ समस्या देखते हैं? दोनों ही मामलों में पार्टी एक जब तक एक छवि का पता नहीं मिल सकता है के बाद पार्टी बी चित्र को संसाधित । अभी तक पार्टी A को छवि की तुरंत आवश्यकता नहीं है, और सभी अधिकारों द्वारा, यदि प्रक्रिया समाप्त हो गई है तो कम देखभाल नहीं कर सकती है!
एएमक्यूपी मामले में हम इसे आसानी से ठीक कर सकते हैं पार्टी बी को बता दें कि बी ने प्रसंस्करण के लिए छवि को स्वीकार कर लिया है, ए को एक पता दे रहा है जहां प्रसंस्करण पूरा होने के बाद छवि होगी । तब पार्टी बी भविष्य में कुछ समय के लिए एक संदेश भेज सकती है जिससे यह संकेत मिलता है कि छवि प्रसंस्करण समाप्त हो गया है। बचाव के लिए AMQP संदेश!
सिवाय अनुमान के कि क्या: आप उसी चीज को REST के साथ प्राप्त कर सकते हैं । AMQP उदाहरण में हमने "यहाँ की संसाधित छवि" संदेश को "छवि प्रसंस्करण है, आप इसे बाद में प्राप्त कर सकते हैं" संदेश में बदल दिया। Restful HTTP में ऐसा करने के लिए, हम 202 Acceptedकोड का उपयोग करेंगे और Content-Locationफिर:
- पार्टी ए
POSTपार्टी बी के साथ एक HTTP संदेश भेजता हैContent-Type: image/jpeg
- पार्टी बी तुरंत एक
202 Acceptedप्रतिक्रिया भेजता है जिसमें "असिंक्रोनस ऑपरेशन" सामग्री का कुछ प्रकार होता है जो वर्णन करता है कि क्या प्रसंस्करण समाप्त हो गया है और प्रसंस्करण होने पर छवि उपलब्ध होगी। इसके अलावा एक Content-Location: <link>हेडर भी शामिल है , जो एक 202 Acceptedप्रतिक्रिया में, संसाधन का एक लिंक है, जो कि प्रतिक्रिया निकाय है। इस मामले में, इसका मतलब है कि यह हमारे अतुल्यकालिक ऑपरेशन का एक लिंक है!
- पार्टी ए अपने काम पर विचार करती है क्योंकि इसमें अब संसाधित छवि का संदर्भ है
- पार्टी ए को संसाधित छवि की आवश्यकता होने पर भविष्य में कभी-कभी, यह पहले ही तय हो जाता है कि प्रसंस्करण समाप्त हो गया है या नहीं , यह निर्धारित करने के लिए हेडर में लिंक किया गया एस्क्नीक ऑपरेशन संसाधन
Content-Location है। यदि ऐसा है, तो पार्टी A संसाधित छवि को प्राप्त करने के लिए स्वयं async ऑपरेशन में लिंक का उपयोग करती है।
यहाँ केवल अंतर यह है कि एएमक्यूपी मॉडल में, पार्टी बी पार्टी ए को बताती है जब छवि प्रसंस्करण किया जाता है। लेकिन REST मॉडल में, पार्टी A चेक करता है कि क्या प्रसंस्करण वास्तव में छवि की आवश्यकता से ठीक पहले किया गया है। ये दृष्टिकोण समान रूप से स्केलेबल हैं । जैसे-जैसे सिस्टम बड़ा होता जाता है, दोनों एसिंक्स एएमक्यूपी में भेजे गए संदेशों की संख्या और एसिंक्स रीस्ट की रणनीतियों में समान विषमता की जटिलता बढ़ जाती है। फर्क सिर्फ इतना है कि क्लाइंट सर्वर के बजाय एक अतिरिक्त संदेश भेज रहा है।
लेकिन आरईएसटी दृष्टिकोण में अपनी आस्तीन पर कुछ और चालें हैं: गतिशील खोज और प्रोटोकॉल बातचीत । इस बात पर विचार करें कि सिंक और एसिंक्स्ट रेस्ट इंटरैक्शन दोनों कैसे शुरू हुए। पार्टी ए ने पार्टी बी को ठीक उसी तरह का अनुरोध भेजा , जिसमें एकमात्र अंतर एक विशेष प्रकार का सफलता संदेश था जिसे पार्टी बी ने जवाब दिया। क्या होगा यदि पार्टी ए चुनना चाहता था कि छवि प्रसंस्करण तुल्यकालिक या अतुल्यकालिक है? क्या होगा यदि पार्टी A को यह पता नहीं है कि पार्टी B, async प्रसंस्करण के लिए भी सक्षम है?
खैर, HTTP वास्तव में इसके लिए पहले से ही एक मानकीकृत प्रोटोकॉल है! इसे HTTP प्राथमिकताएं कहा जाता है, विशेष रूप respond-asyncसे RFC 7240 धारा 4.1 की प्राथमिकता। यदि पार्टी A अतुल्यकालिक प्रतिक्रिया की इच्छा रखती है, तो इसमें Prefer: respond-asyncअपने प्रारंभिक POST अनुरोध के साथ एक हेडर शामिल होता है । यदि पार्टी बी इस अनुरोध का सम्मान करने का निर्णय लेती है, तो वह एक 202 Acceptedप्रतिक्रिया वापस भेजती है जिसमें एक शामिल है Preference-Applied: respond-async। अन्यथा, पार्टी बी केवल Preferहेडर को अनदेखा करती है और वापस भेजती है 201 Createdजैसा कि सामान्य रूप से होता है।
यह पार्टी ए को सर्वर के साथ बातचीत करने की अनुमति देता है, गतिशील रूप से जो भी छवि प्रसंस्करण कार्यान्वयन के लिए बात करता है, उसके साथ बात करता है। इसके अलावा, स्पष्ट लिंक्स के उपयोग का मतलब है कि पार्टी A को B के अलावा किसी भी पक्ष के बारे में पता नहीं है: कोई AMQP संदेश दलाल, कोई रहस्यमय पार्टी C जो वास्तव में छवि पते को छवि डेटा में बदलना नहीं जानता, कोई दूसरा B- Async नहीं है पार्टी अगर तुल्यकालिक और अतुल्यकालिक दोनों अनुरोध किए जाने की आवश्यकता है, आदि। यह केवल यह बताता है कि इसे क्या चाहिए, यह वैकल्पिक रूप से क्या पसंद करेगा, और फिर स्थिति कोड, प्रतिक्रिया सामग्री और लिंक पर प्रतिक्रिया करता है। जोड़ेंCache-Controlडेटा की स्थानीय प्रतियाँ रखने के बारे में स्पष्ट निर्देशों के लिए हेडर, और अब सर्वर क्लाइंट के साथ बातचीत कर सकते हैं कि कौन से संसाधन ग्राहक स्थानीय (या ऑफ़लाइन भी हो सकते हैं!) प्रतियां। इस प्रकार आप REST में शिथिल-युग्मित दोष-सहिष्णु microservices का निर्माण करते हैं।