微服务核心理论 - 流量策略

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

1 微服务的基本流量策略

微服务提供了一些技术来实现对微服务的流量的管理，其中最典型的就是对流量进行拆分和转发。
具体体现在金丝雀发布（灰度发布）、ABTesting 以及流量染色 等策略方案上，下面会进行详细的介绍。

2 价值和必要性

★ 价值驱动：

• 支持蓝绿发布、金丝雀发布，无需停服也能保证发布的无缝衔接，提高了服务整体的SLA。
• 全链路的ABTesting，保证不同特征类型的用户可以在独立的链路通道上测试、使用、实验、生产。
• 大幅降低早期为实现灰度而做多服务的资源（时间、服务器资源）损耗。

★ 业务视角：

• 实现所有业务 分级发布、扩散发布的能力，保证发布的渐序性。比如上线一个新功能，首先在小范围发布，观察一段时间之后在全量发布。
• 染色实验的各种场景，让不同类型的用户体验不同类型的功能。
• 实现多环境场景的降本增效：无需再对不同环境的服务独立部署，从维护和资源上来说，大大降低了成本。

3 流量调控

3.1 金丝雀发布、ABTesting

这是流量调度中典型的金丝雀场景，可以先放行一部分流量转发到一个新的服务实例中，这个新的服务实例只有你的研发和测试团队可以接入。可以在上面尝试使用或者测试，直到你确认你的服务是健康的，功能完整的，没有bug的，再把流量逐渐的引流过去。
这个的好处是减少发布新功能存在的风险，而且全程是无停服发布，对用户是透明无感知的，大大提高了可用性，提升服务SLA。

3.2 流量染色

流量染色也是一种典型的场景。如果你想让不同的用户群体(比如这边的Group A、Group B、Group C)使用的功能也是不同的，那流量染色是一个不可缺少的功能。
它可以把符合某些特征的用户流量调控到对应的服务版本中。比如GroupA是学生群体，对应到V1版本，GroupB是政企员工群体，对应到V2版本。需要注意的是，如果是一条完整的链路，那链路上的各个服务包括数据存储层都应该有不同的版本，这样才能一一对应。

3.3 染色实现方案（以ServiceMesh为例子）

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

1. 请求的流量中，需要附带某些特征，如流量的请求的Header、Cookies、queryParams等 中带有某些信息。

    Request Header：
    UserId: 135648468
    Dep: T204351
    X-Request-Id: ee6637e816d7470bb2e90e13e1130733

1. 部署在kubernetes上的服务（svc）的实例（pod）需要接入Mesh（如Istio），并在pod上打上版本标签。

    labels:
        app: traffic-test
        appName: traffic-test
        appType: java
        istio.io/rev: default
        pod-template-hash: 78ab8776a9
        security.istio.io/tlsMode: istio
        service.istio.io/canonical-revision: v1
        version: v1  #  在具体的 pod 中 label 上 v1 的 version 标签

1. 下发Istio的策略到kubernetes对应服务服务上：当请求的流量带有某些特征（如header中带有Dep=SO）时，流量路由到对应标签（如 version = v1 ）的服务实例上。

      spec:
        exportTo:
        - '*'
        host: xxx.com
        subsets:
        - labels:   #  这是v1 版本
            version: v1
          name: v1
          trafficPolicy:
            loadBalancer:
              simple: ROUND_ROBIN
        - labels:  # 这是default
            version: default
          name: default

1. header中符合带Dep=T204351的走v1版本，不符合条件的路由则默认走到默认版本中（如 version = default）。

所以，Mesh的染色本质上是通过在流量中携带一些特征（如流量的请求的Header、Cookies、queryParams等），而Mesh会根据这些请求的特征进行路由匹配，转发到对应的带有某些特征的服务实例上。
未匹配成功的流量则走到默认版本中，从而实现多个版本和跟默认版本的业务隔离的目标。

上面的图，当部门编号为 T204351的时候，流量会转发到服务的v1版本中；当部门编号为 T204352的时候，流量会转发到服务的v2版本中；剩余的流量，默认转发到服务的default版本中。

4 总结

丰富的流量管理策略为我们系统的稳定性，以及流量的多样化（金丝雀发布、ABTesting、分级扩散流量、流量染色）使用提供了保证。