माइक्रोसर्विसेज में एपीआई गेटवे पैटर्न को समझना: एक सरल गाइड
एकल, अखंड एप्लिकेशन से माइक्रोसर्विसेज आर्किटेक्चर में संक्रमण कई समस्याओं का समाधान करता है। यह टीमों को स्वतंत्र रूप से काम करने, सेवाओं को अलग से तैनात करने और आवश्यकतानुसार सिस्टम के हिस्सों को स्केल करने की अनुमति देता है। हालाँकि, यह एक नई चुनौती भी पेश करता है: ग्राहक इन सभी स्वतंत्र सेवाओं के साथ कैसे इंटरैक्ट करते हैं?
यदि आपके पास दस, पचास, या सैकड़ों छोटी माइक्रोसर्विसेज हैं, तो क्या एक मोबाइल ऐप या वेब पेज उनमें से प्रत्येक से सीधे जुड़ना चाहिए?
यहीं पर एपीआई गेटवे पैटर्न आता है। इस गाइड में, हम बताएंगे कि एपीआई गेटवे क्या है, आपको इसकी आवश्यकता क्यों है, और यह सरल शब्दों और वास्तविक दुनिया की उपमाओं का उपयोग करके आपके माइक्रोसर्विसेज सिस्टम को कैसे सरल बनाता है।
वास्तविक दुनिया सादृश्य: होटल रिसेप्शनिस्ट
कल्पना कीजिए कि आप एक बड़े, लक्जरी रिसॉर्ट होटल में चेक-इन कर रहे हैं। रिज़ॉर्ट में कई अलग-अलग विभाग हैं:
- हाउसकीपिंग (साफ़ चादरों के लिए)
- कक्ष सेवा (भोजन के लिए)
- दरबान (पर्यटन बुकिंग के लिए)
- बिलिंग (बिल भुगतान के लिए)
यदि आप एक साफ तौलिया चाहते हैं, तो आप हाउसकीपिंग बिल्डिंग को खोजने के लिए रिसॉर्ट में न घूमें। अगर आपको रात का खाना चाहिए तो आप रसोई का दरवाज़ा नहीं खटखटाएं। इसके बजाय, आप फ्रंट डेस्क रिसेप्शनिस्ट को बुलाएँ।
रिसेप्शनिस्ट आपके अनुरोध को सुनता है, यह निर्धारित करता है कि कौन सा विभाग इसे हल कर सकता है, और आपको जोड़ता है या आपके लिए इसे संभालता है।
इस परिदृश्य में:
- आप ग्राहक (मोबाइल ऐप या ब्राउज़र) हैं।
- रिसेप्शनिस्ट एपीआई गेटवे है।
- विभाग (हाउसकीपिंग, रूम सर्विस, बिलिंग) माइक्रोसर्विसेज हैं।
समस्या: सीधा ग्राहक-से-सेवा संचार
गेटवे कैसे काम करता है यह देखने से पहले, आइए देखें कि यदि हम इसका उपयोग नहीं करते हैं तो क्या होता है।
मान लीजिए कि आपके ई-कॉमर्स एप्लिकेशन में तीन अलग-अलग माइक्रोसर्विसेज हैं:
- उपयोगकर्ता सेवा (प्रोफ़ाइल प्रबंधित करता है)
- उत्पाद सेवा (कैटलॉग प्रबंधित करता है)
- आदेश सेवा (चेकआउट का प्रबंधन करता है)
एपीआई गेटवे के बिना, क्लाइंट ऐप को प्रत्येक सेवा के व्यक्तिगत पते (आईपी या यूआरएल) पर सीधे अलग-अलग अनुरोध भेजना होगा:
यह सीधा कनेक्शन दृष्टिकोण कई प्रमुख सिरदर्द पैदा करता है:
- बहुत सारे समापन बिंदु: क्लाइंट ऐप को तीन अलग-अलग यूआरएल याद रखने होंगे। यदि आप किसी सेवा को विभाजित करते हैं या उसका पता बदलते हैं, तो आपको क्लाइंट एप्लिकेशन को अपडेट करना होगा।
- सुरक्षा दुःस्वप्न: प्रत्येक माइक्रोसर्विस को अलग से प्रमाणीकरण (लॉगिन टोकन की जाँच करना), एसएसएल प्रमाणपत्र और फ़ायरवॉल नियम लागू करना होगा।
- नेटवर्क ओवरहेड: क्लाइंट को केवल एक पेज लोड करने के लिए धीमे मोबाइल नेटवर्क पर तीन अलग-अलग नेटवर्क अनुरोध करने की आवश्यकता हो सकती है (उदाहरण के लिए, प्रोफ़ाइल प्राप्त करें, उत्पाद विवरण प्राप्त करें, और ऑर्डर इतिहास प्राप्त करें)।
- प्रोटोकॉल अंतर: आपका क्लाइंट ऐप HTTP/JSON जैसे मानक वेब प्रोटोकॉल का उपयोग करना पसंद कर सकता है, लेकिन आपकी आंतरिक सेवाएँ gRPC या AMQP जैसे विशेष प्रोटोकॉल का उपयोग करके तेज़ी से संचार कर सकती हैं।
समाधान: एपीआई गेटवे पैटर्न
एपीआई गेटवे एक सहायक सर्वर है जो क्लाइंट एप्लिकेशन और आंतरिक माइक्रोसर्विसेज के बीच बैठता है। यह आने वाले सभी अनुरोधों के लिए प्रवेश के एकल बिंदु के रूप में कार्य करता है।
तीन अलग-अलग सेवाओं को कॉल करने के बजाय, क्लाइंट एपीआई गेटवे पर एक कॉल करता है। फिर गेटवे अनुरोध को सही आंतरिक सेवा तक अग्रेषित करता है, परिणाम एकत्र करता है, और उन्हें क्लाइंट को वापस भेजता है।
एपीआई गेटवे की प्रमुख जिम्मेदारियां
एक एपीआई गेटवे सीधे ट्रैफ़िक के अलावा और भी बहुत कुछ करता है। यह “क्रॉस-कटिंग चिंताओं” का ख्याल रखता है - ऐसे कार्य जिनके लिए प्रत्येक माइक्रोसर्विस को कोड लिखना होगा:
- रूटिंग: गेटवे एक आने वाला यूआरएल (जैसे
/api/v1/orders) लेता है और इसे सही आंतरिक सेवा पते पर मैप करता है। - प्रमाणीकरण और प्राधिकरण: गेटवे प्रवेश द्वार पर सुरक्षा टोकन (जैसे JWTs) को मान्य करता है। यदि अनुरोध अमान्य है, तो इसे तुरंत अस्वीकार कर दिया जाता है, जिससे आपके माइक्रोसर्विसेज को अप्रमाणित अनुरोधों पर सीपीयू चक्र बर्बाद करने से बचाया जा सकता है।
- दर सीमित करना: यह एक उपयोगकर्ता द्वारा प्रति मिनट किए जाने वाले अनुरोधों की संख्या को सीमित करके दुर्भावनापूर्ण बॉट या बग्गी क्लाइंट को आपके सिस्टम को स्पैम करने से रोकता है।
- लोड संतुलन: गेटवे किसी एक सर्वर को ओवरलोड होने से रोकने के लिए आने वाले ट्रैफ़िक को माइक्रोसर्विस के कई उदाहरणों में समान रूप से वितरित कर सकता है।
- प्रोटोकॉल अनुवाद: यह उपयोगकर्ता-सामना वाले JSON अनुरोधों को उच्च-प्रदर्शन वाले आंतरिक जीआरपीसी संदेशों में अनुवादित कर सकता है, जिससे सेवाओं को अपनी पसंदीदा भाषाओं में एक-दूसरे से बात करने की अनुमति मिलती है।
एक सरल कार्यान्वयन: कोड उदाहरण
यह देखने के लिए कि रूटिंग कितनी आसान हो जाती है, आइए एपीआई गेटवे स्थापित करने के दो सामान्य तरीकों पर नजर डालें।
1. घोषणात्मक रूटिंग (स्प्रिंग क्लाउड गेटवे YAML)
एंटरप्राइज़ जावा सिस्टम में, आप अक्सर एक साधारण कॉन्फ़िगरेशन फ़ाइल का उपयोग करके रूटिंग कॉन्फ़िगर करते हैं। गेटवे इन नियमों के आधार पर अनुरोधों को स्वचालित रूप से अग्रेषित करता है:
spring:
cloud:
gateway:
routes:
- id: user_service_route
uri: http://internal-user-service:8081
predicates:
- Path=/api/users/**
- id: product_service_route
uri: http://internal-product-service:8082
predicates:
- Path=/api/products/**
2. प्रोग्रामेटिक रूटिंग (नोड.जेएस गेटवे मॉकअप)
यदि आप एक्सप्रेस का उपयोग करके जावास्क्रिप्ट में एक हल्का एपीआई गेटवे बनाना चाहते हैं, तो यह इस तरह दिखता है:
const express = require('express');
const { createProxyMiddleware } = require('http-proxy-middleware');
const app = express();
const PORT = 3000;
// 1. Simple Security/Authentication Check at the door
const authenticate = (req, res, next) => {
const token = req.headers['authorization'];
if (token === 'secret-handshake-token') {
next(); // Token is valid, proceed
} else {
res.status(401).json({ error: 'Unauthorized Access!' });
}
};
// Apply auth check to all incoming gateway requests
app.use(authenticate);
// 2. Route requests to correct internal microservices
app.use('/api/users', createProxyMiddleware({ target: 'http://localhost:8081', changeOrigin: true }));
app.use('/api/products', createProxyMiddleware({ target: 'http://localhost:8082', changeOrigin: true }));
app.use('/api/orders', createProxyMiddleware({ target: 'http://localhost:8083', changeOrigin: true }));
app.listen(PORT, () => {
console.log(`API Gateway running smoothly on port ${PORT}`);
});
एपीआई गेटवे पैटर्न के फायदे और नुकसान
किसी भी वास्तुशिल्प निर्णय की तरह, एपीआई गेटवे का उपयोग करने के कुछ फायदे हैं:
| लाभ (प्रो) | हानि (कोन) |
|---|---|
| सरल क्लाइंट इंटरफ़ेस: ग्राहकों को केवल एक डोमेन नाम जानने की आवश्यकता है। | विफलता का एकल बिंदु: यदि गेटवे नीचे चला जाता है, तो संपूर्ण एप्लिकेशन अप्राप्य हो जाता है। |
| केंद्रीकृत सुरक्षा: लॉगिन जांच, एसएसएल और सीओआरएस को एक ही स्थान पर लागू करें। | अतिरिक्त विलंबता: अनुरोधों में थोड़ा अधिक समय लगता है क्योंकि उन्हें एक अतिरिक्त नेटवर्क हॉप से गुजरना होगा। |
| कोड दोहराव में कमी: प्रत्येक सेवा में प्रमाणीकरण और दर-सीमित कोड को दोबारा लिखने से बचें। | रखरखाव ओवरहेड: जब भी सेवाएँ जोड़ी जाती हैं, हटाई जाती हैं, या विभाजित की जाती हैं तो गेटवे को अद्यतन किया जाना चाहिए। |
निष्कर्ष
एपीआई गेटवे पैटर्न आधुनिक माइक्रोसर्विसेज आर्किटेक्चर की आधारशिला है। एकल, स्मार्ट प्रवेश बिंदु के रूप में कार्य करके, यह क्लाइंट अनुप्रयोगों को आंतरिक सेवा सेटअप की जटिलता से बचाता है। यह क्लाइंट-साइड कोड को सरल बनाता है, सुरक्षा को केंद्रीकृत करता है, और ट्रैफ़िक प्रबंधन को कुशलतापूर्वक संभालता है।
हालांकि यह एक मामूली नेटवर्क हॉप पेश करता है और इसे उत्पादन में उच्च उपलब्धता के साथ स्थापित करने की आवश्यकता है, क्लीनर, अधिक सुरक्षित और प्रबंधनीय कोडबेस के लाभ इसे किसी भी बढ़ती वितरित प्रणाली के लिए अत्यधिक अनुशंसित पैटर्न बनाते हैं।
ग़ज़निक्स ब्लॉग पर अधिक सॉफ़्टवेयर विकास और बैकएंड इंजीनियरिंग अंतर्दृष्टि का अन्वेषण करें →