जब माइक्रोसर्विसेज सिरदर्द बन जाती हैं
\nकल्पना करें: आपने सफलतापूर्वक एक मोनोलिथ को Node.js पर एक दर्जन माइक्रोसर्विसेज में विभाजित कर दिया है। प्रत्येक सर्विस अपने कार्य के लिए जिम्मेदार है — प्रमाणीकरण, उत्पाद सूची, कार्ट, भुगतान। सब कुछ तब तक बढ़िया है जब तक असली मज़ा शुरू नहीं होता: सर्विसेज क्रैश होती हैं, अनुरोध खो जाते हैं, टाइमआउट बढ़ जाते हैं, और लॉग पाँच अलग-अलग डैशबोर्ड पर बिखरे होते हैं। परिचित लगता है?
\nआपने axios के माध्यम से सरल HTTP अनुरोधों से शुरुआत की थी, लेकिन अब प्रत्येक सर्विस को अन्य सभी सर्विसेज के पतों को जानना होगा, रिट्राइज़, circuit breakers और लोड बैलेंसिंग को संभालना होगा। कोड इन्फ्रास्ट्रक्चर लॉजिक की स्पेगेटी में बदल जाता है। यहीं पर Service Mesh आता है — एक आर्किटेक्चरल पैटर्न जो सभी नेटवर्क जादू को आपके जावास्क्रिप्ट कोड के बाहर ले जाता है।
इस लेख में, हम समझेंगे कि जावास्क्रिप्ट और Node.js के संदर्भ में Service Mesh कैसे काम करता है, लोकप्रिय समाधानों (Envoy, Istio, Linkerd) के साथ वास्तविक एकीकरण कोड लिखेंगे, और समझेंगे कि यह जटिलता कब उचित है। चलिए शुरू करते हैं!
\n\nService Mesh क्या है और जावास्क्रिप्ट डेवलपर को इसकी आवश्यकता क्यों है
\nService Mesh माइक्रोसर्विसेज के बीच संचार के लिए एक समर्पित इन्फ्रास्ट्रक्चर लेयर है। प्रत्येक जावास्क्रिप्ट सर्विस में सर्विस डिस्कवरी, लोड बैलेंसिंग, एन्क्रिप्शन और मॉनिटरिंग लॉजिक को एम्बेड करने के बजाय, हम इसे एक "sidecar"-प्रॉक्सी में डालते हैं, जो आपके एप्लिकेशन के प्रत्येक इंस्टेंस के साथ चलता है।
\nNode.js डेवलपर के लिए इसका मतलब है:
\n- \n
- स्वच्छ बिज़नेस लॉजिक कोड — आप केवल Express/Koa/Fastify हैंडलर लिखते हैं, सारा नेटवर्क जादू छिपा रहता है। \n
- स्वचालित लोड बैलेंसिंग — अनुरोध बिना किसी अतिरिक्त लाइब्रेरी के इंस्टेंसेज के बीच वितरित होते हैं। \n
- बॉक्स से बाहर विश्वसनीयता — retries, timeouts, circuit breakers को घोषणात्मक रूप से कॉन्फ़िगर किया जाता है। \n
- Observability — ट्रेसिंग, मेट्रिक्स और लॉग स्वचालित रूप से एकत्र किए जाते हैं। \n
सबसे अच्छी बात: आप भाषा से बंधे नहीं हैं। Service Mesh नेटवर्क स्तर पर काम करता है, इसलिए आपकी जावास्क्रिप्ट सर्विस Go सर्विस, Python सर्विस या लीगेसी Java मोनोलिथ से संवाद कर सकती है — प्रॉक्सी सब कुछ पारदर्शी रूप से करेगा।
\n\nService Mesh आर्किटेक्चर: sidecar कंटेनर और कंट्रोल प्लेन
\nक्लासिक Service Mesh दो भागों से बना होता है:
\nData Plane (डेटा प्लेन)
\nआपकी प्रत्येक माइक्रोसर्विस (उदाहरण के लिए, पोर्ट 3000 पर Node.js एप्लिकेशन) एक sidecar-प्रॉक्सी (आमतौर पर Envoy या Linkerd-proxy) के साथ चलती है। सभी आने वाले और जाने वाले अनुरोध इस प्रॉक्सी से होकर गुजरते हैं:
\n// sidecar के माध्यम से रूटिंग का उदाहरण\n// आपकी सर्विस localhost:3000 पर सुनती है\n// Sidecar localhost:8080 पर सुनता है और ट्रैफ़िक को रीडायरेक्ट करता है\n\n// प्रोडक्शन में, आप कभी भी सीधे किसी अन्य सर्विस तक नहीं पहुँचते\n// इसके बजाय, आप localhost:8080/service-name पर अनुरोध भेजते हैं\n\nconst axios = require('axios');\n\n// Service Mesh के बिना (खराब)\n// const userService = 'http://user-service:4000';\n\n// Service Mesh के साथ (अच्छा) - sidecar तक पहुँचें\nconst userService = 'http://localhost:8080'; \n\nasync function getUser(id) {\n const response = await axios.get(`${userService}/users/${id}`);\n return response.data;\n}\nप्रॉक्सी स्वचालित रूप से user-service का सही इंस्टेंस ढूंढता है, लोड को संतुलित करता है और सुरक्षा नीतियों को लागू करता है।
\n\nControl Plane (कंट्रोल प्लेन)
\nयह सिस्टम का "दिमाग" है। उदाहरण के लिए, Istio कॉन्फ़िगरेशन प्रबंधन, टेलीमेट्री संग्रह और प्रमाणपत्र जारी करने के लिए Pilot, Mixer और Citadel घटकों का उपयोग करता है। आप YAML में रूटिंग नियमों का वर्णन करते हैं, और Control Plane उन्हें सभी sidecar-प्रॉक्सी में प्रसारित करता है।
\n\nव्यावहारिक उदाहरण: Node.js + Envoy + Istio
\nआइए एक वास्तविक कॉन्फ़िगरेशन बनाएं। हमारे पास Express पर दो माइक्रोसर्विसेज होंगी: order-service और payment-service। एक-दूसरे के URL को हार्डकोड करने के बजाय, हम Service Mesh का उपयोग करेंगे।