ServiceMesh 4:实现流量染色和分级发布

ServiceMesh系列

1 什么是流量染色

在复杂的生产场景中,经常会有同一个服务中,存在多个版本长期共存的需求。为了让不同的用户在不一样的版本中使用,就需要对用户的请求进行采样和染色,打上不同的标识。

这样的目的有几个:

  1. 支撑分级发布,避免全量发布时可能遇到的大规模风险,如系统崩溃、用户流失。
  2. 支持染色实验,让部分人优先体验新版本或者实验功能
  3. QA的线上问题分析、验证、调试,甚至压测都可以放在染色部署区域去做,因为是强隔离模式,可以避免对线上其他用户的影响

使用Service Mesh的流量染色能力,可以在单个服务中根据特征值进行多元版本流量分发。特别是链路繁琐的巨型网格中,能够管理长达10个以上的链路分流调度,这个能力显得非常重要。常见的 Canary Release(金丝雀)、ABTesting、Diversified Version(多版本分流),都是基于此类算法实现。这边介绍在无侵入业务的情况下,Mesh如何实现流量染色。

1. Canary Release

2. Diversified Version

3. Diversified Version

2 Mesh使用标签特性进行染色

Mesh如果想要实现流量染色,需要具备以下几个条件:

  • 请求的流量中,需要附带某些特征,如流量的请求的Header、Cookies、queryParams等,它们带有某些信息。
  • 部署多版本服务
    • 部署在kubernetes上的服务(svc)的实例(pod)需要接入Mesh,并打上版本标签
    • 或者创建不同的服务(svc),后面把流量引入到这个新的服务上去
  • 在Mesh平台上对应的服务中配上策略:当请求的流量带有某些特征(如header中带有UserID=12345678)时,流量路由到对应标签(如 version = v1.7 )的服务实例上。
  • 不符合条件的路由则默认走到默认版本中(如 version = default)。

所以,Mesh的染色本质上是通过在流量中携带一些特征(如流量的请求的Header、Cookies、queryParams等),而Mesh会根据这些请求的特征进行路由匹配,转发到对应的带有某些特征的服务实例上。

未匹配成功的流量则走到默认版本中,从而实现多个版本和跟默认版本的业务隔离的目标。

2.1 Mesh 染色流转原理

2.1.1 Istio支持的策略模型

即Istio支持的流量特征包括uri、scheme、method、headers、queryParams等条件,可以根据这些特征进行路由转发:

完整参考官方文档:https://istio.io/latest/docs/reference/config/networking/virtual-service/

2.1.2 流量转发实现

基于上述的策略模型,如果你想配置如下:请求的header 带有 username=brand 或者 dep=A1025 的时候,将流量转发到服务的v1版本,否着转发到default版本。

则策略代码如下:

# 说明:VirtualService 流量染色,根据不同的条件将流量发往不同特征的版本中,假设这边有default、v1、v2 版本
apiVersion: networking.istio.io/beta
kind: VirtualService
metadata:
  name: router-test-vs
spec:
  hosts:
  - router-test-vs  # 调度router-test服务的流量
exportTo:
- "."
http:  # 加各种路由条件,比如匹配人员、所属部门进行路由
- match  # 用户匹配 brand,部门匹配 A1025 时
  - headers:
    username:
      exact: brand
  - headers:
    department:
      exact: A1025
  route:
    destination:
    # todo 匹配条件的流量路由到对应的服务上,比如ServiceA-V1
route: 
  destination:
  # todo 不匹配条件的流量路由到其他服务上,比如ServiceA-V2

3 总结

本文介绍了在Mesh场景下如何使用流量染色,来对不同特征的流量进行分发的实现过程。流量染色在我们实际的生产环境中可以有很多收益和价值:

  1. 支撑分级发布,避免全量发布时出现问题
  2. 支持染色实验,让部分人进入实验环境
  3. QA的线上问题分析、验证、调试,甚至压测
相关推荐
九卷技术录14 天前
(微服务)服务治理:几种开源限流算法库/应用软件介绍和使用
微服务·服务治理·限流算法
Dylanioucn1 个月前
【分布式微服务云原生】《微服务架构下的服务治理探秘》
分布式·微服务·云原生·架构·服务治理·服务拆分·反腐层
Hello-Brand1 个月前
ServiceMesh 3:路由控制(图文总结)
istio·服务网格·envoy·服务治理·servicemesh·路由调度
华为云开发者联盟1 个月前
内核级流量治理引擎Kmesh八大新特性解读
ebpf·服务网格·kmesh·sidecar
Hello-Brand2 个月前
ServiceMesh 2:控制面和数据面的职责(图文总结)
微服务·istio·envoy·服务治理·service mesh·控制面·数据面
vivo互联网技术2 个月前
vivo 全链路多版本开发测试环境落地实践
devops·测试环境·流量染色
Hello-Brand2 个月前
ServiceMesh 1:大火的云原生微服务网格,究竟好在哪里?
分布式·微服务·istio·服务网格·service mesh·分布式框架
-无-为-4 个月前
科普文:微服务技术栈梳理
缓存·微服务·消息队列·负载均衡·springcloud·服务治理·微服务框架
研究司马懿5 个月前
【云原生】Kubernetes部署高可用平台手册
云原生·容器·kubernetes·k8s·负载均衡·高可用架构