这里是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
}
]
}
]
}
}
}
注意这里我们配置了两条规则
http_release_version
等于 小奏技术
的请求。这些请求将被100%路由到新版本的 search_gray
服务。search
服务,将10%的流量路由到灰度的 search
服务注意原生的
traffic-split
插件比较简陋,不支持uid
这种自定义参数,需要自己开发,自定义请求头参数仅支持http_
开头的,比如http_x_user_id
总结
总的来说基于apisix
实现灰度发布还是比较简单的,实现方式有多种,区别主要还是kubernetes
中是多个service
还是单个service
相对来说多service
是apisix
更推荐的做法,也能更精准控制流量。
但是相对于java传统的比如spring cloud
和dubbo
这些服务发现框架来说都是单service
的元数据管理不太一样
所以后续要实现全链路灰度可能会有比较大的不同