服务网格是云原生架构中专门负责处理服务间通信的基础设施层，它以Sidecar代理的模式部署在每一个服务实例旁边，接管所有进出服务的网络流量，从而实现流量管控、服务发现、链路追踪、安全认证等通用治理能力，无需业务代码做任何改动。
服务网格的核心概念与工作原理
服务网格的核心架构分为数据平面和控制平面两部分。数据平面由一系列Sidecar代理组成，比如常用的Envoy，每个代理和对应的服务实例部署在同一个Pod中，所有服务的入站和出站流量都会先经过这个代理。控制平面负责管理和配置这些代理，下发路由规则、策略配置等内容，常见的控制平面实现有Istio、Linkerd等。
服务网格的优势在于将通信相关的非业务逻辑从业务代码中剥离出来，让开发者可以专注于业务功能的实现。比如以前需要在.NET代码中写的熔断、重试逻辑，现在都可以通过服务网格的配置来完成，降低了业务代码的复杂度。
服务网格的核心能力
- 流量管理：支持按权重灰度发布、流量镜像、超时重试等策略，无需修改业务代码
- 可观测性：自动采集服务间的调用链路、指标数据、日志，对接监控系统即可查看
- 安全能力：实现服务间的双向TLS认证、访问权限控制，保障通信安全
- 弹性能力：提供熔断、限流、故障注入等能力，提升系统的容错性
.NET应用集成服务网格的步骤
以Istio作为服务网格实现，Kubernetes作为容器编排平台为例，.NET应用集成服务网格的流程主要分为以下几步。
第一步：准备.NET微服务应用
首先需要一个容器化的.NET微服务应用，这里以一个简单的.NET Web API项目为例，项目代码如下：
// Program.cs 代码
var builder = WebApplication.CreateBuilder(args);
// 添加控制器服务
builder.Services.AddControllers();
var app = builder.Build();
// 配置HTTP请求管道
app.MapControllers();
// 暴露健康检查接口，服务网格可通过该接口判断服务状态
app.MapGet("/health", () => "Healthy");
app.Run();
对应的Dockerfile内容如下：
# 使用.NET 8 SDK镜像作为构建阶段 FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build WORKDIR /app # 复制项目文件并还原依赖 COPY *.csproj ./ RUN dotnet restore # 复制所有文件并发布项目 COPY . . RUN dotnet publish -c Release -o out # 使用.NET 8运行时镜像作为运行阶段 FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS runtime WORKDIR /app COPY --from=build /app/out . # 暴露8080端口 EXPOSE 8080 ENTRYPOINT ["dotnet", "服务网格示例.dll"]
第二步：部署应用到Kubernetes集群
编写Kubernetes的部署文件，将.NET应用部署到集群中，部署文件示例如下：
apiVersion: apps/v1
kind: Deployment
metadata:
name: dotnet-service
labels:
app: dotnet-service
spec:
replicas: 2
selector:
matchLabels:
app: dotnet-service
template:
metadata:
labels:
app: dotnet-service
spec:
containers:
- name: dotnet-service
image: 你的镜像地址:latest
ports:
- containerPort: 8080
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10
periodSeconds: 5
---
apiVersion: v1
kind: Service
metadata:
name: dotnet-service
spec:
selector:
app: dotnet-service
ports:
- protocol: TCP
port: 80
targetPort: 8080
type: ClusterIP
执行部署命令将应用部署到集群：
kubectl apply -f deployment.yaml
第三步：安装Istio并注入Sidecar
首先安装Istio控制平面到Kubernetes集群，安装完成后，给需要启用服务网格的命名空间打上标签，让Istio自动给该命名空间下的Pod注入Sidecar代理：
# 安装Istio，这里使用demo配置档 istioctl install --set profile=demo -y # 给default命名空间打标签，启用自动注入 kubectl label namespace default istio-injection=enabled
之后重新部署之前的.NET应用，此时Pod中会自动增加一个Istio的Sidecar容器，查看Pod详情可以看到两个容器在运行：
kubectl get pods kubectl describe pod dotnet-service-xxxxxx
第四步：配置服务网格规则
可以通过Istio的自定义资源来配置流量规则，比如配置灰度发布规则，将80%的流量转到旧版本，20%的流量转到新版本：
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
name: dotnet-service-vs
spec:
hosts:
- dotnet-service
http:
- route:
- destination:
host: dotnet-service
subset: v1
weight: 80
- destination:
host: dotnet-service
subset: v2
weight: 20
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
name: dotnet-service-dr
spec:
host: dotnet-service
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
给不同版本的应用打上对应的version标签，Istio就会按照配置的规则分发流量。
.NET使用服务网格的注意事项
在.NET应用中使用服务网格时，需要注意几个问题。首先是端口问题，Istio默认只拦截特定范围的端口流量，如果.NET应用使用了非标准端口，需要在部署文件的Pod注解中声明端口，避免流量没有被Sidecar接管。其次是健康检查配置，要保证健康检查的路径和端口是Sidecar能够访问到的，否则会导致Pod被误判为不健康。另外，服务网格会增加一定的网络延迟，在对延迟要求极高的场景下需要做充分的性能测试。
服务网格并没有取代.NET应用中的HttpClient等通信组件，它只是在网络层做流量拦截和治理，应用内部的服务调用还是可以正常使用HttpClient发起请求，不需要做额外的代码改造，这也是服务网格对业务代码侵入性极低的体现。