एक सेवा मेश (Istio, Linkerd) क्रॉस-कटिंग नेटवर्किंग समस्या — रिट्राई, टाइमआउट, mTLS, ट्रॅफिक रूटिंग, निरीक्षणीयता — अनुप्रयोग कोडच्या बाहेर आणि साइडकार प्रॉक्सीज च्या नेटवर्क इन्फ्रास्ट्रक्चर लेयरमध्ये हलवते।
प्रत्येक सेवा उदाहरण (उदा., Envoy) च्या बाजूला चालते। सर्व ट्रॅफिक प्रॉक्सीजमधून वाहते, जे तयार करते; एक त्यांना कॉन्फिगर करते।
┌─────────────────┐ ┌─────────────────┐
│ Service A │ │ Service B │
│ app ⇄ [proxy] │◀──────▶│ [proxy] ⇄ app │
└─────────────────┘ mTLS └─────────────────┘
▲ configured by ▲
└──── Control Plane (Istio/Linkerd) ────┘
# shift 10% of traffic to v2 (canary), no code change
route:
- destination: { host: orders, subset: v1 }
weight: 90
- destination: { host: orders, subset: v2 }
weight: 10
एक मेश विलंबता (अतिरिक्त हॉप्स), संसाधन ओव्हरहेड (प्रति पॉड एक प्रॉक्सी), आणि वास्तविक ऑपरेशनल जटिलता जोडते।
मेश सर्व सेवांमध्ये लचकदारपणा, सुरक्षा आणि निरीक्षणीयता मानकीकृत करते, प्रत्येक टीमला विविध भाषांमध्ये त्यांची पुनरावृत्ती करावी लागत नाही।
परंतु हे भारी आहे: केवळ तेव्हाच त्याचा स्वीकार करा जेव्हा तुमच्याकडे इतक्या सेवा असतील की डुप्लिकेट नेटवर्किंग लॉजिक मेशच्या ऑपरेशनल खर्चापेक्षा जास्त असेल।