apisix实现http流量灰度方案的演进

这里是weihubeats ,觉得文章不错可以关注公众号小奏技术

背景

想要实现http流量灰度的核心还是看你用什么网关，才能决定你用什么技术方案。

如果我们想用spring cloud gateway那一套，那么我们就需要自己去开发一些路由规则。

本次我们讨论的是云原生网关apisix的一种灰度发布实现方式

基于k8s的单service pod替换

实际最简单的方案就是我们可以基于kubernetes的服务发现来做比如我们有一个search服务，有3个pod

我们可以发版只发布修改一个pod实现最简单的灰度

但是这样有一个最明显的弊端，我们无法精准控制灰度流量比例。在apisix那边对应只有一个upstream(上游服务)

基于k8s的多service+apisix traffic-split插件

traffic-split插件

traffic-split 插件可以通过配置match 和 weighted_upstreams 属性，从而动态地将部分流量引导至各种上游服务。该插件可应用于灰度发布和蓝绿发布的场景

官方文档:apisix.apache.org/zh/docs/api...

举个🌰

比如现在search需要进行蓝绿发布。那么我们需要首先创建两个上游服务

search
search-gray

对应的也是两个kubernetes的 service

search-service
search-service-gray

然后我们配置traffic-split插件

json 复制代码

{
  "plugins": {
    "traffic-split": {
      "rules": [
        {
          "match": [
            {
              "vars": [
                ["http_release_version", "==", "小奏技术"]
              ]
            }
          ],
          "weighted_upstreams": [
            {
              "upstream_id": "search_gray_upstream_id",
              "weight": 10
            }
          ]
        },
        {
          "match": [
            {
              "vars": []
            }
          ],
          "weighted_upstreams": [
            {
              "upstream_id": "search_upstream_id",
              "weight": 90
            },
            {
              "upstream_id": "search_gray_upstream_id",
              "weight": 10
            }
          ]
        }
      ]
    }
  }
}

注意这里我们配置了两条规则

第一条规则是针对带有特定 HTTP 头 http_release_version 等于 小奏技术 的请求。这些请求将被100%路由到新版本的 search_gray 服务。
第二条规则是默认规则，适用于所有其他请求。在这个例子中，我们将90%的流量路由到旧版本的 search 服务，将10%的流量路由到灰度的 search 服务

注意原生的traffic-split插件比较简陋，不支持uid这种自定义参数,需要自己开发,自定义请求头参数仅支持http_开头的，比如http_x_user_id

总结

总的来说基于apisix实现灰度发布还是比较简单的，实现方式有多种，区别主要还是kubernetes中是多个service还是单个service

相对来说多service是apisix更推荐的做法，也能更精准控制流量。

但是相对于java传统的比如spring cloud和dubbo这些服务发现框架来说都是单service的元数据管理不太一样

所以后续要实现全链路灰度可能会有比较大的不同