साइडकार पैटर्न: कोड को संशोधित किए बिना माइक्रोसर्विसेज का विस्तार

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

यदि हम इस सभी क्रॉस-कटिंग कार्यक्षमता को सीधे प्रत्येक एप्लिकेशन के कोडबेस के अंदर एम्बेड करते हैं, तो हम कोड ब्लोट, टाइट कपलिंग और भाषा लॉक-इन के साथ समाप्त होते हैं।

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

वास्तविक दुनिया सादृश्य: मोटरसाइकिल साइडकार

इस पैटर्न को समझने का सबसे आसान तरीका साइडकार वाली मोटरसाइकिल के बारे में सोचना है।

कल्पना कीजिए कि आपके पास एक उच्च प्रदर्शन वाली मोटरसाइकिल है। इसे एक काम असाधारण रूप से अच्छी तरह से करने के लिए डिज़ाइन किया गया है: एक सवार को शीघ्रता से परिवहन करना। अब, मान लीजिए कि आपको यात्री का सामान ले जाना है या एक अतिरिक्त सीट जोड़नी है।

आप मोटरसाइकिल को एक कार में बदलने के लिए उसके फ्रेम, इंजन और पहियों को पूरी तरह से नया डिज़ाइन कर सकते हैं। हालाँकि, इसके लिए बड़े पैमाने पर प्रयास की आवश्यकता होती है, यह बाइक की सादगी को बर्बाद कर देता है, और इसे बनाए रखना कठिन हो जाता है।

इसके बजाय, आप एक साइडकार संलग्न करें।

साइडकार एक अलग, स्व-निहित इकाई है जो मोटरसाइकिल से जुड़ती है। यह मोटरसाइकिल की यात्रा को साझा करता है, जहां भी बाइक जाती है वहां जाता है, और एक साथ मिलकर काम करता है। फिर भी, मोटरसाइकिल का मुख्य इंजन अछूता रहता है।

सॉफ्टवेयर आर्किटेक्चर में:

• मोटरसाइकिल आपका प्राथमिक एप्लिकेशन कंटेनर है (आपके मुख्य व्यवसाय तर्क को चलाना, जैसे चेकआउट या उपयोगकर्ता प्रमाणीकरण)।
• साइडकार एक अलग सहायक कंटेनर है (एसएसएल समाप्ति, निगरानी, ​​​​या लॉग शिपिंग जैसे उपयोगिता कार्य चलाना)।
• यात्रा परिनियोजन का जीवनचक्र है (उदाहरण के लिए, कुबेरनेट्स पॉड)।

समस्या: क्रॉस-कटिंग चिंताएं और कोड ब्लोट

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

इस पुस्तकालय-आधारित दृष्टिकोण ने कई महत्वपूर्ण चुनौतियाँ पैदा कीं:

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

समाधान: साइडकार पैटर्न

साइडकार पैटर्न सहायक कार्यों को मुख्य एप्लिकेशन प्रक्रिया से बाहर ले जाकर और उन्हें एप्लिकेशन के ठीक बगल में चलने वाली एक अलग, स्वतंत्र प्रक्रिया में रखकर इन समस्याओं का समाधान करता है।

कुबेरनेट्स जैसे कंटेनरीकृत वातावरण में, एप्लिकेशन कंटेनर और साइडकार कंटेनर एक ही पॉड के अंदर चलते हैं। क्योंकि वे एक ही पॉड साझा करते हैं:

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

साइडकार पैटर्न के प्रमुख उपयोग के मामले

साइडकार अविश्वसनीय रूप से बहुमुखी हैं। कुछ सबसे आम अनुप्रयोगों में शामिल हैं:

1. सर्विस मेश प्रॉक्सीइंग (जैसे, दूत, लिंकरड)

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

2. लॉग संग्रह और अग्रेषण (उदाहरण के लिए, फ़्लुएंट बिट)

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

3. कॉन्फ़िगरेशन और गुप्त पुनः लोडिंग

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

कुबेरनेट्स कार्यान्वयन उदाहरण

कुबेरनेट्स में साइडकार स्थापित करना सीधा है। यहां एक सरल YAML कॉन्फ़िगरेशन है जो एक साझा वॉल्यूम पर एक एप्लिकेशन कंटेनर लेखन लॉग दिखा रहा है, और एक फ्लुएंट बिट साइडकार कंटेनर उन लॉग को पढ़ रहा है और शिपिंग कर रहा है:

apiVersion: v1
kind: Pod
metadata:
  name: app-with-logging-sidecar
  labels:
    app: billing-service
spec:
  containers:
    # 1. Primary Application Container
    - name: web-app
      image: node:18-alpine
      command: ["/bin/sh", "-c"]
      args:
        - >
          while true; do
            echo "$(date) [INFO] Transaction processed successfully" >> /var/log/app/output.log;
            sleep 5;
          done
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/app

    # 2. Sidecar Container (Log Shipper)
    - name: log-shipper
      image: fluent/fluent-bit:latest
      volumeMounts:
        - name: shared-logs
          mountPath: /var/log/app
      # In a real setup, Fluent Bit config would read /var/log/app/output.log
      # and forward it to an external logging system.

  # Shared disk storage accessible by both containers
  volumes:
    - name: shared-logs
      emptyDir: {}

साइडकार पैटर्न के फायदे और नुकसान

किसी भी डिज़ाइन पैटर्न की तरह, साइडकार ट्रेड-ऑफ़ के साथ आते हैं:

निष्कर्ष

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

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

ग़ज़निक्स ब्लॉग पर अधिक सॉफ़्टवेयर विकास और बैकएंड इंजीनियरिंग अंतर्दृष्टि का अन्वेषण करें →