服务网格通过边车模式为.NET应用提供透明通信管理，支持服务发现、mTLS加密、可观测性及流量控制；在Kubernetes中结合Istio或Linkerd可实现无代码侵入的灰度发布与安全通信。
服务网格（Service Mesh）是云原生架构中用于管理服务间通信的专用基础设施层。它负责处理服务发现、负载均衡、加密传输、故障恢复、指标监控和安全控制等任务，而无需将这些逻辑嵌入业务代码中。在 .NET 应用中使用服务网格，可以让开发者更专注于业务逻辑，把通信的复杂性交给基础设施处理。
服务网格的核心功能
服务网格通常通过“边车”（Sidecar）模式运行，每个服务实例旁边部署一个代理（如 Envoy），所有进出流量都经过这个代理。常见功能包括：
- 自动服务发现与负载均衡：服务之间调用时自动定位目标实例并分发请求。
- mTLS 加密通信：在服务间自动启用双向 TLS，保障内网通信安全。
- 可观测性：收集请求延迟、错误率、追踪链路等数据，便于排查问题。
- 流量控制：支持灰度发布、金丝雀发布、熔断、重试等高级路由策略。
- 策略执行：实现访问控制、配额限制等统一治理规则。
主流服务网格：Istio 与 Linkerd
目前最常用的服务网格是 Istio 和 Linkerd。两者都支持 Kubernetes 环境下的 .NET 应用无缝集成。
- Istio 功能强大，适合复杂场景，支持细粒度流量管理和安全策略，常配合 Jaeger 或 Prometheus 做监控。
- Linkerd 更轻量，对性能影响小，安装简单，适合希望快速落地服务网格的团队。
它们都能自动注入边车代理到 .NET 服务的 Pod 中，无需修改代码。
在 .NET 中如何使用服务网格
.NET 应用本身不需要做任何变更来适配服务网格。只要运行在 Kubernetes 上，并启用服务网格的自动注入，通信就会被代理接管。
- HTTP/gRPC 调用透明处理：使用 HttpClient 或 gRPC 客户端调用其他服务时，实际流量由边车代理完成，应用无感知。
- 启用 mTLS：在 Istio 中开启 strict 模式后，.NET 服务间的通信自动加密，无需配置证书。
- 分布式追踪：结合 OpenTelemetry，.NET 应用可生成追踪上下文，服务网格自动传播 trace header。
- 健康检查与重试：超时、重试策略可在 Istio 的 VirtualService 中定义，不影响 .NET 代码。
实际部署示例（Kubernetes + Istio）
以一个 ASP.NET Core 微服务为例：
1. 部署 Istio 并启用命名空间自动注入：
istioctl install --set profile=default kubectl label namespace default istio-injection=enabled
2. 部署 .NET 服务：
kubectl apply -f my-dotnet-service.yaml
Pod 启动时会自动包含 Istio 代理容器。
3. 定义路由规则（如灰度发布）：
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: payment-service
spec:
hosts:
- payment-service
http:
- route:
- destination:
host: payment-service
subset: v1
weight: 90
- destination:
host: payment-service
subset: v2
weight: 10此时，从 .NET 服务发出的请求将按比例分发到不同版本。
基本上就这些。服务网格让 .NET 微服务在云原生环境中更安全、更可控，同时减少对 SDK 的依赖，提升系统整体稳定性。
