API Gateway के साथ Fallback को लागू करना

API लचीलापन (Resilience) एक API की तेजी से विफल होने या विफलता के बाद भी कार्य करने की क्षमता है, जब यह उच्च ट्रैफ़िक, त्रुटियों, या आंशिक सिस्टम विफलताओं का सामना करता है। इसमें सामान्य API लचीलापन डिज़ाइन पैटर्न जैसे रिट्रीज़, टाइमआउट्स, सर्किट ब्रेकर्स, फेलओवर, और फॉलबैक्स को लागू करना शामिल है। API गेटवे का उपयोग करके फॉलबैक एक API के लिए प्लान B है - जब प्राथमिक API सेवा विफल हो जाती है, तो API गेटवे ट्रैफ़िक को एक द्वितीयक सेवा पर रीडायरेक्ट कर सकता है या एक पूर्वनिर्धारित प्रतिक्रिया वापस कर सकता है। इस लेख में, हम मौजूदा फॉलबैक तकनीकों के साथ चुनौतियों और APISIX API गेटवे का उपयोग करके उन्हें कुशलतापूर्वक कैसे लागू करें का पता लगाएंगे।

APISIX के साथ फॉलबैक लागू करना

APISIX के साथ फॉलबैक मैकेनिज्म लागू करने के लिए, आप इसकी अंतर्निहित अपस्ट्रीम प्राथमिकताएं सुविधा का उपयोग कर सकते हैं या रिस्पॉन्स-रिव्राइट प्लगइन का उपयोग करके एक पूर्वनिर्धारित प्रतिक्रिया वापस कर सकते हैं जब एक सेवा कॉल विफल हो जाती है। यहां दोनों फॉलबैक विधियों को सेट अप करने का चरण-दर-चरण उदाहरण दिया गया है।

पूर्वापेक्षाएं

यह गाइड मानती है कि निम्नलिखित टूल्स स्थानीय रूप से इंस्टॉल किए गए हैं:

• शुरू करने से पहले, APISIX की बुनियादी समझ होना अच्छा है। API गेटवे, और इसकी मुख्य अवधारणाओं जैसे रूट्स, अपस्ट्रीम, एडमिन API, प्लगइन्स, और HTTP प्रोटोकॉल की परिचितता भी लाभदायक होगी।
• Docker का उपयोग कंटेनराइज्ड etcd और APISIX इंस्टॉल करने के लिए किया जाता है।
• सेवाओं को वैलिडेट करने के लिए अनुरोध भेजने के लिए cURL इंस्टॉल करें।

APISIX Docker प्रोजेक्ट शुरू करें

यह प्रोजेक्ट मौजूदा पूर्वनिर्धारित Docker Compose कॉन्फ़िगरेशन फ़ाइल का उपयोग करता है ताकि APISIX, etcd, Prometheus, और अन्य सेवाओं को एक ही कमांड से सेट अप, डिप्लॉय, और रन किया जा सके। सबसे पहले, GitHub पर apisix-docker रेपो को क्लोन करें, इसे अपने पसंदीदा एडिटर में खोलें, example फ़ोल्डर में नेविगेट करें, और प्रोजेक्ट रूट फ़ोल्डर से टर्मिनल में docker compose up कमांड चलाकर प्रोजेक्ट शुरू करें।

जब आप प्रोजेक्ट शुरू करते हैं, तो Docker उन सभी इमेज को डाउनलोड करता है जिनकी उसे रन करने के लिए आवश्यकता होती है। यह दो उदाहरण बैकेंड सेवाएं web1 और web2 को भी रन करता है। आप docker-compose.yaml फ़ाइल में सेवाओं की पूरी सूची देख सकते हैं।

APISIX अपस्ट्रीम प्राथमिकताओं के साथ फॉलबैक

आप प्रत्येक अपस्ट्रीम नोड को एक निश्चित प्राथमिकता स्तर के साथ सेट अप कर सकते हैं। जब उच्च प्राथमिकता वाला नोड एंडपॉइंट विफल हो जाता है, तो API गेटवे ट्रैफ़िक को कम प्राथमिकता वाले द्वितीयक नोड पर रीडायरेक्ट कर सकता है। सभी नोड्स के लिए डिफ़ॉल्ट प्राथमिकता 0 है, नकारात्मक प्राथमिकता वाले नोड्स को बैकअप के रूप में कॉन्फ़िगर किया जा सकता है।

दो सेवाओं के लिए एक रूट बनाएं और प्रत्येक अपस्ट्रीम सेवा नोड के लिए प्राथमिकता विशेषता कॉन्फ़िगर करें:

curl "http://127.0.0.1:9180/apisix/admin/routes" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
   "id":"backend-service-route",
   "methods":[
      "GET"
   ],
   "uri":"/get",
   "upstream":{
      "nodes":[
         {
            "host":"web1",
            "port":80,
            "weight":1,
            "priority":0
         },
         {
            "host":"web2",
            "port":80,
            "weight":1,
            "priority":-1
         }
      ]
   }
}'

• methods: यह निर्दिष्ट करता है कि यह रूट किस HTTP मेथड से मेल खाएगा। इस मामले में, यह GET अनुरोधों से मेल खाता है।
• uri: यह वह पथ है जिससे यह रूट मेल खाएगा। इसलिए, /get पर किसी भी GET अनुरोध को इस रूट द्वारा संभाला जाएगा।
• nodes: यह बैकेंड सर्वरों की एक सरणी है। सरणी में प्रत्येक ऑब्जेक्ट एक सर्वर को उसके host, port, और weight के साथ प्रस्तुत करता है। weight का उपयोग लोड बैलेंसिंग के लिए किया जाता है; इस मामले में, दोनों सर्वर का वजन 1 है, जिसका अर्थ है कि वे ट्रैफ़िक को समान रूप से साझा करेंगे।
• priority: यह दो नोड्स (web1, web2) के लिए एक अतिरिक्त कॉन्फ़िगरेशन है। priority फ़ील्ड का उपयोग यह निर्धारित करने के लिए किया जाता है कि नोड्स को किस क्रम में चुना जाएगा। कम प्राथमिकता वाला नोड (एक उच्च नकारात्मक संख्या) केवल तब उपयोग किया जाएगा जब उच्च प्राथमिकता वाले सभी नोड्स (कम नकारात्मक संख्या या सकारात्मक संख्या) उपलब्ध नहीं होंगे।

सत्यापित करें कि जब आप रूट पर अनुरोध भेजते हैं तो आपको केवल web1 सेवा से प्रतिक्रिया मिलती है:

curl "http://127.0.0.1:9080/get"

आपको निम्नलिखित के समान प्रतिक्रिया दिखाई देनी चाहिए:

hello web1

इसका मतलब है कि web1 पहले निष्पादित हुआ है क्योंकि यह कार्य कर रहा है। अब web1 सेवा कंटेनर को रोकें ताकि यह सत्यापित किया जा सके कि APISIX web2 सेवा पर फॉलबैक करता है।

docker container stop example-web1-1

अब यदि आप फिर से रूट पर अनुरोध भेजते हैं, तो आपको हमारे द्वारा निर्दिष्ट फॉलबैक सेवा से प्रतिक्रिया मिलेगी।

curl "http://127.0.0.1:9080/get"
hello web2

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

APISIX रिस्पॉन्स रिव्राइट प्लगइन के साथ फॉलबैक

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

यदि आपने पहले दृष्टिकोण का पालन किया है, तो Docker में web1 सेवा कंटेनर को फिर से चलाएं:

docker container start example-web1-1

फॉलबैक के लिए रिस्पॉन्स-रिव्राइट प्लगइन का उपयोग करने के लिए, आपको इसे एक रूट में कॉन्फ़िगर करना होगा। यहां एक उदाहरण दिया गया है कि आप curl कमांड का उपयोग करके प्लगइन को कैसे सक्षम कर सकते हैं:

curl "http://127.0.0.1:9180/apisix/admin/routes" -H "X-API-KEY: edd1c9f034335f136f87ad84b625c8f1" -X PUT -d '
{
   "id":"backend-service-route",
   "methods":[
      "GET"
   ],
   "uri":"/get",
   "plugins":{
      "response-rewrite":{
         "status_code":200,
         "body":"{\"message\":\"This is a fallback response when the service is unavailable\"}",
         "vars":[
            [
               "status",
               "==",
               503
            ]
         ]
      }
   },
   "upstream":{
      "nodes":{
         "web1:80":1
      }
   }
}'

उपरोक्त उदाहरण में, हमने एक एकल बैकेंड सेवा (web1:80) को परिभाषित किया है जहां ट्रैफ़िक को इस रूट से मेल खाने पर निर्देशित किया जाना चाहिए। यदि अपस्ट्रीम सेवा (web1:80) 503 Service Unavailable स्थिति के साथ प्रतिक्रिया देती है, तो response-rewrite प्लगइन प्रतिक्रिया को एक कस्टम JSON बॉडी के साथ 200 OK स्थिति में संशोधित करेगा। यह प्रभावी रूप से एक फॉलबैक प्रतिक्रिया बनाता है जब अपस्ट्रीम सेवा उपलब्ध नहीं होती है।

"vars": [["status", "==", 503]]: यह स्थिति प्लगइन को यह बताती है कि रिव्राइट केवल तब लागू करें जब प्रतिक्रिया का मूल स्थिति कोड 503 Service Unavailable हो।

अब यदि आप रूट पर अनुरोध भेजते हैं, तो आपको एक संशोधित प्रतिक्रिया मिलनी चाहिए:

curl "http://127.0.0.1:9080/get"

{"message":"This is a fallback response when the service is unavailable"}

फॉलबैक मैकेनिज्म लागू करने की चुनौतियां

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

फॉलबैक लॉजिक का परीक्षण करने में कठिनाई

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

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

फॉलबैक स्वयं विफल हो सकते हैं

यदि एक फॉलबैक समाधान उतना लचीला नहीं है जितना अपेक्षित है, तो यह उस बढ़े हुए लोड के तहत विफल हो सकता है जो तब होता है जब इसे कार्रवाई में लाया जाता है, जिससे एक कैस्केडिंग विफलता हो सकती है। साथ ही, एक कम कुशल सेवा पर फॉलबैक करने से प्रतिक्रिया समय और लोड बढ़ सकता है, जिससे सिस्टम-वाइड स्लोडाउन या आउटेज हो सकता है। उदाहरण के लिए, एक API में एक रिमोट लॉगिंग सेवा अनुपलब्ध होने पर स्थानीय फ़ाइल सिस्टम पर लॉग लिखने के लिए फॉलबैक हो सकता है। यह सिंक्रोनस फ़ाइल I/O ऑपरेशन्स के कारण धीमी प्रदर्शन का कारण बन सकता है।

APISIX के साथ, आप यह सुनिश्चित करने के लिए ट्रैफ़िक को प्राथमिकता दे सकते हैं कि महत्वपूर्ण अनुरोध पहले संसाधित हों। यह फॉलबैक सेवा को अभिभूत होने से रोक सकता है और सिस्टम के प्रदर्शन को खराब होने से बचा सकता है।

फॉलबैक में परिचालन जोखिम होते हैं

फॉलबैक लागू करने से नए विफलता बिंदु पेश हो सकते हैं, जैसे कि एक द्वितीयक डेटाबेस जो प्राथमिक के साथ सिंक में नहीं है, जिससे डेटा असंगतताएं हो सकती हैं।

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

फॉलबैक में निष्क्रिय और प्रवर्धित बग हो सकते हैं

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

APISIX निरंतर A/B परीक्षण और कैनरी रिलीज़ का समर्थन करता है, जो टीमों को उत्पादन में थोड़े प्रतिशत ट्रैफ़िक के साथ फॉलबैक पाथ का परीक्षण करने की अनुमति देता है। यह निरंतर एक्सपोज़र लेटेंट बग को उजागर करने में मदद कर सकता है इससे पहले कि वे गंभीर हो जाएं।

फॉलबैक का कम उपयोग होता है

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

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

निष्कर्ष

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

संबंधित संसाधन

• API गेटवे के साथ 10 सामान्य API लचीलापन डिज़ाइन पैटर्न
• विश्वसनीय API बनाने के लिए सर्वोत्तम प्रथाएं