微服务治理

楔子：通信的复杂性

掌握Kubernetes后，韩立在云上仙境中如鱼得水。他的韩门运行稳定，能够自动扩缩容、自愈、滚动更新，一切都显得那么完美。

然而，随着服务的不断增多，韩立发现了一个新的问题：服务间通信的复杂性。

在微服务架构中，服务之间的通信需要处理很多横切关注点（Cross-Cutting Concerns）：

• 服务发现：如何找到目标服务
• 负载均衡：如何分发请求
• 熔断降级：如何防止服务雪崩
• 限流：如何控制流量
• 重试：如何处理失败
• 超时：如何设置超时时间
• 安全：如何加密通信、认证授权
• 监控：如何追踪请求链路
• 日志：如何记录通信日志

这些逻辑如果都写在业务代码中，会导致：

1. 代码耦合：业务逻辑与通信逻辑混合
2. 重复代码：每个服务都要实现相同的逻辑
3. 难以维护：修改通信逻辑需要修改所有服务
4. 技术栈绑定：不同语言需要实现不同的逻辑

韩立想起了源界中流传的"服务网格"（Service Mesh）理论。这个理论说，可以将服务间通信的逻辑从业务代码中抽离出来，下沉为基础设施，由Sidecar代理来处理。

“这就是我需要的！“韩立眼中闪烁着兴奋的光芒。

第一节：本命剑灵——Sidecar模式

在服务网格中，每个服务都有一个"本命剑灵”——Sidecar代理。这个代理附着在服务身边，专职处理服务间通信，让服务本体能够专心处理业务逻辑。

Sidecar就像源界中的"护道傀儡”，它：

• 与业务服务同生共死：Sidecar和业务服务运行在同一个Pod中
• 代理所有通信：所有进出服务的流量都经过Sidecar
• 透明代理：业务服务无需感知Sidecar的存在

在Istio中，Sidecar由Envoy实现。Envoy是一个高性能的代理，支持HTTP/1.1、HTTP/2、gRPC等协议。

当服务A调用服务B时：

1. 服务A发送请求 → Envoy Sidecar A
2. Envoy Sidecar A进行服务发现、负载均衡、熔断等处理
3. 请求发送到 → Envoy Sidecar B
4. Envoy Sidecar B进行认证、限流等处理
5. 请求转发到 → 服务B
6. 响应按原路返回

这样，所有的通信逻辑都在Sidecar中处理，业务服务只需要专注于业务逻辑。

第二节：天条律法司——Istio控制平面

Sidecar负责处理具体的通信，但谁来制定规则呢？

这就是Istio控制平面的作用。控制平面就像"天条律法司"，负责制定所有服务间通信的规则，并下发到每个Sidecar执行。

Istio控制平面包含以下组件：

Pilot：服务发现和流量管理

• 从Kubernetes等注册中心获取服务信息
• 将路由规则、负载均衡策略等配置下发到Envoy

Citadel：安全和证书管理

• 为服务间通信提供mTLS（双向TLS）加密
• 管理证书的生成、分发和轮换

Galley：配置验证和分发

• 验证Istio配置的正确性
• 将配置转换为Envoy可理解的格式

Mixer（已废弃，功能合并到Envoy）：策略和遥测

• 访问控制策略
• 指标收集和日志记录

韩立部署了Istio：

# 安装Istio
istioctl install --set profile=default

# 为命名空间启用自动注入Sidecar
kubectl label namespace default istio-injection=enabled

当在启用了自动注入的命名空间中创建Pod时，Istio会自动注入Envoy Sidecar：