Back to Blog

माइक्रोसर्विस आर्किटेक्चर के लिए प्रॉक्सी: एपीआई सुरक्षा, लोड बैलेंसिंग और सुरक्षा

प्रॉक्सी को माइक्रोसर्विस आर्किटेक्चर में एकीकृत करने के लिए पूर्ण मार्गदर्शिका: API सुरक्षा, लोड बैलेंसिंग, सेवाओं के बीच संचार की सुरक्षा और सेटअप के उदाहरण।

📅February 18, 2026
```html

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

माइक्रोसर्विस आर्किटेक्चर में प्रॉक्सी की भूमिका

माइक्रोसर्विस आर्किटेक्चर में प्रॉक्सी सर्वर कई महत्वपूर्ण कार्य करते हैं, जो पारंपरिक प्रॉक्सी के उपयोग से भिन्न होते हैं, जैसे कि गुमनामी या ब्लॉक को बायपास करना। यहां प्रॉक्सी अवसंरचना का एक अभिन्न हिस्सा बन जाते हैं, जो सिस्टम के घटकों के बीच विश्वसनीय और सुरक्षित संचार सुनिश्चित करते हैं।

माइक्रोसर्विसेज में प्रॉक्सी की मुख्य भूमिकाएँ:

  • API गेटवे — सभी ग्राहक अनुरोधों के लिए एकल प्रवेश बिंदु, जो उन्हें संबंधित माइक्रोसर्विसेज की ओर रूट करता है, सिस्टम की आंतरिक आर्किटेक्चर को छुपाता है
  • साइडकार प्रॉक्सी — प्रत्येक सेवा के साथ काम करने वाला प्रॉक्सी कंटेनर (सर्विस मेष पैटर्न), सभी आने वाले और जाने वाले ट्रैफ़िक को पकड़ता है
  • रिवर्स प्रॉक्सी — एक सेवा के कई उदाहरणों के बीच लोड का वितरण, विफलता सहनशीलता सुनिश्चित करना
  • फॉरवर्ड प्रॉक्सी — बाहरी API के लिए जाने वाले अनुरोधों की निगरानी और सुरक्षा, आंतरिक IP पते को छुपाना
  • सुरक्षा प्रॉक्सी — SSL/TLS टर्मिनेशन, प्रमाणीकरण, प्राधिकरण, DDoS और अन्य हमलों से सुरक्षा

प्रॉक्सी महत्वपूर्ण आर्किटेक्चरल पैटर्न को लागू करने की अनुमति देती हैं: सर्किट ब्रेकर (असफल सेवाओं को स्वचालित रूप से बंद करना), पुनः प्रयास लॉजिक (विफलताओं पर पुनः प्रयास), दर सीमित करना (अनुरोधों की आवृत्ति को सीमित करना), अनुरोध/प्रतिक्रिया रूपांतरण (डेटा प्रारूपों का परिवर्तन)। यह सब सिस्टम को विफलताओं के प्रति अधिक सहनशील बनाता है और जटिल वितरित अवसंरचना के प्रबंधन को सरल बनाता है।

महत्वपूर्ण: माइक्रोसर्विस आर्किटेक्चर में प्रॉक्सी दो स्तरों पर काम करती हैं — ग्राहकों के लिए एक बाहरी गेटवे (API गेटवे) के रूप में और सेवाओं के बीच आंतरिक प्रॉक्सी (सर्विस मेष) के रूप में। दोनों स्तर सिस्टम की सुरक्षा और विश्वसनीयता के लिए महत्वपूर्ण हैं।

विभिन्न उपयोग परिदृश्यों के लिए प्रॉक्सी के प्रकार

प्रॉक्सी के प्रकार का चयन माइक्रोसर्विस आर्किटेक्चर में विशिष्ट कार्य पर निर्भर करता है। विभिन्न परिदृश्यों को विभिन्न विशेषताओं की आवश्यकता होती है: गति, विश्वसनीयता, गुमनामी या भौगोलिक वितरण।

परिदृश्य प्रॉक्सी का प्रकार क्यों
सेवाओं के बीच आंतरिक संचार HTTP/HTTPS प्रॉक्सी (Envoy, NGINX) अधिकतम गति, कम विलंबता, HTTP/2 का समर्थन
बाहरी API के लिए सीमित अनुरोध रहने वाले प्रॉक्सी दर सीमाओं को बायपास करना, वास्तविक उपयोगकर्ताओं के IP, ब्लॉक होने का कम जोखिम
विश्लेषण के लिए डेटा पार्सिंग डेटा सेंटर प्रॉक्सी उच्च गति, कम लागत, बड़े पैमाने पर अनुरोधों के लिए उपयुक्त
मोबाइल API के साथ काम करना मोबाइल प्रॉक्सी वास्तविक मोबाइल उपयोगकर्ताओं की नकल, मोबाइल-केवल API तक पहुंच
लोड बैलेंसिंग रिवर्स प्रॉक्सी (HAProxy, NGINX) ट्रैफ़िक का वितरण, स्वास्थ्य जांच, विफलताओं पर स्वचालित स्विचिंग
भौगोलिक रूप से वितरित प्रणाली भौगोलिक लक्षित रहने वाले प्रॉक्सी क्षेत्रीय API तक पहुंच, डेटा स्थानीयकरण आवश्यकताओं का अनुपालन

माइक्रोसर्विसेज के बीच आंतरिक संचार के लिए आमतौर पर Envoy प्रॉक्सी या NGINX जैसे विशेष प्रॉक्सी समाधान का उपयोग किया जाता है, जो कम विलंबता और उच्च बैंडविड्थ के लिए अनुकूलित होते हैं। वे आधुनिक प्रोटोकॉल (HTTP/2, gRPC) का समर्थन करते हैं और सर्विस मेष सिस्टम के साथ एकीकृत होते हैं।

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

API गेटवे के रूप में प्रॉक्सी: सुरक्षा और रूटिंग

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

API गेटवे के मुख्य कार्य:

  • अनुरोधों की रूटिंग — यह निर्धारित करना कि कौन सी माइक्रोसर्विस को अनुरोध को संसाधित करना चाहिए, URL, हेडर या अन्य पैरामीटर के आधार पर
  • प्रमाणीकरण और प्राधिकरण — टोकनों (JWT, OAuth) की जांच, विभिन्न सेवाओं के लिए पहुंच प्रबंधन
  • दर सीमित करना — ओवरलोडिंग और DDoS से सुरक्षा के लिए एक ग्राहक से अनुरोधों की संख्या को सीमित करना
  • उत्तर का समेकन — एक ग्राहक को कई सेवाओं से डेटा को एक उत्तर में एकत्रित करना
  • प्रोटोकॉल रूपांतरण — REST को gRPC, HTTP/1.1 को HTTP/2 में परिवर्तित करना
  • कैशिंग — सेवाओं पर लोड को कम करने के लिए अक्सर अनुरोधित डेटा को सहेजना
  • लॉगिंग और निगरानी — सभी अनुरोधों के मेट्रिक्स और लॉग का केंद्रीकृत संग्रह

API गेटवे के लिए लोकप्रिय समाधान: Kong, Tyk, AWS API गेटवे, Azure API प्रबंधन, NGINX प्लस, Traefik। चयन प्रणाली के पैमाने, प्रदर्शन आवश्यकताओं और उपयोग की जाने वाली क्लाउड प्लेटफ़ॉर्म पर निर्भर करता है।

// NGINX को API गेटवे के रूप में कॉन्फ़िगर करने का उदाहरण
upstream auth_service {
    server auth:8001;
}

upstream user_service {
    server user:8002;
}

upstream order_service {
    server order:8003;
}

server {
    listen 80;
    server_name api.example.com;

    # अनुरोधों की दर सीमित करना
    limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

    location /api/auth/ {
        limit_req zone=api_limit burst=20;
        proxy_pass http://auth_service/;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }

    location /api/users/ {
        # प्रॉक्सी करने से पहले टोकन की जांच
        auth_request /auth/verify;
        proxy_pass http://user_service/;
    }

    location /api/orders/ {
        auth_request /auth/verify;
        proxy_pass http://order_service/;
    }

    # टोकनों की जांच के लिए आंतरिक एंडपॉइंट
    location = /auth/verify {
        internal;
        proxy_pass http://auth_service/verify;
        proxy_pass_request_body off;
        proxy_set_header Content-Length "";
    }
}

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

सर्विस मेष (Istio, Linkerd) के साथ एकीकरण

सर्विस मेष एक अवसंरचना स्तर है, जो प्रॉक्सी सर्वरों के माध्यम से माइक्रोसर्विसेज के बीच संचार का प्रबंधन करता है, जो प्रत्येक सेवा के साथ तैनात होते हैं (साइडकार पैटर्न)। API गेटवे के विपरीत, जो केवल बाहरी ट्रैफ़िक को संभालता है, सर्विस मेष सेवाओं के बीच सभी आंतरिक ट्रैफ़िक को नियंत्रित करता है।

सबसे लोकप्रिय सर्विस मेष समाधान — Istio (जो साइडकार के रूप में Envoy प्रॉक्सी का उपयोग करता है) और Linkerd (जो अपना हल्का प्रॉक्सी उपयोग करता है)। वे स्वचालित रूप से Kubernetes में प्रत्येक पॉड के बगल में प्रॉक्सी कंटेनर को तैनात करते हैं, सभी आने वाले और जाने वाले ट्रैफ़िक को पकड़ते हैं।

प्रॉक्सी के माध्यम से सर्विस मेष की क्षमताएँ:

  • म्यूचुअल TLS (mTLS) — सेवाओं के बीच सभी ट्रैफ़िक को स्वचालित रूप से एन्क्रिप्ट करना, पारस्परिक प्रमाणीकरण के साथ
  • ट्रैफ़िक प्रबंधन — रूटिंग का प्रबंधन, कैनरी तैनाती, A/B परीक्षण
  • पर्यवेक्षण — बिना सेवाओं के कोड को बदले स्वचालित रूप से मेट्रिक्स, ट्रेस और लॉग का संग्रह
  • सहिष्णुता — सर्किट ब्रेकिंग, पुनः प्रयास लॉजिक, टाइमआउट प्रबंधन, परीक्षण के लिए दोष इंजेक्शन
  • सेवा खोज — सेवाओं का स्वचालित पता लगाना और लोड बैलेंसिंग
# Istio वर्चुअल सर्विस के लिए रूटिंग कॉन्फ़िगरेशन का उदाहरण
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: user-service
spec:
  hosts:
  - user-service
  http:
  - match:
    - headers:
        version:
          exact: "v2"
    route:
    - destination:
        host: user-service
        subset: v2
  - route:
    - destination:
        host: user-service
        subset: v1
      weight: 90
    - destination:
        host: user-service
        subset: v2
      weight: 10  # कैनरी तैनाती: v2 पर 10% ट्रैफ़िक

---
# सर्किट ब्रेकर कैस्केडिंग विफलताओं से सुरक्षा के लिए
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: user-service
spec:
  host: user-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
      http:
        http1MaxPendingRequests: 50
        maxRequestsPerConnection: 2
    outlierDetection:
      consecutiveErrors: 5
      interval: 30s
      baseEjectionTime: 30s
      maxEjectionPercent: 50

सर्विस मेष "वितरित मोनोलिथ" की समस्या को हल करता है — जब सेवाओं के बीच बातचीत की लॉजिक (पुनः प्रयास, टाइमआउट, सर्किट ब्रेकिंग) प्रत्येक सेवा के कोड में डुप्लिकेट होती है। इसके बजाय, यह सभी लॉजिक प्रॉक्सी स्तर पर ले जाया जाता है, जो सेवाओं के कोड को सरल बनाता है और पूरे सिस्टम के लिए एक समान व्यवहार सुनिश्चित करता है।

एक महत्वपूर्ण लाभ — ट्रैफ़िक की पूरी पारदर्शिता। सेवाओं के बीच प्रत्येक अनुरोध प्रॉक्सी के माध्यम से गुजरता है, जो मेट्रिक्स को लॉग करता है: प्रतिक्रिया समय, त्रुटि कोड, पेलोड का आकार। ये डेटा स्वचालित रूप से निगरानी (Prometheus, Grafana) और ट्रेसिंग (Jaeger, Zipkin) सिस्टम में भेजे जाते हैं, जिससे वितरित प्रणाली के कामकाज की पूरी तस्वीर बनाई जाती है बिना प्रत्येक सेवा के कोड में उपकरण जोड़ने की आवश्यकता के।

प्रॉक्सी के माध्यम से बाहरी API के लिए अनुरोधों की सुरक्षा

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

बाहरी अनुरोधों के लिए प्रॉक्सी का उपयोग इन समस्याओं को हल करता है और अतिरिक्त क्षमताएँ जोड़ता है:

  • अवसंरचना को छुपाना — बाहरी API प्रॉक्सी के IP पतों को देखते हैं, न कि आपके सर्वरों के
  • दर सीमाओं को बायपास करना — अनुरोधों के वितरण के लिए IP पतों का रोटेशन
  • भौगोलिक वितरण — आवश्यक देशों में प्रॉक्सी के माध्यम से क्षेत्रीय API तक पहुंच
  • केंद्रीकृत प्रबंधन — सभी जाने वाले अनुरोधों का एकल नियंत्रण बिंदु
  • उत्तर की कैशिंग — महंगे API के लिए अनुरोधों की संख्या को कम करना
  • निगरानी और लॉगिंग — बाहरी सेवाओं के सभी संपर्कों की ट्रैकिंग
// Python: बाहरी API के लिए अनुरोधों के लिए प्रॉक्सी सेटअप
import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

class ExternalAPIClient:
    def __init__(self, proxy_url, proxy_rotation=False):
        self.session = requests.Session()
        
        # प्रॉक्सी सेटअप
        self.proxies = {
            'http': proxy_url,
            'https': proxy_url
        }
        
        # विफलता के लिए पुनः प्रयास लॉजिक
        retry_strategy = Retry(
            total=3,
            backoff_factor=1,
            status_forcelist=[429, 500, 502, 503, 504],
            allowed_methods=["GET", "POST"]
        )
        adapter = HTTPAdapter(max_retries=retry_strategy)
        self.session.mount("http://", adapter)
        self.session.mount("https://", adapter)
    
    def call_payment_api(self, data):
        """प्रॉक्सी के माध्यम से भुगतान API के लिए अनुरोध"""
        try:
            response = self.session.post(
                'https://api.payment-provider.com/charge',
                json=data,
                proxies=self.proxies,
                timeout=10,
                headers={'User-Agent': 'MyService/1.0'}
            )
            response.raise_for_status()
            return response.json()
        except requests.exceptions.RequestException as e:
            # त्रुटि लॉगिंग
            print(f"Payment API error: {e}")
            raise

# रोटेशन के लिए प्रॉक्सी पूल के साथ उपयोग
class ProxyPool:
    def __init__(self, proxy_list):
        self.proxies = proxy_list
        self.current = 0
    
    def get_next(self):
        proxy = self.proxies[self.current]
        self.current = (self.current + 1) % len(self.proxies)
        return proxy

# प्रारंभ
proxy_pool = ProxyPool([
    'http://user:pass@proxy1.example.com:8080',
    'http://user:pass@proxy2.example.com:8080',
    'http://user:pass@proxy3.example.com:8080'
])

# प्रत्येक अनुरोध के लिए अगला प्रॉक्सी का उपयोग करें
client = ExternalAPIClient(proxy_pool.get_next())

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

// Node.js: बाहरी API के लिए प्रॉक्सी के साथ स्वचालित रोटेशन
const axios = require('axios');
const HttpsProxyAgent = require('https-proxy-agent');

class ExternalAPIService {
  constructor(proxyList) {
    this.proxyList = proxyList;
    this.currentProxyIndex = 0;
    this.requestCounts = new Map(); // दर सीमित करने के लिए अनुरोध काउंटर
  }

  getNextProxy() {
    const proxy = this.proxyList[this.currentProxyIndex];
    this.currentProxyIndex = (this.currentProxyIndex + 1) % this.proxyList.length;
    return proxy;
  }

  async callAPI(endpoint, data, options = {}) {
    const proxyUrl = this.getNextProxy();
    const agent = new HttpsProxyAgent(proxyUrl);

    // दर सीमित करना: प्रॉक्सी पर प्रति मिनट 100 अनुरोधों से अधिक नहीं
    const proxyKey = proxyUrl;
    const now = Date.now();
    const count = this.requestCounts.get(proxyKey) || { count: 0, resetTime: now + 60000 };
    
    if (count.count >= 100 && now < count.resetTime) {
      // अगले प्रॉक्सी पर स्विच करें
      return this.callAPI(endpoint, data, options);
    }

    try {
      const response = await axios({
        method: options.method || 'POST',
        url: endpoint,
        data: data,
        httpsAgent: agent,
        timeout: options.timeout || 10000,
        headers: {
          'User-Agent': 'Mozilla/5.0 (compatible; MyService/1.0)',
          ...options.headers
        }
      });

      // काउंटर को अपडेट करें
      if (now >= count.resetTime) {
        this.requestCounts.set(proxyKey, { count: 1, resetTime: now + 60000 });
      } else {
        count.count++;
      }

      return response.data;
    } catch (error) {
      if (error.response?.status === 429) {
        // दर सीमा पार हो गई - दूसरे प्रॉक्सी पर स्विच करें
        console.log(`Rate limit on ${proxyUrl}, switching proxy`);
        return this.callAPI(endpoint, data, options);
      }
      throw error;
    }
  }
}

// उपयोग
const apiService = new ExternalAPIService([
  'http://user:pass@proxy1.example.com:8080',
  'http://user:pass@proxy2.example.com:8080'
]);

module.exports = apiService;

लोड बैलेंसिंग और विफलता सहनशीलता

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

लोड बैलेंसिंग के मुख्य एल्गोरिदम:

  • राउंड रॉबिन — सूची में प्रत्येक सर्वर पर बारी-बारी से अनुरोध भेजना, समान सर्वरों के लिए सरल और प्रभावी
  • लीस्ट कनेक्शंस — सबसे कम सक्रिय कनेक्शंस वाले सर्वर पर अनुरोध भेजना, लंबे अनुरोधों के लिए उपयुक्त
  • IP हैश — ग्राहक को उसके IP के आधार पर एक विशेष सर्वर से जोड़ना, स्थायी सत्र सुनिश्चित करना
  • वेटेड राउंड रॉबिन — सर्वरों की शक्ति को ध्यान में रखते हुए वितरण (अधिक शक्तिशाली को अधिक अनुरोध मिलते हैं)
  • रैंडम — सर्वर का यादृच्छिक चयन, stateless सेवाओं के लिए उपयुक्त
# HAProxy कॉन्फ़िगरेशन स्वास्थ्य जांच के साथ लोड बैलेंसिंग के लिए
global
    maxconn 4096
    log stdout format raw local0

defaults
    mode http
    timeout connect 5s
    timeout client 50s
    timeout server 50s
    option httplog

frontend api_frontend
    bind *:80
    default_backend api_servers

backend api_servers
    balance roundrobin
    
    # स्वास्थ्य जांच: हर 2 सेकंड में /health की जांच
    option httpchk GET /health
    http-check expect status 200
    
    # पुनः प्रयास लॉजिक
    retries 3
    option redispatch
    
    # वजन के साथ सर्वर (server3 2 गुना शक्तिशाली)
    server server1 10.0.1.10:8080 check weight 1 maxconn 500
    server server2 10.0.1.11:8080 check weight 1 maxconn 500
    server server3 10.0.1.12:8080 check weight 2 maxconn 1000
    
    # बैकअप सर्वर (केवल तभी उपयोग किया जाता है जब मुख्य अनुपलब्ध हों)
    server backup1 10.0.2.10:8080 check backup

स्वास्थ्य जांच — विफलता सहनशीलता के लिए एक महत्वपूर्ण कार्य है। प्रॉक्सी नियमित रूप से प्रत्येक सर्वर की उपलब्धता की जांच करती है (आमतौर पर HTTP एंडपॉइंट /health या /ready के माध्यम से) और स्वचालित रूप से काम नहीं करने वाले सर्वरों को लोड बैलेंसिंग पूल से बाहर कर देती है। जब सर्वर पुनः चालू होता है और स्वास्थ्य जांचों का उत्तर देना शुरू करता है, तो यह स्वचालित रूप से पूल में वापस आ जाता है।

प्रॉक्सी के माध्यम से विफलता सहनशीलता की रणनीतियाँ:

  • सक्रिय स्वास्थ्य जांच — प्रॉक्सी सक्रिय रूप से सर्वरों की उपलब्धता की जांच करती है
  • निष्क्रिय स्वास्थ्य जांच — प्रॉक्सी वास्तविक अनुरोधों की निगरानी करती है और त्रुटियों के संचय पर सर्वरों को बाहर कर देती है
  • सर्किट ब्रेकर — समस्याग्रस्त सेवा को अस्थायी रूप से बंद करना ताकि कैस्केडिंग विफलताओं को रोका जा सके
  • ग्रेसफुल डिग्रेडेशन — विफलताओं पर सरल कार्यप्रणाली या कैश किए गए डेटा पर स्विच करना
  • बैकअप पर स्विच करना — स्वचालित रूप से बैकअप सर्वरों या क्षेत्रों पर स्विच करना
// Python: बाहरी सेवाओं के लिए प्रॉक्सी के लिए सर्किट ब्रेकर का कार्यान्वयन
from datetime import datetime, timedelta
from enum import Enum

class CircuitState(Enum):
    CLOSED = "closed"      # सामान्य कार्य
    OPEN = "open"          # सेवा अनुपलब्ध है, अनुरोधों को ब्लॉक किया गया है
    HALF_OPEN = "half_open"  # पुनर्प्राप्ति के बाद परीक्षण मोड

class CircuitBreaker:
    def __init__(self, failure_threshold=5, timeout=60, success_threshold=2):
        self.failure_threshold = failure_threshold  # खोलने से पहले त्रुटियाँ
        self.timeout = timeout  # पुनर्प्राप्ति के प्रयासों के लिए सेकंड
        self.success_threshold = success_threshold  # बंद करने के लिए सफलताएँ
        
        self.state = CircuitState.CLOSED
        self.failures = 0
        self.successes = 0
        self.last_failure_time = None
    
    def call(self, func, *args, **kwargs):
        if self.state == CircuitState.OPEN:
            if datetime.now() - self.last_failure_time > timedelta(seconds=self.timeout):
                self.state = CircuitState.HALF_OPEN
                print("Circuit breaker: HALF_OPEN में स्विच करना")
            else:
                raise Exception("Circuit breaker OPEN: सेवा अनुपलब्ध है")
        
        try:
            result = func(*args, **kwargs)
            self._on_success()
            return result
        except Exception as e:
            self._on_failure()
            raise e
    
    def _on_success(self):
        self.failures = 0
        if self.state == CircuitState.HALF_OPEN:
            self.successes += 1
            if self.successes >= self.success_threshold:
                self.state = CircuitState.CLOSED
                self.successes = 0
                print("Circuit breaker: पुनर्प्राप्ति, CLOSED में स्विच करना")
    
    def _on_failure(self):
        self.failures += 1
        self.last_failure_time = datetime.now()
        if self.failures >= self.failure_threshold:
            self.state = CircuitState.OPEN
            print(f"Circuit breaker OPEN: {self.failures} लगातार त्रुटियाँ")

# उपयोग
breaker = CircuitBreaker(failure_threshold=3, timeout=30)

def call_external_service():
    # प्रॉक्सी के माध्यम से बाहरी API के लिए अनुरोध करने का आपका कोड
    pass

try:
    result = breaker.call(call_external_service)
except Exception as e:
    # फॉलबैक लॉजिक: कैश, डिफ़ॉल्ट मान आदि।
    print(f"सेवा अनुपलब्ध है: {e}")

सेवाओं के बीच संचार की सुरक्षा

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

प्रॉक्सी के माध्यम से सुरक्षा के प्रमुख पहलू:

  • म्यूचुअल TLS (mTLS) — द्विदिश प्रमाणीकरण, जब ग्राहक और सर्वर दोनों एक-दूसरे के प्रमाणपत्रों की जांच करते हैं। सर्विस मेष स्वचालित रूप से सभी सेवाओं के बीच mTLS कॉन्फ़िगर करता है
  • TLS टर्मिनेशन — प्रॉक्सी HTTPS ट्रैफ़िक को सीमा पर डिक्रिप्ट करता है, इसकी जांच करता है और सेवाओं को सुरक्षित चैनल के माध्यम से भेजता है
  • JWT मान्यता — प्रॉक्सी स्तर पर पहुंच टोकनों की जांच, सेवा तक पहुंच पहुंचने से पहले
  • IP व्हाइटलिस्टिंग — केवल अनुमत IP पतों से सेवाओं तक पहुंच को सीमित करना
  • DDoS सुरक्षा — दर सीमित करना, कनेक्शन सीमाएँ, प्रॉक्सी स्तर पर SYN फ्लड से सुरक्षा
  • WAF (वेब एप्लिकेशन फ़ायरवॉल) — हानिकारक अनुरोधों की फ़िल्टरिंग, SQL इंजेक्शन, XSS से सुरक्षा
# SSL/TLS और सुरक्षा के साथ NGINX कॉन्फ़िगरेशन
server {
    listen 443 ssl http2;
    server_name api.internal.example.com;

    # SSL प्रमाणपत्र
    ssl_certificate /etc/nginx/certs/api.crt;
    ssl_certificate_key /etc/nginx/certs/api.key;
    
    # आधुनिक प्रोटोकॉल और सिफर
    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    
    # mTLS के लिए क्लाइंट प्रमाणपत्र
    ssl_client_certificate /etc/nginx/certs/ca.crt;
    ssl_verify_client on;
    
    # सुरक्षित हेडर
    add_header Strict-Transport-Security "max-age=31536000" always;
    add_header X-Frame-Options "DENY" always;
    add_header X-Content-Type-Options "nosniff" always;
    
    # दर सीमित करना
    limit_req_zone $binary_remote_addr zone=api:10m rate=100r/s;
    limit_req zone=api burst=200 nodelay;
    
    # कनेक्शन सीमित करना
    limit_conn_zone $binary_remote_addr zone=addr:10m;
    limit_conn addr 10;
    
    # IP व्हाइटलिस्टिंग
    allow 10.0.0.0/8;      # आंतरिक नेटवर्क
    allow 172.16.0.0/12;   # VPC
    deny all;
    
    location / {
        # JWT टोकन की जांच
        auth_jwt "Restricted API";
        auth_jwt_key_file /etc/nginx/jwt_key.json;
        
        proxy_pass http://backend_service;
        
        # क्लाइंट प्रमाणपत्र की जानकारी को प्रॉक्सी करना
        proxy_set_header X-Client-DN $ssl_client_s_dn;
        proxy_set_header X-Client-Verify $ssl_client_verify;
    }
}

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

प्रोडक्शन के लिए महत्वपूर्ण: सेवाओं के बीच आंतरिक संचार के लिए हमेशा mTLS का उपयोग करें, भले ही वे एक ही निजी नेटवर्क में हों। यह मैन-इन-द-मिडल प्रकार के हमलों से सुरक्षा करता है और सेवाओं के स्तर पर प्रमाणीकरण सुनिश्चित करता है, न कि केवल नेटवर्क स्तर पर।

प्रॉक्सी ट्रैफ़िक की निगरानी और लॉगिंग

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

प्रॉक्सी स्तर पर निगरानी के लिए प्रमुख मेट्रिक्स:

  • विलंबता (Latency) — प्रत्येक चरण पर अनुरोध के संसाधन का समय: प्रॉक्सी, सेवा, बाहरी API
  • प्रवाहित क्षमता (Throughput) — प्रति सेकंड अनुरोधों की संख्या, भेजे गए डेटा की मात्रा
  • त्रुटि दर (Error Rate) — त्रुटियों का प्रतिशत (4xx, 5xx), त्रुटियों के प्रकार, समस्याग्रस्त एंडपॉइंट्स
  • कनेक्शन मेट्रिक्स — सक्रिय कनेक्शनों की संख्या, कनेक्शन पूल का उपयोग
  • सर्किट ब्रेकर स्थिति — प्रत्येक सेवा के लिए सर्किट ब्रेकर्स की स्थिति
  • SSL/TLS मेट्रिक्स — प्रमाणपत्रों की स्थिति, प्रोटोकॉल के संस्करण, हैंडशेक त्रुटियाँ
# NGINX कॉन्फ़िगरेशन मेट्रिक्स को Prometheus में निर्यात करने के लिए
server {
    listen 9113;
    location /metrics {
        stub_status;
        access_log off;
        allow 10.0.0.0/8;  # केवल Prometheus सर्वर के लिए
        deny all;
    }
}

# संरचित लॉगिंग के लिए JSON प्रारूप में लॉगिंग
log_format json_combined escape=json
  '{'
    '"time_local":"$time_local",'
    '"remote_addr":"$remote_addr",'
    '"request":"$request",'
    '"status": "$status",'
    '"body_bytes_sent":"$body_bytes_sent",'
    '"request_time":"$request_time",'
    '"upstream_response_time":"$upstream_response_time",'
    '"upstream_addr":"$upstream_addr",'
    '"http_referrer":"$http_referer",'
    '"http_user_agent":"$http_user_agent",'
    '"http_x_forwarded_for":"$http_x_forwarded_for"'
  '}';

access_log /var/log/nginx/access.log json_combined;

वितरित ट्रेसिंग — प्रॉक्सी के माध्यम से निगरानी की सबसे शक्तिशाली क्षमताओं में से एक है। प्रत्येक अनुरोध को एक अद्वितीय ट्रेस ID प्राप्त होता है, जिसे प्रॉक्सी हेडर में जोड़ता है और सेवाओं की श्रृंखला में आगे बढ़ाता है। ट्रेसिंग सिस्टम (Jaeger, Zipkin) सभी प्रॉक्सी से जानकारी एकत्र करते हैं और सिस्टम के माध्यम से अनुरोध के पूर्ण मार्ग का निर्माण करते हैं, यह दिखाते हुए कि वह प्रत्येक सेवा में कितना समय बिता रहा है।

// Node.js: प्रॉक्सी मिडलवेयर में ट्रेसिंग जोड़ना
const express = require('express');
const { v4: uuidv4 } = require('uuid');
const axios = require('axios');

const app = express();

// ट्रेस ID जोड़ने के लिए मिडलवेयर
app.use((req, res, next) => {
  // हेडर से ट्रेस ID प्राप्त करें या नया बनाएं
  const traceId = req.headers['x-trace-id'] || uuidv4();
  const spanId = uuidv4();
  
  // आगे बढ़ाने के लिए हेडर में जोड़ें
  req.traceId = traceId;
  req.spanId = spanId;
  res.setHeader('x-trace-id', traceId);
  
  // संसाधन शुरू होने का लॉग करें
  const startTime = Date.now();
  
  res.on('finish', () => {
    const duration = Date.now() - startTime;
    
    // विश्लेषण के लिए संरचित लॉग
    console.log(JSON.stringify({
      timestamp: new Date().toISOString(),
      traceId: traceId,
      spanId: spanId,
      method: req.method,
      path: req.path,
      status: res.statusCode,
      duration: duration,
      userAgent: req.headers['user-agent'],
      ip: req.ip
    }));
  });
  
  next();
});

// प्रॉक्सी एंडपॉइंट ट्रेसिंग हेडर के साथ
app.all('/api/*', async (req, res) => {
  const targetService = determineTargetService(req.path);
  
  try {
    const response = await axios({
      method: req.method,
      url: `http://${targetService}${req.path}`,
      data: req.body,
      headers: {
        ...req.headers,
        'x-trace-id': req.traceId,
        'x-parent-span-id': req.spanId,
        'x-span-id': uuidv4()  // डाउनस्ट्रीम अनुरोध के लिए नया स्पैन
      }
    });
    
    res.status(response.status).json(response.data);
  } catch (error) {
    console.error(JSON.stringify({
      traceId: req.traceId,
      error: error.message,
      service: targetService
    }));
    res.status(500).json({ error: 'सेवा अनुपलब्ध है' });
  }
});

function determineTargetService(path) {
  if (path.startsWith('/api/users')) return 'user-service:8080';
  if (path.startsWith('/api/orders')) return 'order-service:8080';
  return 'default-service:8080';
}

app.listen(3000);

प्रॉक्सी पर आधारित मेट्रिक्स पर अलर्टिंग समस्याओं का त्वरित पता लगाने की अनुमति देती है। उदाहरण के लिए, आप अलर्ट सेट कर सकते हैं: विलंबता में अचानक वृद्धि (संभवतः एक सेवा खराब हो रही है), त्रुटि दर का एक निश्चित सीमा से अधिक होना (कोड या निर्भरताओं के साथ समस्याएँ), ट्रैफ़िक पैटर्न में परिवर्तन (संभव DDoS हमला या वायरस लोड)।

Python और Node.js पर कार्यान्वयन के उदाहरण

विभिन्न परिदृश्यों के लिए Python और Node.js में प्रॉक्सी को माइक्रोसर्विसेज में एकीकृत करने के व्यावहारिक उदाहरणों पर विचार करें: आंतरिक संचार, बाहरी API के साथ काम करना, लोड बैलेंसिंग।

Python: बाहरी API के लिए प्रॉक्सी के साथ सेवा

from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
import httpx
import asyncio
from typing import List, Optional
import logging

app = FastAPI()
logging.basicConfig(level=logging.INFO)
logger = logging.getLogger(__name__)

class ProxyConfig(BaseModel):
    url: str
    max_requests_per_minute: int = 60

class ProxyPool:
    def __init__(self, proxies: List[ProxyConfig]):
        self.proxies = proxies
        self.current_index = 0
        self.request_counts = {p.url: 0 for p in proxies}
        self.reset_time = asyncio.get_event_loop().time() + 60
    
    async def get_next_proxy(self) -> str:
        # हर मिनट काउंटर रीसेट करें
        current_time = asyncio.get_event_loop().time()
        if current_time >= self.reset_time:
            self.request_counts = {p.url: 0 for p in self.proxies}
            self.reset_time = current_time + 60
        
        # उपलब्ध अनुरोधों के साथ प्रॉक्सी खोजें
        for _ in range(len(self.proxies)):
            proxy = self.proxies[self.current_index]
            self.current_index = (self.current_index + 1) % len(self.proxies)
            
            if self.request_counts[proxy.url] < proxy.max_requests_per_minute:
                self.request_counts[proxy.url] += 1
                return proxy.url
        
        # सभी प्रॉक्सी सीमा से बाहर हो गई हैं
        raise HTTPException(status_code=429, detail="सभी प्रॉक्सी दर सीमित हैं")

# प्रॉक्सी पूल का प्रारंभ
proxy_pool = ProxyPool([
    ProxyConfig(url="http://user:pass@proxy1.example.com:8080", max_requests_per_minute=100),
    ProxyConfig(url="http://user:pass@proxy2.example.com:8080", max_requests_per_minute=100),
    ProxyConfig(url="http://user:pass@proxy3.example.com:8080", max_requests_per_minute=100)
])

class ExternalAPIClient:
    def __init__(self, proxy_pool: ProxyPool):
        self.proxy_pool = proxy_pool
    
    async def fetch_data(self, endpoint: str, params: dict = None) -> dict:
        proxy_url = await self.proxy_pool.get_next_proxy()
        
        async with httpx.AsyncClient(proxies={"http://": proxy_url, "https://": proxy_url}) as client:
            try:
                response = await client.get(
                    endpoint,
                    params=params,
                    timeout=10.0,
                    headers={"User-Agent": "MyMicroservice/1.0"}
                )
                response.raise_for_status()
                
                logger.info(f"{proxy_url} के माध्यम से {endpoint} से सफलतापूर्वक प्राप्त किया");
                return response.json()
            
            except httpx.HTTPStatusError as e:
                logger.error(f"{endpoint} से HTTP त्रुटि {e.response.status_code}");
                raise HTTPException(status_code=e.response.status_code, detail=str(e))
            
            except httpx.RequestError as e:
                logger.error(f"{endpoint} के लिए अनुरोध त्रुटि: {e}");
                raise HTTPException(status_code=503, detail="बाहरी API अनुपलब्ध है");

api_client = ExternalAPIClient(proxy_pool)

@app.get("/data/{resource_id}")
async def get_external_data(resource_id: str):
    """एंडपॉइंट, जो प्रॉक्सी के माध्यम से बाहरी API से डेटा प्राप्त करता है"""
    external_endpoint = f"https://api.external-service.com/v1/resources/{resource_id}"
    
    try:
        data = await api_client.fetch_data(external_endpoint)
        return {"status": "success", "data": data}
    except HTTPException:
        raise
    except Exception as e:
        logger.error(f"अप्रत्याशित त्रुटि: {e}");
        raise HTTPException(status_code=500, detail="आंतरिक सर्वर त्रुटि");

@app.get("/health")
async def health_check():
    return {"status": "healthy", "service": "external-api-proxy"}

# प्रारंभ: uvicorn main:app --host 0.0.0.0 --port 8000

Node.js: लोड बैलेंसिंग के साथ API गेटवे

const express = require('express');
const axios = require('axios');
const rateLimit = require('express-rate-limit');

const app = express();
app.use(express.json());

// माइक्रोसर्विसेज की कॉन्फ़िगरेशन
const services = {
  users: [
    { url: 'http://user-service-1:8001', healthy: true, activeConnections: 0 },
    { url: 'http://user-service-2:8001', healthy: true, activeConnections: 0 },
    ...
  ],
  orders: [
    { url: 'http://order-service-1:8002', healthy: true, activeConnections: 0 },
    { url: 'http://order-service-2:8002', healthy: true, activeConnections: 0 },
    ...
  ]
};

// लोड बैलेंसिंग और रूटिंग लॉजिक
app.use('/api/users', (req, res) => {
  const service = getAvailableService(services.users);
  if (service) {
    axios({
      method: req.method,
      url: `${service.url}${req.path}`,
      data: req.body,
      headers: req.headers
    })
    .then(response => res.status(response.status).json(response.data))
    .catch(error => res.status(500).json({ error: 'सेवा अनुपलब्ध है' }));
  } else {
    res.status(503).json({ error: 'सभी सेवाएँ अनुपलब्ध हैं' });
  }
});

// सेवा उपलब्धता की जांच करने के लिए सहायक कार्य
function getAvailableService(serviceList) {
  return serviceList.find(service => service.healthy);
}

app.listen(3000, () => {
  console.log('API गेटवे 3000 पोर्ट पर सुन रहा है');
});
```