微服务流量治理-Envoy与Istio服务网格

前言

用户需求决定要做什么软件？软件架构决定需要什么样的基础设施？

2005年，PeterRodgers提出Micro-Web-Service，微服务雏形出现；

2011年，威尼斯架构师会议正式提出微服务概念；

2014年3月，MartinFowler与JamesLewis发表经典文章，微服务理念普及；

2014年6月，Google在DockerCon首次发布Kubernetes；

2015年7月，K8s发布v1.0稳定版。

基础设施层随着上层应用架构的变化而变化的，K8s就是为解决微服务架构应用运维难的问题，而诞生的容器编排平台。

在云计算时代的单体架构中，应用内部各模块之间的交互，本质上是进程内的函数调用。这种调用无需依赖网络，也不涉及序列化或反序列化，不存在网络超时或抖动，仅是方法栈的进出，逻辑同步、行为确定，通信高度可靠。

而在云原生时代，应用由单体拆分为微服务架构后，基础设施层面临根本性变化：原本在内存中高效完成的函数调用，被迫转化为依赖网络的远程通信，同时引入网络抖动、超时、服务发现、序列化开销等新的复杂性。

虽然Kubernetes在PaaS层提供了强大的基础能力，例如：

  • 应用部署与升级

  • 弹性伸缩

  • 服务自动注册与发现

  • 服务负载均衡

但在分布式环境中，网络的不可靠性仍然不可忽视，即使在使用Kubernetes之后，SaaS层的微服务应用仍面临诸多挑战，需要额外的机制来保证可靠性和可观测性，例如：

  • 客户端重试与可配置超时

  • 负载均衡与限流、熔断

  • 服务间路由、按需路由与边缘路由

  • 流量镜像与 A/B 测试

  • 内部发布与故障注入

  • 异常点检测、健康状态检查

  • 日志收集与分布式链路追踪

  • 指标统计与度量

有了K8S和服务网格还需要微服务框架吗？

虽然在基础设施层：K8s和服务网格可以解决微服务架构中的运行环境（Kubernetes）、服务发现（CoreDNS）、流量治理（Ingress、Envoy、Istio）、通信可靠性（Envoy、Istio）等问题，

但是微服务框架仍需负责代码层：业务调用封装（Feign/gRPC）、应用级限流熔断（Resilience4j/Hystrix）、动态配置（Nacos/Apollo/Console/Go-ZeroConfig）、消息总线（SpringCloudStream、Go-MicroBroker、Go-ZeroMQ）、分布式事务（Seata/Go-ZeroTCC/Saga）等应用层开发与业务逻辑问题。

什么是微服务治理？

微服务治理：管理控制微服务不断增长产生的复杂度；

网络拓扑变动、网络延时、网络通信安全........

API网关、服务发现、服务容错、服务部署、数据调用、分布式链路追踪、数据全链路透传........

ServiceMesh概念

ServiceMesh（服务网格）是云原生、微服务架构下的基础设施层，用于统一治理服务间的网络通信。

在基础设施层构建微服务服务网格与统一网关，可以将南北向入口流量与东西向服务间通信的流量控制、安全策略、可观测性、熔断、限流、灰度发布等能力，统一从业务代码中剥离并下沉到基础设施层进行托管治理，实现与业务逻辑解耦，同时天然兼容多语言技术生态。

在基于服务网格与网关的云原生架构下，微服务开发框架中的流量治理、服务发现、配置、熔断限流等能力，可以完全由基础设施层替代，业务开发不再需要强依赖SpringCloud、Go-Zero、Go-Micro这类代码层治理框架，只需要关注业务开发能力即可。

ServiceMesh采用经典的 控制平面 + 数据平面 架构：
  • 数据平面（Data Plane）：以 sidecar 代理（如 Envoy）的形式和应用部署在一起，接管所有进出流量。
  • 控制平面（Control Plane）：负责统一下发规则、服务发现、证书管理、策略配置。
核心价值： 
  • 无侵入：不用改业务代码，跨语言、跨框架统一治理
  • 全链路可观测：指标、日志、追踪一体化
  • 安全：自动 mTLS 加密、认证、授权
  • 流量治理：灰度、熔断、重试、超时、流量镜像
Istio（控制平面） + Envoy（数据平面）

服务网格数据平面（Envoy）

Envoy是Istio服务网格的核心数据平面组件，通常以Sidecar模式运行在业务Pod内，与应用容器共享网络命名空间，透明拦截并治理应用的所有入站/出站流量，实现无侵入的流量管控、安全加密与可观测性能力。

Envoy Sidecar容器是通过给业务pod所在的命名空间（NS）打标签，自动注入业务pod的。无代码侵入也无需修改原CD流程。

IstioGateway本质就是个独立部署的Envoy，只是 Istio给它包装了一层。

744ff2feb3ead0604740542fe9e6d00d

如果上图所示Envoy的内部组件通过xDS协议从Istior实时热更新配置，并执行配置规则。

VirtualService/DestinationRule/Gateway
       ↓ 编译
   Istiod控制平面
       ↓
   LDS/RDS/CDS/EDS
       ↓
   Envoy执行

XDS（LDS/RDS/CDS/EDS） 是Envoy与Istio控制平面内部通信的协议，一般不需要使用者关心，也不会直接写这些内容。

XDS是基础设施的实现细节，Envoy会自动从IstioPilot拉取配置。

真正需要关心的是Istio控制器监听的CRD资源

Gateway：定义进出集群的南北流量规则，相当于入口控制器。

VirtualService：定义应用内部或外部流量如何路由到不同版本的服务，实现灰度、金丝雀等。

DestinationRule：定义目标服务的策略，比如流量分割、连接池、熔断等。

服务网格控制平面（Istio）

Istio是服务网格的控制平面负责监听VirtualService/DestinationRule/Gateway等CRD资源的变化转换成Envoy可以识别的配置，通过XDS协议下发到Envoy执行。

- TCP：两车道（全双工）支持同时发送和接收

- HTTP/2：单车道，1条连接，多路Stream，不乱序

- SSE：HTTP/2 单车道，服务器单向推流 → AI 聊天

- List-Watch：HTTP/1.1 单车道，服务器单向推事件 → K8s

- XDS：gRPC+HTTP/2 单车道，服务器单向推配置 → Istio

TCP虽然给了双车道，但这以上3个全是单行道，只许服务器往回推，客户端只发请求不插话，是为了保证数据不乱序。

架构

1.代理

服务之间的通信（比如这里的 Service A 访问 Service B）会通过代理（默认是 envoy）来进行；

中间的网络协议支持 HTTP/1.1，HTTP/2，gRPC 或者 TCP，可以说覆盖了主流的通信协议；

代理会和控制平面实时通信

  • 一方面可以获取需要的服务之间的信息
  • 一方面也可以汇报服务调用的 metrics 数据。

2.控制平面

控制中心做了进一步的细分，分成了 Pilot、Mixer、和 Citadel，它们的各自功能如下：

Pilot

为 envoy 提供了服务发现，流量管理和智能路由（AB测试、金丝雀发布等），以及错误处理（超时、重试、熔断）功能。用户通过 pilot 的 API 管理网络相关的资源对象，pilot 会根据用户的配置和服务的信息把网络流量管理变成 envoy 能识别的格式分发到各个 sidecar 代理中。

Mixer

为整个集群执行访问控制（哪些用户可以访问哪些服务）和 policy 管理（rate limit，quota 等），并且收集代理观察到的服务之间的流量统计数据

Citadel

为服务之间提供认证和证书管理，可以让服务自动升级成 TLS 协议

功能

知道 istio 的核心架构，再来看看它的功能描述就非常容易理解了。

  • 连接：控制中心可以从集群中获取所有服务的信息，并分发给代理，这样代理就能根据用户的期望来完成服务之间的通信（自动地服务发现、负载均衡、流量控制等）

  • 安全加固：因为所有的流量都是通过代理的，那么代理接收到不加密的网络流量之后，可以自动做一次封装，把它升级成安全的加密流量

  • 控制：用户可以配置各种规则（比如 RBAC 授权、白名单、rate limit 或者 quota 等），当代理发现服务之间的访问不符合这些规则，就直接拒绝掉

  • 观察：所有的流量都经过代理，因此代理对整个集群的访问情况知道得一清二楚，它把这些数据上报到控制中心，那么管理员就能观察到整个集群的流量情况了

 

 

Envoy参考

Istio参考

posted on 2024-03-22 13:12  运维开发之路  阅读(101)  评论(0)    收藏  举报