सर्विस मेश और Kotlin माइक्रोसर्विसेज: अराजकता से व्यवस्था की ओर

क्या आपके Kotlin माइक्रोसर्विसेज सिर्फ माइक्रोसर्विसेज नहीं रह गए हैं?

यदि आपने कभी production में दस Kotlin-सर्विसेज का सिस्टम चलाया है, तो आप इस पल को जानते हैं। पहले सब कुछ बढ़िया होता है: ktor चलता है, spring-webflux उड़ता है, डेटाबेस तुरंत जवाब देता है। लेकिन एक महीना बीतता है, और परिचित दुनिया ढह जाती है। ट्रैफ़िक घूमने लगता है, retries बढ़ जाती हैं, टाइम-आउट वहाँ दिखने लगते हैं जहाँ उन्हें नहीं होना चाहिए, और लॉग लाखों पंक्तियों की गड़बड़ी में बदल जाते हैं।

इस पल में आप service mesh की तलाश शुरू करते हैं। और यह सही रास्ता है। आइए समझते हैं कि यह तकनीक कैसे अराजकता को व्यवस्था में बदलती है, और इसे Kotlin की दुनिया में सही तरीके से कैसे लागू किया जाए।

service mesh क्या है और Kotlin-डेवलपर को इसकी आवश्यकता क्यों है?

Service mesh (सर्विस नेटवर्क) इंटर-सर्विस संचार के प्रबंधन के लिए एक समर्पित इंफ्रास्ट्रक्चर लेयर है। यह सारा "गंदा काम" अपने ऊपर ले लेता है: रूटिंग, बैलेंसिंग, एन्क्रिप्शन, observability और circuit breaking। और यह आपके Kotlin-एप्लिकेशन के कोड को बदले बिना करता है।

यह Kotlin के लिए क्यों महत्वपूर्ण है? Kotlin-माइक्रोसर्विसेज अक्सर Ktor या Spring Boot जैसे फ्रेमवर्क पर लिखी जाती हैं। दोनों बिज़नेस लॉजिक को अच्छी तरह से संभालते हैं, लेकिन जब वे 20+ हो जाती हैं, तो प्रत्येक सर्विस अपने ऊपर बहुत सारा दोहराव वाला कोड ले जाने लगती है: मेट्रिक्स, ट्रेसिंग, mTLS, retry-मैकेनिज्म। Service mesh यह सब इंफ्रास्ट्रक्चर लेयर पर ले जाता है।

कल्पना करें: आप Ktor पर एक सरल REST-एंडपॉइंट लिखते हैं, और service mesh स्वचालित रूप से इसमें एन्क्रिप्शन, ट्रेसिंग और बैलेंसिंग जोड़ता है। सुंदरता, है ना?

service mesh के मुख्य घटक

कोई भी सर्विस नेटवर्क दो प्रमुख घटकों पर बनता है:

\n
• Control plane (नियंत्रण तल) — सिस्टम का "दिमाग"। कॉन्फ़िगरेशन एकत्र करता है, रूटिंग नियमों, सुरक्षा नीतियों का प्रबंधन करता है। Istio में यह istiod है, Linkerd में — linkerd-controller।
\n
• Data plane (डेटा तल) — "मांसपेशियाँ"। sidecar-प्रॉक्सी (आमतौर पर Envoy) का सेट, जो आपकी प्रत्येक Kotlin-सर्विस के साथ रहता है और सभी आने/जाने वाले ट्रैफ़िक को इंटरसेप्ट करता है।
\n

जब Kotlin-सर्विस A, सर्विस B को कॉल करना चाहती है, तो उसका अनुरोध पहले sidecar-प्रॉक्सी में जाता है। प्रॉक्सी नियमों की जाँच करता है, mTLS लागू करता है, लोड बैलेंस करता है, ट्रेसिंग के लिए हेडर जोड़ता है — और उसके बाद ही अनुरोध को आगे भेजता है। आपका कोड इसके बारे में कुछ नहीं जानता।

अभ्यास: Kotlin-माइक्रोसर्विस के लिए service mesh सेट करना

आइए Ktor पर एक सरल Kotlin-सर्विस लिखें और देखें कि service mesh इसके व्यवहार को कैसे बदलता है।

चरण 1. Kotlin में एप्लिकेशन लिखना

// build.gradle.kts\ndependencies {\n    implementation("io.ktor:ktor-server-netty:2.3.7")\n    implementation("io.ktor:ktor-server-content-negotiation:2.3.7")\n    implementation("io.ktor:ktor-serialization-kotlinx-json:2.3.7")\n    implementation("ch.qos.logback:logback-classic:1.4.14")\n}\n\n// Application.kt\npackage com.example\n\nimport io.ktor.server.engine.*\nimport io.ktor.server.netty.*\nimport io.ktor.server.routing.*\nimport io.ktor.server.response.*\nimport io.ktor.serialization.kotlinx.json.*\nimport io.ktor.server.plugins.contentnegotiation.*\n\nfun main() {\n    embeddedServer(Netty, port = 8080) {\n        install(ContentNegotiation) {\n            json()\n        }\n        routing {\n            get("/health") {\n                call.respond(mapOf("status" to "UP", "service" to "payment"))\n            }\n            get("/api/payments/{id}") {\n                val id = call.parameters["id"] ?: "unknown"\n                call.respond(mapOf("paymentId" to id, "amount" to 150.00))\n            }\n        }\n    }.start(wait = true)\n}\n

यह सर्विस service mesh के बारे में कुछ नहीं जानती। यह सिर्फ अनुरोधों का जवाब देती है। लेकिन जैसे ही हम इसे Istio के साथ Kubernetes क्लस्टर में डिप्लॉय करेंगे, सब कुछ बदल जाएगा।

चरण 2. डिप्लॉय करना