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插件

{
  "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
            }
          ]
        }
      ]
    }
  }
}

注意这里咱们装备了两条规矩

1. 榜首条规矩是针对带有特定 HTTP 头 http_release_version 等于 小奏技能 的恳求。这些恳求将被100%路由到新版本的 search_gray 服务。
2. 第二条规矩是默认规矩，适用于一切其他恳求。在这个比方中，咱们将90%的流量路由到旧版本的 search 服务，将10%的流量路由到灰度的 search 服务

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

总结

总的来说基于apisix完成灰度发布仍是比较简略的，完成方法有多种，差异主要仍是kubernetes中是多个service仍是单个service

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

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

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