Service Mesh और PHP: माइक्रोसर्विसेज़ को स्मार्ट बनाएं

आपके PHP माइक्रोसर्विसेज़ फुसफुसा रहे हैं? अब ज़ोर से बोलने का समय आ गया है

कल्पना करें: आपके पास 15 PHP माइक्रोसर्विसेज़ हैं। एक ऑथराइज़ेशन के लिए, दूसरा पेमेंट के लिए, तीसरा नोटिफिकेशन के लिए। ये HTTP पर बात करते हैं, लेकिन हर हफ्ते कुछ न कुछ टूट जाता है: टाइमआउट, क्रैश, खोए हुए रिक्वेस्ट। आप रिट्राई, circuit breaker, बैलेंसिंग जोड़ते हैं — और कोड नेटवर्क कम्युनिकेशन की स्पेगेटी में बदल जाता है।

यहाँ आता है Service Mesh — एक इंफ्रास्ट्रक्चर लेयर जो आपके PHP कोड से सारी नेटवर्क मैजिक को बाहर निकाल देता है। डरें नहीं: यह कोई जादू नहीं, बल्कि एक सोची-समझी आर्किटेक्चर है। और हाँ, PHP माइक्रोसर्विसेज़ Service Mesh का उपयोग कर सकते हैं (और करना चाहिए)।

Service Mesh क्या है और PHP डेवलपर को इसकी आवश्यकता क्यों है?

Service Mesh एक समर्पित इंफ्रास्ट्रक्चर लेयर है जो इंटर-सर्विस कम्युनिकेशन को मैनेज करता है। हर माइक्रोसर्विस में बैलेंसिंग, एन्क्रिप्शन, ट्रेसिंग और टाइमआउट का लॉजिक लिखने के बजाय, आप यह काम sidecar-proxy (आमतौर पर Envoy या Linkerd) को सौंप देते हैं।

PHP के लिए यह विशेष रूप से महत्वपूर्ण है, क्योंकि:

\n
• PHP ऐप्स अक्सर FastCGI या FPM के ज़रिए चलते हैं, और हर सर्विस में नेटवर्क लॉजिक जोड़ना एक overhead है
\n
• Service Mesh बिना कोड बदले mTLS (आपसी प्रमाणीकरण) देता है
• आपको सभी माइक्रोसर्विसेज़ की निगरानी के लिए एक ही डैशबोर्ड मिलता है
• आप प्रॉक्सी लेवल पर ही circuit breaker और retry लागू कर सकते हैं

सबसे लोकप्रिय स्टैक है — Istio + Envoy। लेकिन हम इसे PHP डेवलपर के नज़रिए से देखेंगे।

यह कैसे काम करता है: PHP सर्विस + sidecar

मान लीजिए, आपके पास PHP पर एक माइक्रोसर्विस user-service है। यह पोर्ट 9000 (FPM) पर सुनता है। Service Mesh के बिना, आप सीधे इस तक पहुँचते हैं:

GET http://user-service:9000/api/users/1

Service Mesh के साथ, आपके pod (कंटेनर) में एक Envoy-proxy जुड़ जाता है। अब सारा आने-जाने वाला ट्रैफ़िक इसके ज़रिए गुज़रता है:

┌─────────────────┐       ┌──────────────┐\n│ PHP-एप्लीकेशन   │ ──►   │ Envoy Proxy  │\n│ (user-service)   │       │ (sidecar)    │\n└─────────────────┘       └──────┬───────┘\n                                  │\n                                  ▼\n                          ┌──────────────┐\n                          │ Envoy Proxy  │\n                          │ (दूसरी सर्विस)│\n                          └──────────────┘

आपका PHP कोड प्रॉक्सी के बारे में नहीं जानता। वह बस localhost:80 या localhost:9000 पर रिक्वेस्ट भेजता है — Envoy उन्हें इंटरसेप्ट करके Istio के नियमों के अनुसार रूट करता है।

व्यावहारिक उदाहरण: Istio पर Service Mesh के साथ PHP माइक्रोसर्विस

चरण 1. PHP सर्विस सेटअप (कोड में कोई बदलाव नहीं)

मान लीजिए, आपके पास एक सरल PHP स्क्रिप्ट है जो उपयोगकर्ता का डेटा लौटाती है:

<?php\n// user-service/index.php\n$userId = $_GET['id'] ?? 0;\n$users = [\n    1 => ['name' => 'राहुल', 'email' => 'rahul@example.com'],\n    2 => ['name' => 'प्रिया', 'email' => 'priya@example.com'],\n];\n\nheader('Content-Type: application/json');\necho json_encode($users[$userId] ?? ['error' => 'उपयोगकर्ता नहीं मिला']);

इसे Docker में लपेटें:

# Dockerfile\nFROM php:8.2-fpm\nCOPY index.php /var/www/html/index.php\nCMD ["php-fpm"]

सब कुछ स्टैंडर्ड है। Service Mesh के लिए कोई बदलाव नहीं।

चरण 2. Kubernetes में sidecar के साथ डिप्लॉयमेंट

एनोटेशन sidecar.istio.io/inject: "true" जोड़ें — Istio अपने आप Envoy डाल देगा:

apiVersion: apps/v1\nkind: Deployment\nmetadata:\n  name: user-service\nspec:\n  replicas: 2\n  selector:\n    matchLabels:\n      app: user-service\n  template:\n    metadata:\n      labels:\n        app: user-service\n      annotations:\n        sidecar.istio.io/inject: "true"  # <-- मुख्य लाइन\n    spec:\n      containers:\n      - name: php\n