Canary deployments Java के साथ: बिना डर के सुरक्षित डिप्लॉय

शुरुआती लोगों के लिए ऑनलाइन Python प्रशिक्षक

Python आसानी से सीखें बिना सिद्धांत के बोझ के। स्वचालित जांच के साथ व्यावहारिक कार्य हल करें और ब्राउज़र में सीधे कोड लिखें।

पाठ्यक्रम शुरू करें

Canary deployments Java के साथ: प्रोडक्शन के लिए जोखिम के बिना नए वर्ज़न कैसे जारी करें

\n\n

कल्पना करें: आप एक पनडुब्बी के कप्तान हैं। आपको एक नया सोनार जांचना है, लेकिन आप इसे पूरी शक्ति से चालू नहीं कर सकते — हो सकता है कि यह पूरे दल को अंधा कर दे या, इससे भी बुरा, झूठा अलार्म दे। आप क्या करते हैं? आप एक कैनरी (एक पक्षी जो पुराने समय में खनिकों को गैस रिसाव के बारे में चेतावनी देता था) छोड़ते हैं। यदि पक्षी जीवित है — तो सिस्टम ठीक है।

\n\n

Java डेवलपमेंट की दुनिया में, इस सिद्धांत को canary deployments (कैनरी डिप्लॉयमेंट) कहा जाता है। यह एक रणनीति है जिसमें एप्लिकेशन का नया वर्ज़न पहले उपयोगकर्ताओं के एक छोटे प्रतिशत (आमतौर पर 1–5%) को भेजा जाता है। यदि सब कुछ ठीक है — तो ट्रैफ़िक धीरे-धीरे बढ़ाया जाता है। यदि नहीं — तो बिना किसी आपदा के वापस लौट जाते हैं।

\n\n

इस लेख में, हम वास्तविक उदाहरणों के साथ Java में canary deployments को लागू करने का तरीका समझेंगे: सरल कॉन्फ़िगरेशन से लेकर Kubernetes और Spring Cloud के साथ उन्नत तकनीकों तक। चलिए शुरू करते हैं!

\n\n

Canary ही क्यों, blue-green या rolling update क्यों नहीं?

\n\n

आइए तीन लोकप्रिय डिप्लॉय रणनीतियों की तुरंत तुलना करें:

\n\n
    \n
  • Blue-Green: आपके पास दो समान वातावरण हैं (नीला और हरा)। आप सारा ट्रैफ़िक एक साथ स्विच करते हैं। तेज़, लेकिन अगर कोई बग निकलता है — तो सभी प्रभावित होंगे।
  • \n
  • Rolling update: आप पॉड्स/सर्वर को एक-एक करके अपडेट करते हैं। धीमा, लेकिन फिर भी बड़े पैमाने पर।
  • \n
  • Canary: आप नया वर्ज़न केवल 2% उपयोगकर्ताओं पर छोड़ते हैं। यदि वे शिकायत नहीं करते — तो 10%, फिर 50%, फिर 100% तक बढ़ाते हैं।
  • \n
\n\n

Canary एकमात्र ऐसी रणनीति है जो आपको सभी के लिए जोखिम के बिना वास्तविक उपयोगकर्ताओं पर नए वर्ज़न का A/B परीक्षण करने की अनुमति देती है। यह विशेष रूप से Java माइक्रोसर्विसेज के लिए महत्वपूर्ण है, जहाँ एक गलती कैस्केडिंग विफलता का कारण बन सकती है।

\n\n

Java में यह कैसे काम करता है? तकनीकी आर्किटेक्चर

\n\n

एक सामान्य Java सिस्टम की कल्पना करें: एक Spring Boot एप्लिकेशन जो REST API प्रदान करता है। Canary लागू करने के लिए, हमें चाहिए:

\n\n
    \n
  1. ट्रैफ़िक रूटिंग: कुछ अनुरोधों को नए वर्ज़न (v2) पर भेजना, बाकी को पुराने (v1) पर।
  2. \n
  3. मेट्रिक्स और मॉनिटरिंग: त्रुटियाँ, विलंबता, अनुरोधों की संख्या एकत्र करना।
  4. \n
  5. स्वचालित रोलबैक: यदि त्रुटि प्रतिशत सीमा से अधिक हो जाता है — तो canary वापस ले लें।
  6. \n
  7. क्रमिक वृद्धि: यदि सब ठीक है — तो canary का भार बढ़ाएँ।
  8. \n
\n\n

ऐसा करने का सबसे सरल तरीका Kubernetes का उपयोग Service Mesh (जैसे Istio) या रूटिंग भार के साथ Spring Cloud Gateway के साथ करना है। नीचे दोनों दृष्टिकोणों के उदाहरण दिए गए हैं।

\n\n

उदाहरण 1: Spring Cloud Gateway के साथ Canary (Kubernetes के बिना)

\n\n

यदि आपके पास Kubernetes नहीं है, लेकिन Spring Cloud है, तो आप भार कॉन्फ़िगरेशन के साथ Spring Cloud Gateway का उपयोग कर सकते हैं। यह इस प्रकार दिखता है:

\n\n
// application.yml\nspring:\n  cloud:\n    gateway:\n      routes:\n        - id: my-app-canary\n          uri: http://my-app-v2:8080\n          predicates:\n            - Weight=my-app, 10   # 10% ट्रैफ़िक\n          filters:\n            - SetPath=/api/v2/**\n        - id: my-app-stable\n          uri: http://my-app-v1:8080\n          predicates:\n            - Weight=my-app, 90   # 90% ट्रैफ़िक\n          filters:\n            - SetPath=/api/v1/**\n
\n\n

यहाँ हम Weight प्रेडिकेट का उपयोग करते हैं — Spring Cloud Gateway की एक अंतर्निहित सुविधा। यह यादृच्छिक रूप से अनुरोधों को 10/90 के अनुपात में वितरित करता है। यदि v2 स्थिर रूप से काम करता है, तो हम भार को 50/50, फिर 100/0 में बदल देते हैं।

\n\n

लाभ: सरल, बाहरी उपकरणों की आवश्यकता नहीं है।
\nनुकसान: कोई स्वचालन नहीं — भार मैन्युअल रूप से या API के माध्यम से बदले जाते हैं।

\n\n

उदाहरण 2: Kubernetes और Istio के साथ Canary (उन्नत)

\n\n

यह Java माइक्रोसर्विसेज के लिए स्वर्ण मानक है। हम Istio VirtualService

ब्लॉग

पुस्तक अनुशंसाएँ