这里是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
属性,从而动态地将部分流量引导至各种上游服务。该插件可应用于灰度发布和蓝绿发布的场景
举个
比方现在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
}
]
}
]
}
}
}
注意这里咱们装备了两条规矩
- 榜首条规矩是针对带有特定 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
的元数据管理不太一样
所以后续要完成全链路灰度可能会有比较大的不同