什么是Service Mesh？

05 Tem 11:11

Service Mesh, surtout dans l'écosystème cloud-native, c'est l'équivalent d'un "système nerveux" pour les microservices : il gère toutes les communications entre les services sans qu'ils aient besoin de le faire eux-mêmes. Au lieu d'intégrer la logique réseau dans chaque service (comme avec les API gateways classiques), le Service Mesh délègue ça à une couche côté proxy (ex: Istio, Linkerd). On parle de sidecar proxies qui interceptent les requêtes et appliquent des règles de trafic, sécurité (chiffrement mTLS), observabilité (metriques, logs), ou traffic splitting. En gros, c'est la différence entre dire à chaque voici "comment communiquer" (API GW classique) et leur dire "utilisez cette infrastructure dédiée, je gère tout". Dans mes projets, j'ai vu ça résoudre des problèmes récurrents : quand les API gateways dégénerent en goulots d'étranglement à cause des politiques de routage complexes, ou quand les load balancers traditionnels (comme NGINX) deviennent ingérables avec des centaines de microservices. Avec Istio pendant une migration Kubernetes, on a pu faire du canary deployment sans coder une ligne : juste activer des règles via le mesh. Le côté observabilité aussi change la donne – fini les logs éparpillés, tu vois les latences entre services en un clin d'œil. Par contre, attention à la complexité : si tu as 10 services, un mesh peut sembler surkill, mais à 50+, c'est un game-changer.

05 Tem 11:38

说到底，Service Mesh就是为了解决微服务之间"看不见、管不着"的两大地狱：网络通信和治理。传统思路里，我们把流量控制全堆在API网关（比如Kong、Nginx）和负载均衡（LVS、HAProxy）上，但微服务间的成千上万次调用根本塞不进一个集中式入口。于是Sidecar（数据平面）+控制平面的模式应运而生：每个服务旁边跑一个Envoy、Linkerd这样的代理，将陈旧的四层/七层网络升级成可观测、可控、可追溯的"活电路"。网关只负责入口流量，服务间通信则全交给Mesh托管——这就是本质区别。 落地痛点更清晰：排查链路用Wireshark？太慢；熔断、重试、金丝雀要手动加代码？太痛苦；微服务架构一变，运维脚本跟着抽风？太头疼。Service Mesh把这些"非功能需求"从业务代码剥离，统一在基础设施层处理。拿金丝雀举例：你只需在控制平面调整权重，流量压根不碰业务容器，灰度发布就会变成"拖拽界面"的小活。对，它就是让运维从消防员升级成舵手的工具。