一、什么是服务网格？
服务网格（Service Mesh）是专门处理服务间通信的基础设施层，通过透明注入的方式，将服务治理能力（服务发现、负载均衡、流量控制、可观测性等）从业务代码中剥离，实现"业务逻辑"与"通信治理"的解耦。
二，核心特征或用途包括：
解决微服务之间通信的共性问题，业务代码只关心业务服务，不用写网络治理代码，
流量管理 ：灰度发布，金丝雀，流量镜像，路由，超时，重试，熔断，限流
透明性 ：对业务代码无侵入，无需修改应用即可获得治理能力；
分布式 ：由数据平面（代理集群）和控制平面组成的分布式系统；
可观测性 ：内置指标 metrics、日志logging、调用链tracing 能力；
安全性 ：提供服务间mTLS通信加密、身份认证等安全保障，授权策略；
故障注入 ：模拟延时，报错，做混沌工程测试；
负载均衡 ：多种负载均衡策略（轮询，最小链接，一致性哈希）；
服务网格解决了传统微服务架构中"烟囱式治理"的痛点，特别适合多语言异构系统（如Java、Go 、Python混合架构）的统一治理。
三、服务网格核心架构流程
流程说明：客户端请求首先经过本地Sidecar代理，依次完成服务发现（从控制平面获取服务列表）、负载均衡（选择目标实例）、流量控制（熔断、限流等）；请求到达目标服务的Sidecar后转发至业务服务，响应按原路返回。同时，Sidecar实时采集流量指标上报控制平面，控制平面通过动态配置调整治理策略。
四、服务网格通信时序
五，架构和实现原理
ServiceMesh采用 Sidecar （边车代理）模式，
数据面 ，Data Plane：Sidecar 代理进程和业务Pod/容器部署在同一个主机，接管业务所有进出网络流量，业务服务之间不互相调用，请求先经过Sidecar；
控制面 ，Control Plane：独立组件，不转发流量，下发配置规则给所有的 Sidecar，统一管理策略；
经典代表：istIO最主流，底层 Sidecar 使用C++编写的 Envoy；
六，开发语言
Envoy 数据面代理，istIO 默认，C++编写
istIO 控制面组件，Go编写
Linkerd 控制面 Go 编写， 数据面 Rust 编写；
Kuma 控制面 Go 编写， 数据面C++编写（基于Envoy）
七，部署方法（以最常用的 Istio + Kubernetes为例）
1，前置环境，
Kubernetes（k8s），istioctl客户端工具。
2，安装 istio
#下载 istioctl
curl -L https://istio.io/downloadIstio | sh -
cd istio-xxx
export PATH= PWD/bin:PATH #注意：PWD和后一个PATH前面有英文的美元符号，
#安装 istio控制面 istiod 到 k8s
istioctl install --set
profile=default -y
3，命名空间开启 Sidecar 自动注入
#给命名空间打标签，新建Pod会自动注入 Sidecar
kubectl label namespace demo-ns
istio-injection=enabled
4，部署业务应用
正常部署微服务yaml，Pod 启动时自动注入 istio-proxy（Envoy）容器，无需改业务代码；
5，下发治理规则，
通过 CRD 资源配置流量策略：VirtualService，DestinationRule，AuthorizationPolicy
八，优点，
1，无入侵 ，对业务代码无侵入，无需修改应用即可获得治理能力，java、golang，python任何语言微服务都可接入；
2，能力统一 ，所有微服务复用同一套流量治理，安全，监控能力，不用每个服务重复开发熔断，加密，trace；
3，解耦 ，业务开发只关注业务，运维/架构统一管控服务通信策略；
4，标准化，统一的可观测数据，统一安全策略，多语言微服务体系治理更简单；
九，缺点，
1，性能开销 ，所有请求都经过 Sidecar 代理，增加网络延迟，cpu/内存开销大，高吞吐场景需要做性能压测；
2，复杂度高 ，组件多，istiod，envoy，CRD资源，学习成本高，排障难度大；
3，运维成本上升 ，需要额外维护面板，Sidecar 版本升级，资源占用量大，
4，小体量项目不划算 ，少量微服务，如果引入ServiceMesh反而会过度设计，复杂了；
部分内容参考博主：https://blog.csdn.net/weixin_43290370/article/details/151576522