You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apisix.apache.org by Yuelin Zheng <zy...@163.com> on 2020/10/31 16:00:31 UTC
Proposal: add the traffic split plugin to apisix
Hi, Community,
I have implemented a plug-in related to traffic split, and I want to add the plug-in to apisix. The following is the main information of the plugin:
1. Background
After seeing this issue about traffic split plugin #2303(https://github.com/apache/apisix/issues/2303), I think this function is very useful, it can effectively realize the flow control function. Therefore, this inspired me to implement a dynamic upstream plugin.
2. Why do this
For details, please see: https://github.com/apache/apisix/issues/2303
Traffic split means that requests need to comply with certain rules in order to reach the designated upstream or a certain node in the upstream. Through this function, gray release, blue-green release and custom routing are realized, which is very useful for reducing downtime in the event of a failure.
3. Design
The dynamic upstream plug-in is mainly composed of two parts `match` and `upstreams` to implement the rules of the plugin. `match` is the matching rule of the plugin (the currently supported operations are: ==, ~=, ~~, >, >=, <, <=, in , ip_in). Only after the `match` rule is passed, can the `upstreams` rule in the plugin be reached, otherwise the default upstream is reached. In the `upstreams` rule, `upstream` is the configuration of the plugin upstream, and the `weight` field is the basis for traffic segmentation between upstream services (using the roundrobin algorithm).
note:
```
{
"Weight": 1
}
```
When the plug-in upstream configuration has only the weight field, it means the default upstream traffic ratio.
Example:
Grayscale release:
The traffic is split according to the weight field value configured in the upstreams part of the plug-in.
If `match` is not configured, match is passed by default. Divide the request traffic by 4:1, 4/5 of the traffic hits the upstream of the plugin port of `1981`, and 1/5 of the traffic hits the default upstream of the `1980` port.
```
"plugins": {
"dynamic-upstream": {
"rules": [
{
"upstreams": [
{
"upstream": {
"name": "upstream_A",
"type": "roundrobin",
"nodes": {
"127.0.0.1:1981":10
}
},
"weight": 4
},
{
"weight": 1
}
]
}
]
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"127.0.0.1:1980": 1
}
}
```
Blue-green release:
All requests hit the upstrean configured by the plugin (when weight is 0, the corresponding upstream is invalid).
```
"plugins": {
"dynamic-upstream": {
"rules": [
{
"match": [
{
"vars": [
[ "http_new-release","==","blue" ]
]
}
],
"upstreams": [
{
"upstream": {
"name": "upstream_A",
"type": "roundrobin",
"nodes": {
"127.0.0.1:1981":10
}
},
"weight": 1
},
{
"weight": 0
}
]
}
]
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"127.0.0.1:1980": 1
}
}
```
Custom release:
There are multiple conditions in vars, and the relationship between them is `add`. Multiple vars can be configured, then they have an `or` relationship.
After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the traffic hits the default upstream of the `1980` port.
```
"plugins": {
"dynamic-upstream": {
"rules": [
{
"match": [
{
"vars": [
[ "arg_name","==","jack" ],
[ "http_user-id",">=","23" ],
[ "http_apisix-key","~~","[a-z]+" ]
]
}
],
"upstreams": [
{
"upstream": {
"name": "upstream_A",
"type": "roundrobin",
"nodes": {
"127.0.0.1:1981":10
}
},
"weight": 4
},
{
“weight”: 2
}
]
}
]
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"127.0.0.1:1980": 1
}
}
```
Note: The vars parameter here can be obtained from the http request header, querystring or nginx variable.
The above is a brief introduction to the dynamic upstream plugin.
I want to add this plugin to the apisix project, what do you think?
Re:Re: Proposal: add the traffic split plugin to apisix
Posted by Yuelin Zheng <zy...@163.com>.
Thank you very much for your reply, the following is my understanding of related issues.
Reply to question 1:
It is not clearly described in my example. Multiple upstream configurations in the plug-in are configured at the same location, and the second upstream configuration in the example is the configuration on the route.
Reply to question 2:
match is an array structure, it can have multiple vars rules. The condition in vars is the relationship of add, and the rule between multiple vars is the relationship of or. When there are multiple vars rules, only one of them needs to be satisfied.
Reply to question 3:
The weight value here does not need to be configured. This blue-green release is not a good example. `http_new-release` is a request header named `new-release` from the http request.
Reply to question 4:
Thank you for your suggestion and I will make appropriate adjustments.
Reply to question 5:
The vars rule is: support request headers, request parameters or NGINX variables to do a series of operations (`==`, `~=`, `~~`, `>=`, `<=`, etc.).
Reply to question 6:
I think they are not in conflict, because the plugin is just a rule bound to the route. If the `vars` rule is configured on the route, I think it is also independent of the plugin's `vars` rule, as long as the request satisfies one of the rules, the other rule will also be executed.
Reply to question 7:
I did not consider this issue, we need further discussion.
At 2020-11-01 14:02:34, "Ming Wen" <we...@apache.org> wrote:
>I have some questions.
>1. The example of Grayscale release is not easy to understand. Why are
>multiple upstreams scattered in different places for configuration? We need
>a clear design.
>2. In the match rules, why do we need a separate `vars`, can't we just
>write the rules directly?
>3. In the example released by Blue-green, why do I need to configure the
>weight? Where does the `http_new-release` in the rules come from?
>4. In addition, I suggest you use yaml to describe instead of json, yaml is
>easier for people to understand
>5. the design of ["arg_name","==","jack"] is complicated, is there a more
>concise description?
>6. Will there be conflicts between the rules of this plugin and the rules
>in the routing? How should the conflict be resolved?
>7. Where will the upstream health check be set?
>
>Thanks,
>Ming Wen, Apache APISIX & Apache SkyWalking
>Twitter: _WenMing
>
>
>wei jin <kv...@apache.org> 于2020年11月1日周日 下午12:52写道：
>
>> +1 agree
>> LGTM
>>
>> Yuelin Zheng <zy...@163.com> 于2020年11月1日周日 上午12:00写道：
>>
>> > Hi, Community,
>> >
>> >
>> > I have implemented a plug-in related to traffic split, and I want to add
>> > the plug-in to apisix. The following is the main information of the
>> plugin:
>> >
>> >
>> > 1. Background
>> >
>> >
>> > After seeing this issue about traffic split plugin #2303(
>> > https://github.com/apache/apisix/issues/2303), I think this function is
>> > very useful, it can effectively realize the flow control function.
>> > Therefore, this inspired me to implement a dynamic upstream plugin.
>> >
>> >
>> > 2. Why do this
>> > For details, please see: https://github.com/apache/apisix/issues/2303
>> > Traffic split means that requests need to comply with certain rules in
>> > order to reach the designated upstream or a certain node in the upstream.
>> > Through this function, gray release, blue-green release and custom
>> routing
>> > are realized, which is very useful for reducing downtime in the event of
>> a
>> > failure.
>> >
>> >
>> > 3. Design
>> > The dynamic upstream plug-in is mainly composed of two parts `match` and
>> > `upstreams` to implement the rules of the plugin. `match` is the matching
>> > rule of the plugin (the currently supported operations are: ==, ~=, ~~,
>> >,
>> > >=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
>> > `upstreams` rule in the plugin be reached, otherwise the default upstream
>> > is reached. In the `upstreams` rule, `upstream` is the configuration of
>> the
>> > plugin upstream, and the `weight` field is the basis for traffic
>> > segmentation between upstream services (using the roundrobin algorithm).
>> >
>> >
>> > note:
>> > ```
>> > {
>> > "Weight": 1
>> > }
>> > ```
>> > When the plug-in upstream configuration has only the weight field, it
>> > means the default upstream traffic ratio.
>> >
>> >
>> > Example:
>> >
>> >
>> > Grayscale release:
>> > The traffic is split according to the weight field value configured in
>> the
>> > upstreams part of the plug-in.
>> > If `match` is not configured, match is passed by default. Divide the
>> > request traffic by 4:1, 4/5 of the traffic hits the upstream of the
>> plugin
>> > port of `1981`, and 1/5 of the traffic hits the default upstream of the
>> > `1980` port.
>> >
>> >
>> > ```
>> > "plugins": {
>> > "dynamic-upstream": {
>> > "rules": [
>> > {
>> > "upstreams": [
>> > {
>> > "upstream": {
>> > "name": "upstream_A",
>> > "type": "roundrobin",
>> > "nodes": {
>> > "127.0.0.1:1981":10
>> > }
>> > },
>> > "weight": 4
>> > },
>> > {
>> >
>> > "weight": 1
>> > }
>> >
>> > ]
>> > }
>> > ]
>> > }
>> > },
>> > "upstream": {
>> > "type": "roundrobin",
>> > "nodes": {
>> > "127.0.0.1:1980": 1
>> > }
>> > }
>> > ```
>> >
>> >
>> > Blue-green release:
>> > All requests hit the upstrean configured by the plugin (when weight is 0,
>> > the corresponding upstream is invalid).
>> >
>> >
>> > ```
>> > "plugins": {
>> > "dynamic-upstream": {
>> > "rules": [
>> > {
>> > "match": [
>> > {
>> > "vars": [
>> > [ "http_new-release","==","blue" ]
>> > ]
>> > }
>> > ],
>> > "upstreams": [
>> > {
>> > "upstream": {
>> > "name": "upstream_A",
>> > "type": "roundrobin",
>> > "nodes": {
>> > "127.0.0.1:1981":10
>> > }
>> > },
>> > "weight": 1
>> > },
>> > {
>> >
>> > "weight": 0
>> > }
>> >
>> > ]
>> > }
>> > ]
>> > }
>> > },
>> > "upstream": {
>> > "type": "roundrobin",
>> > "nodes": {
>> > "127.0.0.1:1980": 1
>> > }
>> > }
>> > ```
>> >
>> >
>> > Custom release:
>> > There are multiple conditions in vars, and the relationship between them
>> > is `add`. Multiple vars can be configured, then they have an `or`
>> > relationship.
>> > After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
>> > the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
>> > traffic hits the default upstream of the `1980` port.
>> >
>> >
>> > ```
>> > "plugins": {
>> > "dynamic-upstream": {
>> > "rules": [
>> > {
>> > "match": [
>> > {
>> > "vars": [
>> > [ "arg_name","==","jack" ],
>> > [ "http_user-id",">=","23" ],
>> > [ "http_apisix-key","~~","[a-z]+" ]
>> > ]
>> > }
>> > ],
>> > "upstreams": [
>> > {
>> > "upstream": {
>> > "name": "upstream_A",
>> > "type": "roundrobin",
>> > "nodes": {
>> > "127.0.0.1:1981":10
>> > }
>> > },
>> > "weight": 4
>> > },
>> > {
>> >
>> > “weight”: 2
>> >
>> > }
>> >
>> > ]
>> > }
>> > ]
>> > }
>> > },
>> > "upstream": {
>> > "type": "roundrobin",
>> > "nodes": {
>> > "127.0.0.1:1980": 1
>> > }
>> > }
>> > ```
>> >
>> >
>> > Note: The vars parameter here can be obtained from the http request
>> > header, querystring or nginx variable.
>> > The above is a brief introduction to the dynamic upstream plugin.
>> >
>> >
>> > I want to add this plugin to the apisix project, what do you think?
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
Re: Proposal: add the traffic split plugin to apisix
Posted by Ming Wen <we...@apache.org>.
I have some questions.
1. The example of Grayscale release is not easy to understand. Why are
multiple upstreams scattered in different places for configuration? We need
a clear design.
2. In the match rules, why do we need a separate `vars`, can't we just
write the rules directly?
3. In the example released by Blue-green, why do I need to configure the
weight? Where does the `http_new-release` in the rules come from?
4. In addition, I suggest you use yaml to describe instead of json, yaml is
easier for people to understand
5. the design of ["arg_name","==","jack"] is complicated, is there a more
concise description?
6. Will there be conflicts between the rules of this plugin and the rules
in the routing? How should the conflict be resolved?
7. Where will the upstream health check be set?
Thanks,
Ming Wen, Apache APISIX & Apache SkyWalking
Twitter: _WenMing
wei jin <kv...@apache.org> 于2020年11月1日周日 下午12:52写道：
> +1 agree
> LGTM
>
> Yuelin Zheng <zy...@163.com> 于2020年11月1日周日 上午12:00写道：
>
> > Hi, Community,
> >
> >
> > I have implemented a plug-in related to traffic split, and I want to add
> > the plug-in to apisix. The following is the main information of the
> plugin:
> >
> >
> > 1. Background
> >
> >
> > After seeing this issue about traffic split plugin #2303(
> > https://github.com/apache/apisix/issues/2303), I think this function is
> > very useful, it can effectively realize the flow control function.
> > Therefore, this inspired me to implement a dynamic upstream plugin.
> >
> >
> > 2. Why do this
> > For details, please see: https://github.com/apache/apisix/issues/2303
> > Traffic split means that requests need to comply with certain rules in
> > order to reach the designated upstream or a certain node in the upstream.
> > Through this function, gray release, blue-green release and custom
> routing
> > are realized, which is very useful for reducing downtime in the event of
> a
> > failure.
> >
> >
> > 3. Design
> > The dynamic upstream plug-in is mainly composed of two parts `match` and
> > `upstreams` to implement the rules of the plugin. `match` is the matching
> > rule of the plugin (the currently supported operations are: ==, ~=, ~~,
> >,
> > >=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
> > `upstreams` rule in the plugin be reached, otherwise the default upstream
> > is reached. In the `upstreams` rule, `upstream` is the configuration of
> the
> > plugin upstream, and the `weight` field is the basis for traffic
> > segmentation between upstream services (using the roundrobin algorithm).
> >
> >
> > note:
> > ```
> > {
> > "Weight": 1
> > }
> > ```
> > When the plug-in upstream configuration has only the weight field, it
> > means the default upstream traffic ratio.
> >
> >
> > Example:
> >
> >
> > Grayscale release:
> > The traffic is split according to the weight field value configured in
> the
> > upstreams part of the plug-in.
> > If `match` is not configured, match is passed by default. Divide the
> > request traffic by 4:1, 4/5 of the traffic hits the upstream of the
> plugin
> > port of `1981`, and 1/5 of the traffic hits the default upstream of the
> > `1980` port.
> >
> >
> > ```
> > "plugins": {
> > "dynamic-upstream": {
> > "rules": [
> > {
> > "upstreams": [
> > {
> > "upstream": {
> > "name": "upstream_A",
> > "type": "roundrobin",
> > "nodes": {
> > "127.0.0.1:1981":10
> > }
> > },
> > "weight": 4
> > },
> > {
> >
> > "weight": 1
> > }
> >
> > ]
> > }
> > ]
> > }
> > },
> > "upstream": {
> > "type": "roundrobin",
> > "nodes": {
> > "127.0.0.1:1980": 1
> > }
> > }
> > ```
> >
> >
> > Blue-green release:
> > All requests hit the upstrean configured by the plugin (when weight is 0,
> > the corresponding upstream is invalid).
> >
> >
> > ```
> > "plugins": {
> > "dynamic-upstream": {
> > "rules": [
> > {
> > "match": [
> > {
> > "vars": [
> > [ "http_new-release","==","blue" ]
> > ]
> > }
> > ],
> > "upstreams": [
> > {
> > "upstream": {
> > "name": "upstream_A",
> > "type": "roundrobin",
> > "nodes": {
> > "127.0.0.1:1981":10
> > }
> > },
> > "weight": 1
> > },
> > {
> >
> > "weight": 0
> > }
> >
> > ]
> > }
> > ]
> > }
> > },
> > "upstream": {
> > "type": "roundrobin",
> > "nodes": {
> > "127.0.0.1:1980": 1
> > }
> > }
> > ```
> >
> >
> > Custom release:
> > There are multiple conditions in vars, and the relationship between them
> > is `add`. Multiple vars can be configured, then they have an `or`
> > relationship.
> > After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
> > the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
> > traffic hits the default upstream of the `1980` port.
> >
> >
> > ```
> > "plugins": {
> > "dynamic-upstream": {
> > "rules": [
> > {
> > "match": [
> > {
> > "vars": [
> > [ "arg_name","==","jack" ],
> > [ "http_user-id",">=","23" ],
> > [ "http_apisix-key","~~","[a-z]+" ]
> > ]
> > }
> > ],
> > "upstreams": [
> > {
> > "upstream": {
> > "name": "upstream_A",
> > "type": "roundrobin",
> > "nodes": {
> > "127.0.0.1:1981":10
> > }
> > },
> > "weight": 4
> > },
> > {
> >
> > “weight”: 2
> >
> > }
> >
> > ]
> > }
> > ]
> > }
> > },
> > "upstream": {
> > "type": "roundrobin",
> > "nodes": {
> > "127.0.0.1:1980": 1
> > }
> > }
> > ```
> >
> >
> > Note: The vars parameter here can be obtained from the http request
> > header, querystring or nginx variable.
> > The above is a brief introduction to the dynamic upstream plugin.
> >
> >
> > I want to add this plugin to the apisix project, what do you think?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
Re: Proposal: add the traffic split plugin to apisix
Posted by wei jin <kv...@apache.org>.
+1 agree
LGTM
Yuelin Zheng <zy...@163.com> 于2020年11月1日周日 上午12:00写道：
> Hi, Community,
>
>
> I have implemented a plug-in related to traffic split, and I want to add
> the plug-in to apisix. The following is the main information of the plugin:
>
>
> 1. Background
>
>
> After seeing this issue about traffic split plugin #2303(
> https://github.com/apache/apisix/issues/2303), I think this function is
> very useful, it can effectively realize the flow control function.
> Therefore, this inspired me to implement a dynamic upstream plugin.
>
>
> 2. Why do this
> For details, please see: https://github.com/apache/apisix/issues/2303
> Traffic split means that requests need to comply with certain rules in
> order to reach the designated upstream or a certain node in the upstream.
> Through this function, gray release, blue-green release and custom routing
> are realized, which is very useful for reducing downtime in the event of a
> failure.
>
>
> 3. Design
> The dynamic upstream plug-in is mainly composed of two parts `match` and
> `upstreams` to implement the rules of the plugin. `match` is the matching
> rule of the plugin (the currently supported operations are: ==, ~=, ~~, >,
> >=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
> `upstreams` rule in the plugin be reached, otherwise the default upstream
> is reached. In the `upstreams` rule, `upstream` is the configuration of the
> plugin upstream, and the `weight` field is the basis for traffic
> segmentation between upstream services (using the roundrobin algorithm).
>
>
> note:
> ```
> {
> "Weight": 1
> }
> ```
> When the plug-in upstream configuration has only the weight field, it
> means the default upstream traffic ratio.
>
>
> Example:
>
>
> Grayscale release:
> The traffic is split according to the weight field value configured in the
> upstreams part of the plug-in.
> If `match` is not configured, match is passed by default. Divide the
> request traffic by 4:1, 4/5 of the traffic hits the upstream of the plugin
> port of `1981`, and 1/5 of the traffic hits the default upstream of the
> `1980` port.
>
>
> ```
> "plugins": {
> "dynamic-upstream": {
> "rules": [
> {
> "upstreams": [
> {
> "upstream": {
> "name": "upstream_A",
> "type": "roundrobin",
> "nodes": {
> "127.0.0.1:1981":10
> }
> },
> "weight": 4
> },
> {
>
> "weight": 1
> }
>
> ]
> }
> ]
> }
> },
> "upstream": {
> "type": "roundrobin",
> "nodes": {
> "127.0.0.1:1980": 1
> }
> }
> ```
>
>
> Blue-green release:
> All requests hit the upstrean configured by the plugin (when weight is 0,
> the corresponding upstream is invalid).
>
>
> ```
> "plugins": {
> "dynamic-upstream": {
> "rules": [
> {
> "match": [
> {
> "vars": [
> [ "http_new-release","==","blue" ]
> ]
> }
> ],
> "upstreams": [
> {
> "upstream": {
> "name": "upstream_A",
> "type": "roundrobin",
> "nodes": {
> "127.0.0.1:1981":10
> }
> },
> "weight": 1
> },
> {
>
> "weight": 0
> }
>
> ]
> }
> ]
> }
> },
> "upstream": {
> "type": "roundrobin",
> "nodes": {
> "127.0.0.1:1980": 1
> }
> }
> ```
>
>
> Custom release:
> There are multiple conditions in vars, and the relationship between them
> is `add`. Multiple vars can be configured, then they have an `or`
> relationship.
> After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
> the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
> traffic hits the default upstream of the `1980` port.
>
>
> ```
> "plugins": {
> "dynamic-upstream": {
> "rules": [
> {
> "match": [
> {
> "vars": [
> [ "arg_name","==","jack" ],
> [ "http_user-id",">=","23" ],
> [ "http_apisix-key","~~","[a-z]+" ]
> ]
> }
> ],
> "upstreams": [
> {
> "upstream": {
> "name": "upstream_A",
> "type": "roundrobin",
> "nodes": {
> "127.0.0.1:1981":10
> }
> },
> "weight": 4
> },
> {
>
> “weight”: 2
>
> }
>
> ]
> }
> ]
> }
> },
> "upstream": {
> "type": "roundrobin",
> "nodes": {
> "127.0.0.1:1980": 1
> }
> }
> ```
>
>
> Note: The vars parameter here can be obtained from the http request
> header, querystring or nginx variable.
> The above is a brief introduction to the dynamic upstream plugin.
>
>
> I want to add this plugin to the apisix project, what do you think?
>
>
>
>
>
>
>
>
>
>
>
Re: Re: Proposal: add the traffic split plugin to apisix
Posted by YuanSheng Wang <me...@apache.org>.
Let me talk about an example of API grayscale.
One API is described by one Route in APISIX.
After it is created, a Route will have a default Upstream.
When the user enables API grayscale, the user needs to forward part of the
API traffic to a
specific upstream, such as using the source IP address, specific request
parameters, etc.
Users do not want to create multiple Route objects, because this is one
API, not multiple.
To support this case, it is necessary to support conditions when selecting
upstream objects.
On Fri, Nov 6, 2020 at 10:36 AM Zhang Chao <zc...@gmail.com> wrote:
> Hi!
>
> It depends on the document description and whether people can find the docs
> easily rather than the way we implement feature. That’s not a convincing
> reason IMHO.
>
> On November 3, 2020 at 9:44:34 PM, Yuelin Zheng (zyl1812@163.com) wrote:
>
> I think plugin implementation is also a good way. If implemented through
> existing routing rules,
> it is difficult for people who are not familiar with apisix to find this
> feature.
>
>
>
>
>
> At 2020-11-01 16:07:21, "Zhang Chao" <zc...@gmail.com> wrote:
> > Hi!
> >
> >Actually we already have a discuss about this feature in this mailing
> list,
> >see
> >
>
> https://lists.apache.org/thread.html/r9222f87b69bbb8cf9dce1f5e920adb6aede38f4c24bc1b0dac07b53f%40%3Cdev.apisix.apache.org%3E
> >for
> >the details.
> >
> >From my point of view, it’s better to implement the first class support of
> >traffic split/shift by APISIX instead of by a plugin, since the match part
> >is highly consistent with Route, and Route already handles the related
> >logics like health check, service discovery around Upstream well. On the
> >contrary, introducing another Plugin which references to Upstream need to
> >consider these problems once again.
> >
> >So what about considering the way in the above mentioned link? :)
> >
> >On November 1, 2020 at 12:00:47 AM, Yuelin Zheng (zyl1812@163.com) wrote:
> >
> >Hi, Community,
> >
> >
> >I have implemented a plug-in related to traffic split, and I want to add
> >the plug-in to apisix. The following is the main information of the
> plugin:
> >
> >
> >1. Background
> >
> >
> >After seeing this issue about traffic split plugin #2303(
> >https://github.com/apache/apisix/issues/2303), I think this function is
> >very useful, it can effectively realize the flow control function.
> >Therefore, this inspired me to implement a dynamic upstream plugin.
> >
> >
> >2. Why do this
> >For details, please see: https://github.com/apache/apisix/issues/2303
> >Traffic split means that requests need to comply with certain rules in
> >order to reach the designated upstream or a certain node in the upstream.
> >Through this function, gray release, blue-green release and custom routing
> >are realized, which is very useful for reducing downtime in the event of a
> >failure.
> >
> >
> >3. Design
> >The dynamic upstream plug-in is mainly composed of two parts `match` and
> >`upstreams` to implement the rules of the plugin. `match` is the matching
> >rule of the plugin (the currently supported operations are: ==, ~=, ~~, >,
> >>=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
> >`upstreams` rule in the plugin be reached, otherwise the default upstream
> >is reached. In the `upstreams` rule, `upstream` is the configuration of
> the
> >plugin upstream, and the `weight` field is the basis for traffic
> >segmentation between upstream services (using the roundrobin algorithm).
> >
> >
> >note:
> >```
> >{
> >"Weight": 1
> >}
> >```
> >When the plug-in upstream configuration has only the weight field, it
> means
> >the default upstream traffic ratio.
> >
> >
> >Example:
> >
> >
> >Grayscale release:
> >The traffic is split according to the weight field value configured in the
> >upstreams part of the plug-in.
> >If `match` is not configured, match is passed by default. Divide the
> >request traffic by 4:1, 4/5 of the traffic hits the upstream of the plugin
> >port of `1981`, and 1/5 of the traffic hits the default upstream of the
> >`1980` port.
> >
> >
> >```
> >"plugins": {
> >"dynamic-upstream": {
> >"rules": [
> >{
> >"upstreams": [
> >{
> >"upstream": {
> >"name": "upstream_A",
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1981":10
> >}
> >},
> >"weight": 4
> >},
> >{
> >
> >"weight": 1
> >}
> >
> >]
> >}
> >]
> >}
> >},
> >"upstream": {
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1980": 1
> >}
> >}
> >```
> >
> >
> >Blue-green release:
> >All requests hit the upstrean configured by the plugin (when weight is 0,
> >the corresponding upstream is invalid).
> >
> >
> >```
> >"plugins": {
> >"dynamic-upstream": {
> >"rules": [
> >{
> >"match": [
> >{
> >"vars": [
> >[ "http_new-release","==","blue" ]
> >]
> >}
> >],
> >"upstreams": [
> >{
> >"upstream": {
> >"name": "upstream_A",
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1981":10
> >}
> >},
> >"weight": 1
> >},
> >{
> >
> >"weight": 0
> >}
> >
> >]
> >}
> >]
> >}
> >},
> >"upstream": {
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1980": 1
> >}
> >}
> >```
> >
> >
> >Custom release:
> >There are multiple conditions in vars, and the relationship between them
> is
> >`add`. Multiple vars can be configured, then they have an `or`
> relationship.
> >After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
> >the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
> >traffic hits the default upstream of the `1980` port.
> >
> >
> >```
> >"plugins": {
> >"dynamic-upstream": {
> >"rules": [
> >{
> >"match": [
> >{
> >"vars": [
> >[ "arg_name","==","jack" ],
> >[ "http_user-id",">=","23" ],
> >[ "http_apisix-key","~~","[a-z]+" ]
> >]
> >}
> >],
> >"upstreams": [
> >{
> >"upstream": {
> >"name": "upstream_A",
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1981":10
> >}
> >},
> >"weight": 4
> >},
> >{
> >
> >“weight”: 2
> >
> >}
> >
> >]
> >}
> >]
> >}
> >},
> >"upstream": {
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1980": 1
> >}
> >}
> >```
> >
> >
> >Note: The vars parameter here can be obtained from the http request
> header,
> >querystring or nginx variable.
> >The above is a brief introduction to the dynamic upstream plugin.
> >
> >
> >I want to add this plugin to the apisix project, what do you think?
>
--
*MembPhis*
My GitHub: https://github.com/membphis
Apache APISIX: https://github.com/apache/apisix
Re: Re:Re: Proposal: add the traffic split plugin to apisix
Posted by Chao Zhang <zc...@gmail.com>.
1. The execution process of traffic shift can be understood as these
components: route (data structure) -> traffic shift (algorithm) ->
upstream(s) (data structure).The traffic shift (algorithm) will change
according to the business, and the logic that is prone to change is more
suitable for implementation through plugins.
That’s true, you convinced me. But some advanced features, like label based
endpoint selector is still need the help of the core logic, what the plugin
can do is like preparing the necessary parameters for the core logic to run
as per it’s settings. So if we implements the traffic split plug-in, a
generic, flexible core interface for upstream selection is required (e.g.
accepts label set and filter them, which can be chained with load balancer
and health check).
Re:Re: Re:Re: Proposal: add the traffic split plugin to apisix
Posted by Yuelin Zheng <zy...@163.com>.
Your point is very good. The main matching logic of the plug-in and the realization of vars logic are regarded as public. I think the upstream health check can be achieved through the upstream_id method, and the existing functions of apisix can be reused to implement this plugin.
At 2020-11-15 15:08:16, "wei jin" <kv...@apache.org> wrote:
>I think it is more appropriate to achieve traffic shift through plug-ins.
>
>There are several reasons:
>1. The execution process of traffic shift can be understood as these
>components: route (data structure) -> traffic shift (algorithm) ->
>upstream(s) (data structure).The traffic shift (algorithm) will change
>according to the business, and the logic that is prone to change is more
>suitable for implementation through plugins.
>2.APISIX provides plug-in expansion capabilities, and does not affect the
>core logic of the gateway, the impact of the upgrade is small;
>3.We cannot guarantee that the traffic shift capabilities implemented by
>the community will meet all business scenarios. If we implement it in the
>routing logic, the new needs of users will be limited by the release of
>APISIX.
>4.Benefiting from the plug-in's implementation stage and priority
>capabilities, it will also bring more flexible combination capabilities,
>which we can use in combination with other plug-ins; but it will not work
>if we implement it in the routing logic.
>e.g. There are some parameter rewriting capabilities in the gateway's
>capabilities, and some user scenarios need to modify the parameters first,
>and use the modified parameters as the input parameters for flow control.
>5.There is nothing wrong with implementing flow control through plug-ins,
>and the efficiency is the same as that implemented in the route core code.
>
>
>I proposal:
>1. Use plug-ins to achieve traffic shift.
>2. According to the different needs of users, continuously improve the
>plug-in, and gradually turn this plug-in into a community standard
>implementation.
>3. We can extract APISIX’s match logic and vars logic as public
>implementations.
>
>Chao Zhang <zc...@gmail.com> 于2020年11月7日周六 下午4:30写道：
>
>> Hi!
>>
>> Why we need to implement a feature duplicately? I think you can post your
>> idea about this feature to Community firstly :)
>>
>> Chao Zhang
>> https://github.com/tokers
>>
>> On November 7, 2020 at 11:55:33 AM, Yuelin Zheng (zyl1812@163.com) wrote:
>>
>> Hi,Zhang Chao,
>>
>>
>> Agree with your point of view. But we can go to implement the plug-in
>> method, so that there is another way of `traffic split`. Allow users to
>> choose their own preferred method. What do you think?
>>
>> At 2020-11-06 10:35:58, "Zhang Chao" <zc...@gmail.com> wrote:
>> >Hi!
>> >
>> >It depends on the document description and whether people can find the
>> docs
>> >easily rather than the way we implement feature. That’s not a convincing
>> >reason IMHO.
>> >
>> >On November 3, 2020 at 9:44:34 PM, Yuelin Zheng (zyl1812@163.com) wrote:
>> >
>> >I think plugin implementation is also a good way. If implemented through
>> >existing routing rules,
>> >it is difficult for people who are not familiar with apisix to find this
>> >feature.
>> >
>> >
>> >
>> >
>> >
>> >At 2020-11-01 16:07:21, "Zhang Chao" <zc...@gmail.com> wrote:
>> >> Hi!
>> >>
>> >>Actually we already have a discuss about this feature in this mailing
>> list,
>> >>see
>> >>
>> >
>>
>> https://lists.apache.org/thread.html/r9222f87b69bbb8cf9dce1f5e920adb6aede38f4c24bc1b0dac07b53f%40%3Cdev.apisix.apache.org%3E
>> >>for
>> >>the details.
>> >>
>> >>From my point of view, it’s better to implement the first class support
>> of
>> >>traffic split/shift by APISIX instead of by a plugin, since the match
>> part
>> >>is highly consistent with Route, and Route already handles the related
>> >>logics like health check, service discovery around Upstream well. On the
>> >>contrary, introducing another Plugin which references to Upstream need to
>> >>consider these problems once again.
>> >>
>> >>So what about considering the way in the above mentioned link? :)
>> >>
>> >>On November 1, 2020 at 12:00:47 AM, Yuelin Zheng (zyl1812@163.com)
>> wrote:
>> >>
>> >>Hi, Community,
>> >>
>> >>
>> >>I have implemented a plug-in related to traffic split, and I want to add
>> >>the plug-in to apisix. The following is the main information of the
>> plugin:
>> >>
>> >>
>> >>1. Background
>> >>
>> >>
>> >>After seeing this issue about traffic split plugin #2303(
>> >>https://github.com/apache/apisix/issues/2303), I think this function is
>> >>very useful, it can effectively realize the flow control function.
>> >>Therefore, this inspired me to implement a dynamic upstream plugin.
>> >>
>> >>
>> >>2. Why do this
>> >>For details, please see: https://github.com/apache/apisix/issues/2303
>> >>Traffic split means that requests need to comply with certain rules in
>> >>order to reach the designated upstream or a certain node in the upstream.
>> >>Through this function, gray release, blue-green release and custom
>> routing
>> >>are realized, which is very useful for reducing downtime in the event of
>> a
>> >>failure.
>> >>
>> >>
>> >>3. Design
>> >>The dynamic upstream plug-in is mainly composed of two parts `match` and
>> >>`upstreams` to implement the rules of the plugin. `match` is the matching
>> >>rule of the plugin (the currently supported operations are: ==, ~=, ~~,
>> >,
>> >>>=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
>> >>`upstreams` rule in the plugin be reached, otherwise the default upstream
>> >>is reached. In the `upstreams` rule, `upstream` is the configuration of
>> the
>> >>plugin upstream, and the `weight` field is the basis for traffic
>> >>segmentation between upstream services (using the roundrobin algorithm).
>> >>
>> >>
>> >>note:
>> >>```
>> >>{
>> >>"Weight": 1
>> >>}
>> >>```
>> >>When the plug-in upstream configuration has only the weight field, it
>> means
>> >>the default upstream traffic ratio.
>> >>
>> >>
>> >>Example:
>> >>
>> >>
>> >>Grayscale release:
>> >>The traffic is split according to the weight field value configured in
>> the
>> >>upstreams part of the plug-in.
>> >>If `match` is not configured, match is passed by default. Divide the
>> >>request traffic by 4:1, 4/5 of the traffic hits the upstream of the
>> plugin
>> >>port of `1981`, and 1/5 of the traffic hits the default upstream of the
>> >>`1980` port.
>> >>
>> >>
>> >>```
>> >>"plugins": {
>> >>"dynamic-upstream": {
>> >>"rules": [
>> >>{
>> >>"upstreams": [
>> >>{
>> >>"upstream": {
>> >>"name": "upstream_A",
>> >>"type": "roundrobin",
>> >>"nodes": {
>> >>"127.0.0.1:1981":10
>> >>}
>> >>},
>> >>"weight": 4
>> >>},
>> >>{
>> >>
>> >>"weight": 1
>> >>}
>> >>
>> >>]
>> >>}
>> >>]
>> >>}
>> >>},
>> >>"upstream": {
>> >>"type": "roundrobin",
>> >>"nodes": {
>> >>"127.0.0.1:1980": 1
>> >>}
>> >>}
>> >>```
>> >>
>> >>
>> >>Blue-green release:
>> >>All requests hit the upstrean configured by the plugin (when weight is 0,
>> >>the corresponding upstream is invalid).
>> >>
>> >>
>> >>```
>> >>"plugins": {
>> >>"dynamic-upstream": {
>> >>"rules": [
>> >>{
>> >>"match": [
>> >>{
>> >>"vars": [
>> >>[ "http_new-release","==","blue" ]
>> >>]
>> >>}
>> >>],
>> >>"upstreams": [
>> >>{
>> >>"upstream": {
>> >>"name": "upstream_A",
>> >>"type": "roundrobin",
>> >>"nodes": {
>> >>"127.0.0.1:1981":10
>> >>}
>> >>},
>> >>"weight": 1
>> >>},
>> >>{
>> >>
>> >>"weight": 0
>> >>}
>> >>
>> >>]
>> >>}
>> >>]
>> >>}
>> >>},
>> >>"upstream": {
>> >>"type": "roundrobin",
>> >>"nodes": {
>> >>"127.0.0.1:1980": 1
>> >>}
>> >>}
>> >>```
>> >>
>> >>
>> >>Custom release:
>> >>There are multiple conditions in vars, and the relationship between them
>> is
>> >>`add`. Multiple vars can be configured, then they have an `or`
>> >relationship.
>> >>After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
>> >>the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
>> >>traffic hits the default upstream of the `1980` port.
>> >>
>> >>
>> >>```
>> >>"plugins": {
>> >>"dynamic-upstream": {
>> >>"rules": [
>> >>{
>> >>"match": [
>> >>{
>> >>"vars": [
>> >>[ "arg_name","==","jack" ],
>> >>[ "http_user-id",">=","23" ],
>> >>[ "http_apisix-key","~~","[a-z]+" ]
>> >>]
>> >>}
>> >>],
>> >>"upstreams": [
>> >>{
>> >>"upstream": {
>> >>"name": "upstream_A",
>> >>"type": "roundrobin",
>> >>"nodes": {
>> >>"127.0.0.1:1981":10
>> >>}
>> >>},
>> >>"weight": 4
>> >>},
>> >>{
>> >>
>> >>“weight”: 2
>> >>
>> >>}
>> >>
>> >>]
>> >>}
>> >>]
>> >>}
>> >>},
>> >>"upstream": {
>> >>"type": "roundrobin",
>> >>"nodes": {
>> >>"127.0.0.1:1980": 1
>> >>}
>> >>}
>> >>```
>> >>
>> >>
>> >>Note: The vars parameter here can be obtained from the http request
>> header,
>> >>querystring or nginx variable.
>> >>The above is a brief introduction to the dynamic upstream plugin.
>> >>
>> >>
>> >>I want to add this plugin to the apisix project, what do you think?
>>
Re: Re:Re: Proposal: add the traffic split plugin to apisix
Posted by wei jin <kv...@apache.org>.
I think it is more appropriate to achieve traffic shift through plug-ins.
There are several reasons:
1. The execution process of traffic shift can be understood as these
components: route (data structure) -> traffic shift (algorithm) ->
upstream(s) (data structure).The traffic shift (algorithm) will change
according to the business, and the logic that is prone to change is more
suitable for implementation through plugins.
2.APISIX provides plug-in expansion capabilities, and does not affect the
core logic of the gateway, the impact of the upgrade is small;
3.We cannot guarantee that the traffic shift capabilities implemented by
the community will meet all business scenarios. If we implement it in the
routing logic, the new needs of users will be limited by the release of
APISIX.
4.Benefiting from the plug-in's implementation stage and priority
capabilities, it will also bring more flexible combination capabilities,
which we can use in combination with other plug-ins; but it will not work
if we implement it in the routing logic.
e.g. There are some parameter rewriting capabilities in the gateway's
capabilities, and some user scenarios need to modify the parameters first,
and use the modified parameters as the input parameters for flow control.
5.There is nothing wrong with implementing flow control through plug-ins,
and the efficiency is the same as that implemented in the route core code.
I proposal:
1. Use plug-ins to achieve traffic shift.
2. According to the different needs of users, continuously improve the
plug-in, and gradually turn this plug-in into a community standard
implementation.
3. We can extract APISIX’s match logic and vars logic as public
implementations.
Chao Zhang <zc...@gmail.com> 于2020年11月7日周六 下午4:30写道：
> Hi!
>
> Why we need to implement a feature duplicately? I think you can post your
> idea about this feature to Community firstly :)
>
> Chao Zhang
> https://github.com/tokers
>
> On November 7, 2020 at 11:55:33 AM, Yuelin Zheng (zyl1812@163.com) wrote:
>
> Hi,Zhang Chao,
>
>
> Agree with your point of view. But we can go to implement the plug-in
> method, so that there is another way of `traffic split`. Allow users to
> choose their own preferred method. What do you think?
>
> At 2020-11-06 10:35:58, "Zhang Chao" <zc...@gmail.com> wrote:
> >Hi!
> >
> >It depends on the document description and whether people can find the
> docs
> >easily rather than the way we implement feature. That’s not a convincing
> >reason IMHO.
> >
> >On November 3, 2020 at 9:44:34 PM, Yuelin Zheng (zyl1812@163.com) wrote:
> >
> >I think plugin implementation is also a good way. If implemented through
> >existing routing rules,
> >it is difficult for people who are not familiar with apisix to find this
> >feature.
> >
> >
> >
> >
> >
> >At 2020-11-01 16:07:21, "Zhang Chao" <zc...@gmail.com> wrote:
> >> Hi!
> >>
> >>Actually we already have a discuss about this feature in this mailing
> list,
> >>see
> >>
> >
>
> https://lists.apache.org/thread.html/r9222f87b69bbb8cf9dce1f5e920adb6aede38f4c24bc1b0dac07b53f%40%3Cdev.apisix.apache.org%3E
> >>for
> >>the details.
> >>
> >>From my point of view, it’s better to implement the first class support
> of
> >>traffic split/shift by APISIX instead of by a plugin, since the match
> part
> >>is highly consistent with Route, and Route already handles the related
> >>logics like health check, service discovery around Upstream well. On the
> >>contrary, introducing another Plugin which references to Upstream need to
> >>consider these problems once again.
> >>
> >>So what about considering the way in the above mentioned link? :)
> >>
> >>On November 1, 2020 at 12:00:47 AM, Yuelin Zheng (zyl1812@163.com)
> wrote:
> >>
> >>Hi, Community,
> >>
> >>
> >>I have implemented a plug-in related to traffic split, and I want to add
> >>the plug-in to apisix. The following is the main information of the
> plugin:
> >>
> >>
> >>1. Background
> >>
> >>
> >>After seeing this issue about traffic split plugin #2303(
> >>https://github.com/apache/apisix/issues/2303), I think this function is
> >>very useful, it can effectively realize the flow control function.
> >>Therefore, this inspired me to implement a dynamic upstream plugin.
> >>
> >>
> >>2. Why do this
> >>For details, please see: https://github.com/apache/apisix/issues/2303
> >>Traffic split means that requests need to comply with certain rules in
> >>order to reach the designated upstream or a certain node in the upstream.
> >>Through this function, gray release, blue-green release and custom
> routing
> >>are realized, which is very useful for reducing downtime in the event of
> a
> >>failure.
> >>
> >>
> >>3. Design
> >>The dynamic upstream plug-in is mainly composed of two parts `match` and
> >>`upstreams` to implement the rules of the plugin. `match` is the matching
> >>rule of the plugin (the currently supported operations are: ==, ~=, ~~,
> >,
> >>>=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
> >>`upstreams` rule in the plugin be reached, otherwise the default upstream
> >>is reached. In the `upstreams` rule, `upstream` is the configuration of
> the
> >>plugin upstream, and the `weight` field is the basis for traffic
> >>segmentation between upstream services (using the roundrobin algorithm).
> >>
> >>
> >>note:
> >>```
> >>{
> >>"Weight": 1
> >>}
> >>```
> >>When the plug-in upstream configuration has only the weight field, it
> means
> >>the default upstream traffic ratio.
> >>
> >>
> >>Example:
> >>
> >>
> >>Grayscale release:
> >>The traffic is split according to the weight field value configured in
> the
> >>upstreams part of the plug-in.
> >>If `match` is not configured, match is passed by default. Divide the
> >>request traffic by 4:1, 4/5 of the traffic hits the upstream of the
> plugin
> >>port of `1981`, and 1/5 of the traffic hits the default upstream of the
> >>`1980` port.
> >>
> >>
> >>```
> >>"plugins": {
> >>"dynamic-upstream": {
> >>"rules": [
> >>{
> >>"upstreams": [
> >>{
> >>"upstream": {
> >>"name": "upstream_A",
> >>"type": "roundrobin",
> >>"nodes": {
> >>"127.0.0.1:1981":10
> >>}
> >>},
> >>"weight": 4
> >>},
> >>{
> >>
> >>"weight": 1
> >>}
> >>
> >>]
> >>}
> >>]
> >>}
> >>},
> >>"upstream": {
> >>"type": "roundrobin",
> >>"nodes": {
> >>"127.0.0.1:1980": 1
> >>}
> >>}
> >>```
> >>
> >>
> >>Blue-green release:
> >>All requests hit the upstrean configured by the plugin (when weight is 0,
> >>the corresponding upstream is invalid).
> >>
> >>
> >>```
> >>"plugins": {
> >>"dynamic-upstream": {
> >>"rules": [
> >>{
> >>"match": [
> >>{
> >>"vars": [
> >>[ "http_new-release","==","blue" ]
> >>]
> >>}
> >>],
> >>"upstreams": [
> >>{
> >>"upstream": {
> >>"name": "upstream_A",
> >>"type": "roundrobin",
> >>"nodes": {
> >>"127.0.0.1:1981":10
> >>}
> >>},
> >>"weight": 1
> >>},
> >>{
> >>
> >>"weight": 0
> >>}
> >>
> >>]
> >>}
> >>]
> >>}
> >>},
> >>"upstream": {
> >>"type": "roundrobin",
> >>"nodes": {
> >>"127.0.0.1:1980": 1
> >>}
> >>}
> >>```
> >>
> >>
> >>Custom release:
> >>There are multiple conditions in vars, and the relationship between them
> is
> >>`add`. Multiple vars can be configured, then they have an `or`
> >relationship.
> >>After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
> >>the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
> >>traffic hits the default upstream of the `1980` port.
> >>
> >>
> >>```
> >>"plugins": {
> >>"dynamic-upstream": {
> >>"rules": [
> >>{
> >>"match": [
> >>{
> >>"vars": [
> >>[ "arg_name","==","jack" ],
> >>[ "http_user-id",">=","23" ],
> >>[ "http_apisix-key","~~","[a-z]+" ]
> >>]
> >>}
> >>],
> >>"upstreams": [
> >>{
> >>"upstream": {
> >>"name": "upstream_A",
> >>"type": "roundrobin",
> >>"nodes": {
> >>"127.0.0.1:1981":10
> >>}
> >>},
> >>"weight": 4
> >>},
> >>{
> >>
> >>“weight”: 2
> >>
> >>}
> >>
> >>]
> >>}
> >>]
> >>}
> >>},
> >>"upstream": {
> >>"type": "roundrobin",
> >>"nodes": {
> >>"127.0.0.1:1980": 1
> >>}
> >>}
> >>```
> >>
> >>
> >>Note: The vars parameter here can be obtained from the http request
> header,
> >>querystring or nginx variable.
> >>The above is a brief introduction to the dynamic upstream plugin.
> >>
> >>
> >>I want to add this plugin to the apisix project, what do you think?
>
Re:Re:Re: Proposal: add the traffic split plugin to apisix
Posted by Chao Zhang <zc...@gmail.com>.
Hi!
Why we need to implement a feature duplicately? I think you can post your
idea about this feature to Community firstly :)
Chao Zhang
https://github.com/tokers
On November 7, 2020 at 11:55:33 AM, Yuelin Zheng (zyl1812@163.com) wrote:
Hi,Zhang Chao,
Agree with your point of view. But we can go to implement the plug-in
method, so that there is another way of `traffic split`. Allow users to
choose their own preferred method. What do you think?
At 2020-11-06 10:35:58, "Zhang Chao" <zc...@gmail.com> wrote:
>Hi!
>
>It depends on the document description and whether people can find the docs
>easily rather than the way we implement feature. That’s not a convincing
>reason IMHO.
>
>On November 3, 2020 at 9:44:34 PM, Yuelin Zheng (zyl1812@163.com) wrote:
>
>I think plugin implementation is also a good way. If implemented through
>existing routing rules,
>it is difficult for people who are not familiar with apisix to find this
>feature.
>
>
>
>
>
>At 2020-11-01 16:07:21, "Zhang Chao" <zc...@gmail.com> wrote:
>> Hi!
>>
>>Actually we already have a discuss about this feature in this mailing
list,
>>see
>>
>
https://lists.apache.org/thread.html/r9222f87b69bbb8cf9dce1f5e920adb6aede38f4c24bc1b0dac07b53f%40%3Cdev.apisix.apache.org%3E
>>for
>>the details.
>>
>>From my point of view, it’s better to implement the first class support of
>>traffic split/shift by APISIX instead of by a plugin, since the match part
>>is highly consistent with Route, and Route already handles the related
>>logics like health check, service discovery around Upstream well. On the
>>contrary, introducing another Plugin which references to Upstream need to
>>consider these problems once again.
>>
>>So what about considering the way in the above mentioned link? :)
>>
>>On November 1, 2020 at 12:00:47 AM, Yuelin Zheng (zyl1812@163.com) wrote:
>>
>>Hi, Community,
>>
>>
>>I have implemented a plug-in related to traffic split, and I want to add
>>the plug-in to apisix. The following is the main information of the
plugin:
>>
>>
>>1. Background
>>
>>
>>After seeing this issue about traffic split plugin #2303(
>>https://github.com/apache/apisix/issues/2303), I think this function is
>>very useful, it can effectively realize the flow control function.
>>Therefore, this inspired me to implement a dynamic upstream plugin.
>>
>>
>>2. Why do this
>>For details, please see: https://github.com/apache/apisix/issues/2303
>>Traffic split means that requests need to comply with certain rules in
>>order to reach the designated upstream or a certain node in the upstream.
>>Through this function, gray release, blue-green release and custom routing
>>are realized, which is very useful for reducing downtime in the event of a
>>failure.
>>
>>
>>3. Design
>>The dynamic upstream plug-in is mainly composed of two parts `match` and
>>`upstreams` to implement the rules of the plugin. `match` is the matching
>>rule of the plugin (the currently supported operations are: ==, ~=, ~~, >,
>>>=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
>>`upstreams` rule in the plugin be reached, otherwise the default upstream
>>is reached. In the `upstreams` rule, `upstream` is the configuration of
the
>>plugin upstream, and the `weight` field is the basis for traffic
>>segmentation between upstream services (using the roundrobin algorithm).
>>
>>
>>note:
>>```
>>{
>>"Weight": 1
>>}
>>```
>>When the plug-in upstream configuration has only the weight field, it
means
>>the default upstream traffic ratio.
>>
>>
>>Example:
>>
>>
>>Grayscale release:
>>The traffic is split according to the weight field value configured in the
>>upstreams part of the plug-in.
>>If `match` is not configured, match is passed by default. Divide the
>>request traffic by 4:1, 4/5 of the traffic hits the upstream of the plugin
>>port of `1981`, and 1/5 of the traffic hits the default upstream of the
>>`1980` port.
>>
>>
>>```
>>"plugins": {
>>"dynamic-upstream": {
>>"rules": [
>>{
>>"upstreams": [
>>{
>>"upstream": {
>>"name": "upstream_A",
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1981":10
>>}
>>},
>>"weight": 4
>>},
>>{
>>
>>"weight": 1
>>}
>>
>>]
>>}
>>]
>>}
>>},
>>"upstream": {
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1980": 1
>>}
>>}
>>```
>>
>>
>>Blue-green release:
>>All requests hit the upstrean configured by the plugin (when weight is 0,
>>the corresponding upstream is invalid).
>>
>>
>>```
>>"plugins": {
>>"dynamic-upstream": {
>>"rules": [
>>{
>>"match": [
>>{
>>"vars": [
>>[ "http_new-release","==","blue" ]
>>]
>>}
>>],
>>"upstreams": [
>>{
>>"upstream": {
>>"name": "upstream_A",
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1981":10
>>}
>>},
>>"weight": 1
>>},
>>{
>>
>>"weight": 0
>>}
>>
>>]
>>}
>>]
>>}
>>},
>>"upstream": {
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1980": 1
>>}
>>}
>>```
>>
>>
>>Custom release:
>>There are multiple conditions in vars, and the relationship between them
is
>>`add`. Multiple vars can be configured, then they have an `or`
>relationship.
>>After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
>>the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
>>traffic hits the default upstream of the `1980` port.
>>
>>
>>```
>>"plugins": {
>>"dynamic-upstream": {
>>"rules": [
>>{
>>"match": [
>>{
>>"vars": [
>>[ "arg_name","==","jack" ],
>>[ "http_user-id",">=","23" ],
>>[ "http_apisix-key","~~","[a-z]+" ]
>>]
>>}
>>],
>>"upstreams": [
>>{
>>"upstream": {
>>"name": "upstream_A",
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1981":10
>>}
>>},
>>"weight": 4
>>},
>>{
>>
>>“weight”: 2
>>
>>}
>>
>>]
>>}
>>]
>>}
>>},
>>"upstream": {
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1980": 1
>>}
>>}
>>```
>>
>>
>>Note: The vars parameter here can be obtained from the http request
header,
>>querystring or nginx variable.
>>The above is a brief introduction to the dynamic upstream plugin.
>>
>>
>>I want to add this plugin to the apisix project, what do you think?
Re:Re:Re: Proposal: add the traffic split plugin to apisix
Posted by Yuelin Zheng <zy...@163.com>.
Hi,Zhang Chao,
Agree with your point of view. But we can go to implement the plug-in method, so that there is another way of `traffic split`. Allow users to choose their own preferred method. What do you think?
At 2020-11-06 10:35:58, "Zhang Chao" <zc...@gmail.com> wrote:
>Hi!
>
>It depends on the document description and whether people can find the docs
>easily rather than the way we implement feature. That’s not a convincing
>reason IMHO.
>
>On November 3, 2020 at 9:44:34 PM, Yuelin Zheng (zyl1812@163.com) wrote:
>
>I think plugin implementation is also a good way. If implemented through
>existing routing rules,
>it is difficult for people who are not familiar with apisix to find this
>feature.
>
>
>
>
>
>At 2020-11-01 16:07:21, "Zhang Chao" <zc...@gmail.com> wrote:
>> Hi!
>>
>>Actually we already have a discuss about this feature in this mailing list,
>>see
>>
>https://lists.apache.org/thread.html/r9222f87b69bbb8cf9dce1f5e920adb6aede38f4c24bc1b0dac07b53f%40%3Cdev.apisix.apache.org%3E
>>for
>>the details.
>>
>>From my point of view, it’s better to implement the first class support of
>>traffic split/shift by APISIX instead of by a plugin, since the match part
>>is highly consistent with Route, and Route already handles the related
>>logics like health check, service discovery around Upstream well. On the
>>contrary, introducing another Plugin which references to Upstream need to
>>consider these problems once again.
>>
>>So what about considering the way in the above mentioned link? :)
>>
>>On November 1, 2020 at 12:00:47 AM, Yuelin Zheng (zyl1812@163.com) wrote:
>>
>>Hi, Community,
>>
>>
>>I have implemented a plug-in related to traffic split, and I want to add
>>the plug-in to apisix. The following is the main information of the plugin:
>>
>>
>>1. Background
>>
>>
>>After seeing this issue about traffic split plugin #2303(
>>https://github.com/apache/apisix/issues/2303), I think this function is
>>very useful, it can effectively realize the flow control function.
>>Therefore, this inspired me to implement a dynamic upstream plugin.
>>
>>
>>2. Why do this
>>For details, please see: https://github.com/apache/apisix/issues/2303
>>Traffic split means that requests need to comply with certain rules in
>>order to reach the designated upstream or a certain node in the upstream.
>>Through this function, gray release, blue-green release and custom routing
>>are realized, which is very useful for reducing downtime in the event of a
>>failure.
>>
>>
>>3. Design
>>The dynamic upstream plug-in is mainly composed of two parts `match` and
>>`upstreams` to implement the rules of the plugin. `match` is the matching
>>rule of the plugin (the currently supported operations are: ==, ~=, ~~, >,
>>>=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
>>`upstreams` rule in the plugin be reached, otherwise the default upstream
>>is reached. In the `upstreams` rule, `upstream` is the configuration of the
>>plugin upstream, and the `weight` field is the basis for traffic
>>segmentation between upstream services (using the roundrobin algorithm).
>>
>>
>>note:
>>```
>>{
>>"Weight": 1
>>}
>>```
>>When the plug-in upstream configuration has only the weight field, it means
>>the default upstream traffic ratio.
>>
>>
>>Example:
>>
>>
>>Grayscale release:
>>The traffic is split according to the weight field value configured in the
>>upstreams part of the plug-in.
>>If `match` is not configured, match is passed by default. Divide the
>>request traffic by 4:1, 4/5 of the traffic hits the upstream of the plugin
>>port of `1981`, and 1/5 of the traffic hits the default upstream of the
>>`1980` port.
>>
>>
>>```
>>"plugins": {
>>"dynamic-upstream": {
>>"rules": [
>>{
>>"upstreams": [
>>{
>>"upstream": {
>>"name": "upstream_A",
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1981":10
>>}
>>},
>>"weight": 4
>>},
>>{
>>
>>"weight": 1
>>}
>>
>>]
>>}
>>]
>>}
>>},
>>"upstream": {
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1980": 1
>>}
>>}
>>```
>>
>>
>>Blue-green release:
>>All requests hit the upstrean configured by the plugin (when weight is 0,
>>the corresponding upstream is invalid).
>>
>>
>>```
>>"plugins": {
>>"dynamic-upstream": {
>>"rules": [
>>{
>>"match": [
>>{
>>"vars": [
>>[ "http_new-release","==","blue" ]
>>]
>>}
>>],
>>"upstreams": [
>>{
>>"upstream": {
>>"name": "upstream_A",
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1981":10
>>}
>>},
>>"weight": 1
>>},
>>{
>>
>>"weight": 0
>>}
>>
>>]
>>}
>>]
>>}
>>},
>>"upstream": {
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1980": 1
>>}
>>}
>>```
>>
>>
>>Custom release:
>>There are multiple conditions in vars, and the relationship between them is
>>`add`. Multiple vars can be configured, then they have an `or`
>relationship.
>>After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
>>the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
>>traffic hits the default upstream of the `1980` port.
>>
>>
>>```
>>"plugins": {
>>"dynamic-upstream": {
>>"rules": [
>>{
>>"match": [
>>{
>>"vars": [
>>[ "arg_name","==","jack" ],
>>[ "http_user-id",">=","23" ],
>>[ "http_apisix-key","~~","[a-z]+" ]
>>]
>>}
>>],
>>"upstreams": [
>>{
>>"upstream": {
>>"name": "upstream_A",
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1981":10
>>}
>>},
>>"weight": 4
>>},
>>{
>>
>>“weight”: 2
>>
>>}
>>
>>]
>>}
>>]
>>}
>>},
>>"upstream": {
>>"type": "roundrobin",
>>"nodes": {
>>"127.0.0.1:1980": 1
>>}
>>}
>>```
>>
>>
>>Note: The vars parameter here can be obtained from the http request header,
>>querystring or nginx variable.
>>The above is a brief introduction to the dynamic upstream plugin.
>>
>>
>>I want to add this plugin to the apisix project, what do you think?
Re:Re: Proposal: add the traffic split plugin to apisix
Posted by Zhang Chao <zc...@gmail.com>.
Hi!
It depends on the document description and whether people can find the docs
easily rather than the way we implement feature. That’s not a convincing
reason IMHO.
On November 3, 2020 at 9:44:34 PM, Yuelin Zheng (zyl1812@163.com) wrote:
I think plugin implementation is also a good way. If implemented through
existing routing rules,
it is difficult for people who are not familiar with apisix to find this
feature.
At 2020-11-01 16:07:21, "Zhang Chao" <zc...@gmail.com> wrote:
> Hi!
>
>Actually we already have a discuss about this feature in this mailing list,
>see
>
https://lists.apache.org/thread.html/r9222f87b69bbb8cf9dce1f5e920adb6aede38f4c24bc1b0dac07b53f%40%3Cdev.apisix.apache.org%3E
>for
>the details.
>
>From my point of view, it’s better to implement the first class support of
>traffic split/shift by APISIX instead of by a plugin, since the match part
>is highly consistent with Route, and Route already handles the related
>logics like health check, service discovery around Upstream well. On the
>contrary, introducing another Plugin which references to Upstream need to
>consider these problems once again.
>
>So what about considering the way in the above mentioned link? :)
>
>On November 1, 2020 at 12:00:47 AM, Yuelin Zheng (zyl1812@163.com) wrote:
>
>Hi, Community,
>
>
>I have implemented a plug-in related to traffic split, and I want to add
>the plug-in to apisix. The following is the main information of the plugin:
>
>
>1. Background
>
>
>After seeing this issue about traffic split plugin #2303(
>https://github.com/apache/apisix/issues/2303), I think this function is
>very useful, it can effectively realize the flow control function.
>Therefore, this inspired me to implement a dynamic upstream plugin.
>
>
>2. Why do this
>For details, please see: https://github.com/apache/apisix/issues/2303
>Traffic split means that requests need to comply with certain rules in
>order to reach the designated upstream or a certain node in the upstream.
>Through this function, gray release, blue-green release and custom routing
>are realized, which is very useful for reducing downtime in the event of a
>failure.
>
>
>3. Design
>The dynamic upstream plug-in is mainly composed of two parts `match` and
>`upstreams` to implement the rules of the plugin. `match` is the matching
>rule of the plugin (the currently supported operations are: ==, ~=, ~~, >,
>>=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
>`upstreams` rule in the plugin be reached, otherwise the default upstream
>is reached. In the `upstreams` rule, `upstream` is the configuration of the
>plugin upstream, and the `weight` field is the basis for traffic
>segmentation between upstream services (using the roundrobin algorithm).
>
>
>note:
>```
>{
>"Weight": 1
>}
>```
>When the plug-in upstream configuration has only the weight field, it means
>the default upstream traffic ratio.
>
>
>Example:
>
>
>Grayscale release:
>The traffic is split according to the weight field value configured in the
>upstreams part of the plug-in.
>If `match` is not configured, match is passed by default. Divide the
>request traffic by 4:1, 4/5 of the traffic hits the upstream of the plugin
>port of `1981`, and 1/5 of the traffic hits the default upstream of the
>`1980` port.
>
>
>```
>"plugins": {
>"dynamic-upstream": {
>"rules": [
>{
>"upstreams": [
>{
>"upstream": {
>"name": "upstream_A",
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1981":10
>}
>},
>"weight": 4
>},
>{
>
>"weight": 1
>}
>
>]
>}
>]
>}
>},
>"upstream": {
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1980": 1
>}
>}
>```
>
>
>Blue-green release:
>All requests hit the upstrean configured by the plugin (when weight is 0,
>the corresponding upstream is invalid).
>
>
>```
>"plugins": {
>"dynamic-upstream": {
>"rules": [
>{
>"match": [
>{
>"vars": [
>[ "http_new-release","==","blue" ]
>]
>}
>],
>"upstreams": [
>{
>"upstream": {
>"name": "upstream_A",
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1981":10
>}
>},
>"weight": 1
>},
>{
>
>"weight": 0
>}
>
>]
>}
>]
>}
>},
>"upstream": {
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1980": 1
>}
>}
>```
>
>
>Custom release:
>There are multiple conditions in vars, and the relationship between them is
>`add`. Multiple vars can be configured, then they have an `or`
relationship.
>After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
>the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
>traffic hits the default upstream of the `1980` port.
>
>
>```
>"plugins": {
>"dynamic-upstream": {
>"rules": [
>{
>"match": [
>{
>"vars": [
>[ "arg_name","==","jack" ],
>[ "http_user-id",">=","23" ],
>[ "http_apisix-key","~~","[a-z]+" ]
>]
>}
>],
>"upstreams": [
>{
>"upstream": {
>"name": "upstream_A",
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1981":10
>}
>},
>"weight": 4
>},
>{
>
>“weight”: 2
>
>}
>
>]
>}
>]
>}
>},
>"upstream": {
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1980": 1
>}
>}
>```
>
>
>Note: The vars parameter here can be obtained from the http request header,
>querystring or nginx variable.
>The above is a brief introduction to the dynamic upstream plugin.
>
>
>I want to add this plugin to the apisix project, what do you think?
Re: Re: Re: Proposal: add the traffic split plugin to apisix
Posted by Ming Wen <we...@apache.org>.
> Because many technical problems in the current `dynamic-upstream` plugin
have been solved
Please provide a comparison of strengths and weaknesses, we need more
details
Yuelin Zheng <zy...@163.com>于2020年11月7日 周六上午11:44写道：
> Hi,WenMing,
>
> Yes, this is what we need to consider. I think the plug-in approach is
> feasible. Because many technical problems in the current `dynamic-upstream`
> plugin have been solved.
>
> We can try to implement this plugin.
>
>
> At 2020-11-03 22:44:54, "Ming Wen" <we...@apache.org> wrote:
> >Hi, yuelin,
> >I don’t think the hypothetical result is a convincing reason.
> >We need a comparison of technical solutions.
> >
> >Thanks,
> >Ming Wen, Apache APISIX & Apache SkyWalking
> >Twitter: _WenMing
> >
> >
> >Yuelin Zheng <zy...@163.com> 于2020年11月3日周二 下午9:44写道：
> >
> >> I think plugin implementation is also a good way. If implemented through
> >> existing routing rules,
> >> it is difficult for people who are not familiar with apisix to find this
> >> feature.
> >>
> >>
> >>
> >>
> >>
> >> At 2020-11-01 16:07:21, "Zhang Chao" <zc...@gmail.com> wrote:
> >> > Hi!
> >> >
> >> >Actually we already have a discuss about this feature in this mailing
> >> list,
> >> >see
> >> >
> >>
> https://lists.apache.org/thread.html/r9222f87b69bbb8cf9dce1f5e920adb6aede38f4c24bc1b0dac07b53f%40%3Cdev.apisix.apache.org%3E
> >> >for
> >> >the details.
> >> >
> >> >From my point of view, it’s better to implement the first class
> support of
> >> >traffic split/shift by APISIX instead of by a plugin, since the match
> part
> >> >is highly consistent with Route, and Route already handles the related
> >> >logics like health check, service discovery around Upstream well. On
> the
> >> >contrary, introducing another Plugin which references to Upstream need
> to
> >> >consider these problems once again.
> >> >
> >> >So what about considering the way in the above mentioned link? :)
> >> >
> >> >On November 1, 2020 at 12:00:47 AM, Yuelin Zheng (zyl1812@163.com)
> wrote:
> >> >
> >> >Hi, Community,
> >> >
> >> >
> >> >I have implemented a plug-in related to traffic split, and I want to
> add
> >> >the plug-in to apisix. The following is the main information of the
> >> plugin:
> >> >
> >> >
> >> >1. Background
> >> >
> >> >
> >> >After seeing this issue about traffic split plugin #2303(
> >> >https://github.com/apache/apisix/issues/2303), I think this function
> is
> >> >very useful, it can effectively realize the flow control function.
> >> >Therefore, this inspired me to implement a dynamic upstream plugin.
> >> >
> >> >
> >> >2. Why do this
> >> >For details, please see: https://github.com/apache/apisix/issues/2303
> >> >Traffic split means that requests need to comply with certain rules in
> >> >order to reach the designated upstream or a certain node in the
> upstream.
> >> >Through this function, gray release, blue-green release and custom
> routing
> >> >are realized, which is very useful for reducing downtime in the event
> of a
> >> >failure.
> >> >
> >> >
> >> >3. Design
> >> >The dynamic upstream plug-in is mainly composed of two parts `match`
> and
> >> >`upstreams` to implement the rules of the plugin. `match` is the
> matching
> >> >rule of the plugin (the currently supported operations are: ==, ~=,
> ~~, >,
> >> >>=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
> >> >`upstreams` rule in the plugin be reached, otherwise the default
> upstream
> >> >is reached. In the `upstreams` rule, `upstream` is the configuration of
> >> the
> >> >plugin upstream, and the `weight` field is the basis for traffic
> >> >segmentation between upstream services (using the roundrobin
> algorithm).
> >> >
> >> >
> >> >note:
> >> >```
> >> >{
> >> >"Weight": 1
> >> >}
> >> >```
> >> >When the plug-in upstream configuration has only the weight field, it
> >> means
> >> >the default upstream traffic ratio.
> >> >
> >> >
> >> >Example:
> >> >
> >> >
> >> >Grayscale release:
> >> >The traffic is split according to the weight field value configured in
> the
> >> >upstreams part of the plug-in.
> >> >If `match` is not configured, match is passed by default. Divide the
> >> >request traffic by 4:1, 4/5 of the traffic hits the upstream of the
> plugin
> >> >port of `1981`, and 1/5 of the traffic hits the default upstream of the
> >> >`1980` port.
> >> >
> >> >
> >> >```
> >> >"plugins": {
> >> >"dynamic-upstream": {
> >> >"rules": [
> >> >{
> >> >"upstreams": [
> >> >{
> >> >"upstream": {
> >> >"name": "upstream_A",
> >> >"type": "roundrobin",
> >> >"nodes": {
> >> >"127.0.0.1:1981":10
> >> >}
> >> >},
> >> >"weight": 4
> >> >},
> >> >{
> >> >
> >> >"weight": 1
> >> >}
> >> >
> >> >]
> >> >}
> >> >]
> >> >}
> >> >},
> >> >"upstream": {
> >> >"type": "roundrobin",
> >> >"nodes": {
> >> >"127.0.0.1:1980": 1
> >> >}
> >> >}
> >> >```
> >> >
> >> >
> >> >Blue-green release:
> >> >All requests hit the upstrean configured by the plugin (when weight is
> 0,
> >> >the corresponding upstream is invalid).
> >> >
> >> >
> >> >```
> >> >"plugins": {
> >> >"dynamic-upstream": {
> >> >"rules": [
> >> >{
> >> >"match": [
> >> >{
> >> >"vars": [
> >> >[ "http_new-release","==","blue" ]
> >> >]
> >> >}
> >> >],
> >> >"upstreams": [
> >> >{
> >> >"upstream": {
> >> >"name": "upstream_A",
> >> >"type": "roundrobin",
> >> >"nodes": {
> >> >"127.0.0.1:1981":10
> >> >}
> >> >},
> >> >"weight": 1
> >> >},
> >> >{
> >> >
> >> >"weight": 0
> >> >}
> >> >
> >> >]
> >> >}
> >> >]
> >> >}
> >> >},
> >> >"upstream": {
> >> >"type": "roundrobin",
> >> >"nodes": {
> >> >"127.0.0.1:1980": 1
> >> >}
> >> >}
> >> >```
> >> >
> >> >
> >> >Custom release:
> >> >There are multiple conditions in vars, and the relationship between
> them
> >> is
> >> >`add`. Multiple vars can be configured, then they have an `or`
> >> relationship.
> >> >After the `match` rule is passed, the traffic is divided into 4:2, 2/3
> of
> >> >the traffic hits the plug-in upstream of the `1981` port, and 1/3 of
> the
> >> >traffic hits the default upstream of the `1980` port.
> >> >
> >> >
> >> >```
> >> >"plugins": {
> >> >"dynamic-upstream": {
> >> >"rules": [
> >> >{
> >> >"match": [
> >> >{
> >> >"vars": [
> >> >[ "arg_name","==","jack" ],
> >> >[ "http_user-id",">=","23" ],
> >> >[ "http_apisix-key","~~","[a-z]+" ]
> >> >]
> >> >}
> >> >],
> >> >"upstreams": [
> >> >{
> >> >"upstream": {
> >> >"name": "upstream_A",
> >> >"type": "roundrobin",
> >> >"nodes": {
> >> >"127.0.0.1:1981":10
> >> >}
> >> >},
> >> >"weight": 4
> >> >},
> >> >{
> >> >
> >> >“weight”: 2
> >> >
> >> >}
> >> >
> >> >]
> >> >}
> >> >]
> >> >}
> >> >},
> >> >"upstream": {
> >> >"type": "roundrobin",
> >> >"nodes": {
> >> >"127.0.0.1:1980": 1
> >> >}
> >> >}
> >> >```
> >> >
> >> >
> >> >Note: The vars parameter here can be obtained from the http request
> >> header,
> >> >querystring or nginx variable.
> >> >The above is a brief introduction to the dynamic upstream plugin.
> >> >
> >> >
> >> >I want to add this plugin to the apisix project, what do you think?
> >>
>
--
Thanks,
Ming Wen, Apache APISIX & Apache SkyWalking
Twitter: _WenMing
Re:Re: Re: Proposal: add the traffic split plugin to apisix
Posted by Yuelin Zheng <zy...@163.com>.
Hi,WenMing,
Yes, this is what we need to consider. I think the plug-in approach is feasible. Because many technical problems in the current `dynamic-upstream` plugin have been solved.
We can try to implement this plugin.
At 2020-11-03 22:44:54, "Ming Wen" <we...@apache.org> wrote:
>Hi, yuelin,
>I don’t think the hypothetical result is a convincing reason.
>We need a comparison of technical solutions.
>
>Thanks,
>Ming Wen, Apache APISIX & Apache SkyWalking
>Twitter: _WenMing
>
>
>Yuelin Zheng <zy...@163.com> 于2020年11月3日周二 下午9:44写道：
>
>> I think plugin implementation is also a good way. If implemented through
>> existing routing rules,
>> it is difficult for people who are not familiar with apisix to find this
>> feature.
>>
>>
>>
>>
>>
>> At 2020-11-01 16:07:21, "Zhang Chao" <zc...@gmail.com> wrote:
>> > Hi!
>> >
>> >Actually we already have a discuss about this feature in this mailing
>> list,
>> >see
>> >
>> https://lists.apache.org/thread.html/r9222f87b69bbb8cf9dce1f5e920adb6aede38f4c24bc1b0dac07b53f%40%3Cdev.apisix.apache.org%3E
>> >for
>> >the details.
>> >
>> >From my point of view, it’s better to implement the first class support of
>> >traffic split/shift by APISIX instead of by a plugin, since the match part
>> >is highly consistent with Route, and Route already handles the related
>> >logics like health check, service discovery around Upstream well. On the
>> >contrary, introducing another Plugin which references to Upstream need to
>> >consider these problems once again.
>> >
>> >So what about considering the way in the above mentioned link? :)
>> >
>> >On November 1, 2020 at 12:00:47 AM, Yuelin Zheng (zyl1812@163.com) wrote:
>> >
>> >Hi, Community,
>> >
>> >
>> >I have implemented a plug-in related to traffic split, and I want to add
>> >the plug-in to apisix. The following is the main information of the
>> plugin:
>> >
>> >
>> >1. Background
>> >
>> >
>> >After seeing this issue about traffic split plugin #2303(
>> >https://github.com/apache/apisix/issues/2303), I think this function is
>> >very useful, it can effectively realize the flow control function.
>> >Therefore, this inspired me to implement a dynamic upstream plugin.
>> >
>> >
>> >2. Why do this
>> >For details, please see: https://github.com/apache/apisix/issues/2303
>> >Traffic split means that requests need to comply with certain rules in
>> >order to reach the designated upstream or a certain node in the upstream.
>> >Through this function, gray release, blue-green release and custom routing
>> >are realized, which is very useful for reducing downtime in the event of a
>> >failure.
>> >
>> >
>> >3. Design
>> >The dynamic upstream plug-in is mainly composed of two parts `match` and
>> >`upstreams` to implement the rules of the plugin. `match` is the matching
>> >rule of the plugin (the currently supported operations are: ==, ~=, ~~, >,
>> >>=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
>> >`upstreams` rule in the plugin be reached, otherwise the default upstream
>> >is reached. In the `upstreams` rule, `upstream` is the configuration of
>> the
>> >plugin upstream, and the `weight` field is the basis for traffic
>> >segmentation between upstream services (using the roundrobin algorithm).
>> >
>> >
>> >note:
>> >```
>> >{
>> >"Weight": 1
>> >}
>> >```
>> >When the plug-in upstream configuration has only the weight field, it
>> means
>> >the default upstream traffic ratio.
>> >
>> >
>> >Example:
>> >
>> >
>> >Grayscale release:
>> >The traffic is split according to the weight field value configured in the
>> >upstreams part of the plug-in.
>> >If `match` is not configured, match is passed by default. Divide the
>> >request traffic by 4:1, 4/5 of the traffic hits the upstream of the plugin
>> >port of `1981`, and 1/5 of the traffic hits the default upstream of the
>> >`1980` port.
>> >
>> >
>> >```
>> >"plugins": {
>> >"dynamic-upstream": {
>> >"rules": [
>> >{
>> >"upstreams": [
>> >{
>> >"upstream": {
>> >"name": "upstream_A",
>> >"type": "roundrobin",
>> >"nodes": {
>> >"127.0.0.1:1981":10
>> >}
>> >},
>> >"weight": 4
>> >},
>> >{
>> >
>> >"weight": 1
>> >}
>> >
>> >]
>> >}
>> >]
>> >}
>> >},
>> >"upstream": {
>> >"type": "roundrobin",
>> >"nodes": {
>> >"127.0.0.1:1980": 1
>> >}
>> >}
>> >```
>> >
>> >
>> >Blue-green release:
>> >All requests hit the upstrean configured by the plugin (when weight is 0,
>> >the corresponding upstream is invalid).
>> >
>> >
>> >```
>> >"plugins": {
>> >"dynamic-upstream": {
>> >"rules": [
>> >{
>> >"match": [
>> >{
>> >"vars": [
>> >[ "http_new-release","==","blue" ]
>> >]
>> >}
>> >],
>> >"upstreams": [
>> >{
>> >"upstream": {
>> >"name": "upstream_A",
>> >"type": "roundrobin",
>> >"nodes": {
>> >"127.0.0.1:1981":10
>> >}
>> >},
>> >"weight": 1
>> >},
>> >{
>> >
>> >"weight": 0
>> >}
>> >
>> >]
>> >}
>> >]
>> >}
>> >},
>> >"upstream": {
>> >"type": "roundrobin",
>> >"nodes": {
>> >"127.0.0.1:1980": 1
>> >}
>> >}
>> >```
>> >
>> >
>> >Custom release:
>> >There are multiple conditions in vars, and the relationship between them
>> is
>> >`add`. Multiple vars can be configured, then they have an `or`
>> relationship.
>> >After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
>> >the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
>> >traffic hits the default upstream of the `1980` port.
>> >
>> >
>> >```
>> >"plugins": {
>> >"dynamic-upstream": {
>> >"rules": [
>> >{
>> >"match": [
>> >{
>> >"vars": [
>> >[ "arg_name","==","jack" ],
>> >[ "http_user-id",">=","23" ],
>> >[ "http_apisix-key","~~","[a-z]+" ]
>> >]
>> >}
>> >],
>> >"upstreams": [
>> >{
>> >"upstream": {
>> >"name": "upstream_A",
>> >"type": "roundrobin",
>> >"nodes": {
>> >"127.0.0.1:1981":10
>> >}
>> >},
>> >"weight": 4
>> >},
>> >{
>> >
>> >“weight”: 2
>> >
>> >}
>> >
>> >]
>> >}
>> >]
>> >}
>> >},
>> >"upstream": {
>> >"type": "roundrobin",
>> >"nodes": {
>> >"127.0.0.1:1980": 1
>> >}
>> >}
>> >```
>> >
>> >
>> >Note: The vars parameter here can be obtained from the http request
>> header,
>> >querystring or nginx variable.
>> >The above is a brief introduction to the dynamic upstream plugin.
>> >
>> >
>> >I want to add this plugin to the apisix project, what do you think?
>>
Re: Re: Proposal: add the traffic split plugin to apisix
Posted by Ming Wen <we...@apache.org>.
Hi, yuelin,
I don’t think the hypothetical result is a convincing reason.
We need a comparison of technical solutions.
Thanks,
Ming Wen, Apache APISIX & Apache SkyWalking
Twitter: _WenMing
Yuelin Zheng <zy...@163.com> 于2020年11月3日周二 下午9:44写道：
> I think plugin implementation is also a good way. If implemented through
> existing routing rules,
> it is difficult for people who are not familiar with apisix to find this
> feature.
>
>
>
>
>
> At 2020-11-01 16:07:21, "Zhang Chao" <zc...@gmail.com> wrote:
> > Hi!
> >
> >Actually we already have a discuss about this feature in this mailing
> list,
> >see
> >
> https://lists.apache.org/thread.html/r9222f87b69bbb8cf9dce1f5e920adb6aede38f4c24bc1b0dac07b53f%40%3Cdev.apisix.apache.org%3E
> >for
> >the details.
> >
> >From my point of view, it’s better to implement the first class support of
> >traffic split/shift by APISIX instead of by a plugin, since the match part
> >is highly consistent with Route, and Route already handles the related
> >logics like health check, service discovery around Upstream well. On the
> >contrary, introducing another Plugin which references to Upstream need to
> >consider these problems once again.
> >
> >So what about considering the way in the above mentioned link? :)
> >
> >On November 1, 2020 at 12:00:47 AM, Yuelin Zheng (zyl1812@163.com) wrote:
> >
> >Hi, Community,
> >
> >
> >I have implemented a plug-in related to traffic split, and I want to add
> >the plug-in to apisix. The following is the main information of the
> plugin:
> >
> >
> >1. Background
> >
> >
> >After seeing this issue about traffic split plugin #2303(
> >https://github.com/apache/apisix/issues/2303), I think this function is
> >very useful, it can effectively realize the flow control function.
> >Therefore, this inspired me to implement a dynamic upstream plugin.
> >
> >
> >2. Why do this
> >For details, please see: https://github.com/apache/apisix/issues/2303
> >Traffic split means that requests need to comply with certain rules in
> >order to reach the designated upstream or a certain node in the upstream.
> >Through this function, gray release, blue-green release and custom routing
> >are realized, which is very useful for reducing downtime in the event of a
> >failure.
> >
> >
> >3. Design
> >The dynamic upstream plug-in is mainly composed of two parts `match` and
> >`upstreams` to implement the rules of the plugin. `match` is the matching
> >rule of the plugin (the currently supported operations are: ==, ~=, ~~, >,
> >>=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
> >`upstreams` rule in the plugin be reached, otherwise the default upstream
> >is reached. In the `upstreams` rule, `upstream` is the configuration of
> the
> >plugin upstream, and the `weight` field is the basis for traffic
> >segmentation between upstream services (using the roundrobin algorithm).
> >
> >
> >note:
> >```
> >{
> >"Weight": 1
> >}
> >```
> >When the plug-in upstream configuration has only the weight field, it
> means
> >the default upstream traffic ratio.
> >
> >
> >Example:
> >
> >
> >Grayscale release:
> >The traffic is split according to the weight field value configured in the
> >upstreams part of the plug-in.
> >If `match` is not configured, match is passed by default. Divide the
> >request traffic by 4:1, 4/5 of the traffic hits the upstream of the plugin
> >port of `1981`, and 1/5 of the traffic hits the default upstream of the
> >`1980` port.
> >
> >
> >```
> >"plugins": {
> >"dynamic-upstream": {
> >"rules": [
> >{
> >"upstreams": [
> >{
> >"upstream": {
> >"name": "upstream_A",
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1981":10
> >}
> >},
> >"weight": 4
> >},
> >{
> >
> >"weight": 1
> >}
> >
> >]
> >}
> >]
> >}
> >},
> >"upstream": {
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1980": 1
> >}
> >}
> >```
> >
> >
> >Blue-green release:
> >All requests hit the upstrean configured by the plugin (when weight is 0,
> >the corresponding upstream is invalid).
> >
> >
> >```
> >"plugins": {
> >"dynamic-upstream": {
> >"rules": [
> >{
> >"match": [
> >{
> >"vars": [
> >[ "http_new-release","==","blue" ]
> >]
> >}
> >],
> >"upstreams": [
> >{
> >"upstream": {
> >"name": "upstream_A",
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1981":10
> >}
> >},
> >"weight": 1
> >},
> >{
> >
> >"weight": 0
> >}
> >
> >]
> >}
> >]
> >}
> >},
> >"upstream": {
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1980": 1
> >}
> >}
> >```
> >
> >
> >Custom release:
> >There are multiple conditions in vars, and the relationship between them
> is
> >`add`. Multiple vars can be configured, then they have an `or`
> relationship.
> >After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
> >the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
> >traffic hits the default upstream of the `1980` port.
> >
> >
> >```
> >"plugins": {
> >"dynamic-upstream": {
> >"rules": [
> >{
> >"match": [
> >{
> >"vars": [
> >[ "arg_name","==","jack" ],
> >[ "http_user-id",">=","23" ],
> >[ "http_apisix-key","~~","[a-z]+" ]
> >]
> >}
> >],
> >"upstreams": [
> >{
> >"upstream": {
> >"name": "upstream_A",
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1981":10
> >}
> >},
> >"weight": 4
> >},
> >{
> >
> >“weight”: 2
> >
> >}
> >
> >]
> >}
> >]
> >}
> >},
> >"upstream": {
> >"type": "roundrobin",
> >"nodes": {
> >"127.0.0.1:1980": 1
> >}
> >}
> >```
> >
> >
> >Note: The vars parameter here can be obtained from the http request
> header,
> >querystring or nginx variable.
> >The above is a brief introduction to the dynamic upstream plugin.
> >
> >
> >I want to add this plugin to the apisix project, what do you think?
>
Re:Re: Proposal: add the traffic split plugin to apisix
Posted by Yuelin Zheng <zy...@163.com>.
I think plugin implementation is also a good way. If implemented through existing routing rules,
it is difficult for people who are not familiar with apisix to find this feature.
At 2020-11-01 16:07:21, "Zhang Chao" <zc...@gmail.com> wrote:
> Hi!
>
>Actually we already have a discuss about this feature in this mailing list,
>see
>https://lists.apache.org/thread.html/r9222f87b69bbb8cf9dce1f5e920adb6aede38f4c24bc1b0dac07b53f%40%3Cdev.apisix.apache.org%3E
>for
>the details.
>
>From my point of view, it’s better to implement the first class support of
>traffic split/shift by APISIX instead of by a plugin, since the match part
>is highly consistent with Route, and Route already handles the related
>logics like health check, service discovery around Upstream well. On the
>contrary, introducing another Plugin which references to Upstream need to
>consider these problems once again.
>
>So what about considering the way in the above mentioned link? :)
>
>On November 1, 2020 at 12:00:47 AM, Yuelin Zheng (zyl1812@163.com) wrote:
>
>Hi, Community,
>
>
>I have implemented a plug-in related to traffic split, and I want to add
>the plug-in to apisix. The following is the main information of the plugin:
>
>
>1. Background
>
>
>After seeing this issue about traffic split plugin #2303(
>https://github.com/apache/apisix/issues/2303), I think this function is
>very useful, it can effectively realize the flow control function.
>Therefore, this inspired me to implement a dynamic upstream plugin.
>
>
>2. Why do this
>For details, please see: https://github.com/apache/apisix/issues/2303
>Traffic split means that requests need to comply with certain rules in
>order to reach the designated upstream or a certain node in the upstream.
>Through this function, gray release, blue-green release and custom routing
>are realized, which is very useful for reducing downtime in the event of a
>failure.
>
>
>3. Design
>The dynamic upstream plug-in is mainly composed of two parts `match` and
>`upstreams` to implement the rules of the plugin. `match` is the matching
>rule of the plugin (the currently supported operations are: ==, ~=, ~~, >,
>>=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
>`upstreams` rule in the plugin be reached, otherwise the default upstream
>is reached. In the `upstreams` rule, `upstream` is the configuration of the
>plugin upstream, and the `weight` field is the basis for traffic
>segmentation between upstream services (using the roundrobin algorithm).
>
>
>note:
>```
>{
>"Weight": 1
>}
>```
>When the plug-in upstream configuration has only the weight field, it means
>the default upstream traffic ratio.
>
>
>Example:
>
>
>Grayscale release:
>The traffic is split according to the weight field value configured in the
>upstreams part of the plug-in.
>If `match` is not configured, match is passed by default. Divide the
>request traffic by 4:1, 4/5 of the traffic hits the upstream of the plugin
>port of `1981`, and 1/5 of the traffic hits the default upstream of the
>`1980` port.
>
>
>```
>"plugins": {
>"dynamic-upstream": {
>"rules": [
>{
>"upstreams": [
>{
>"upstream": {
>"name": "upstream_A",
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1981":10
>}
>},
>"weight": 4
>},
>{
>
>"weight": 1
>}
>
>]
>}
>]
>}
>},
>"upstream": {
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1980": 1
>}
>}
>```
>
>
>Blue-green release:
>All requests hit the upstrean configured by the plugin (when weight is 0,
>the corresponding upstream is invalid).
>
>
>```
>"plugins": {
>"dynamic-upstream": {
>"rules": [
>{
>"match": [
>{
>"vars": [
>[ "http_new-release","==","blue" ]
>]
>}
>],
>"upstreams": [
>{
>"upstream": {
>"name": "upstream_A",
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1981":10
>}
>},
>"weight": 1
>},
>{
>
>"weight": 0
>}
>
>]
>}
>]
>}
>},
>"upstream": {
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1980": 1
>}
>}
>```
>
>
>Custom release:
>There are multiple conditions in vars, and the relationship between them is
>`add`. Multiple vars can be configured, then they have an `or` relationship.
>After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
>the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
>traffic hits the default upstream of the `1980` port.
>
>
>```
>"plugins": {
>"dynamic-upstream": {
>"rules": [
>{
>"match": [
>{
>"vars": [
>[ "arg_name","==","jack" ],
>[ "http_user-id",">=","23" ],
>[ "http_apisix-key","~~","[a-z]+" ]
>]
>}
>],
>"upstreams": [
>{
>"upstream": {
>"name": "upstream_A",
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1981":10
>}
>},
>"weight": 4
>},
>{
>
>“weight”: 2
>
>}
>
>]
>}
>]
>}
>},
>"upstream": {
>"type": "roundrobin",
>"nodes": {
>"127.0.0.1:1980": 1
>}
>}
>```
>
>
>Note: The vars parameter here can be obtained from the http request header,
>querystring or nginx variable.
>The above is a brief introduction to the dynamic upstream plugin.
>
>
>I want to add this plugin to the apisix project, what do you think?
Re: Proposal: add the traffic split plugin to apisix
Posted by Zhang Chao <zc...@gmail.com>.
Hi!
Actually we already have a discuss about this feature in this mailing list,
see
https://lists.apache.org/thread.html/r9222f87b69bbb8cf9dce1f5e920adb6aede38f4c24bc1b0dac07b53f%40%3Cdev.apisix.apache.org%3E
for
the details.
From my point of view, it’s better to implement the first class support of
traffic split/shift by APISIX instead of by a plugin, since the match part
is highly consistent with Route, and Route already handles the related
logics like health check, service discovery around Upstream well. On the
contrary, introducing another Plugin which references to Upstream need to
consider these problems once again.
So what about considering the way in the above mentioned link? :)
On November 1, 2020 at 12:00:47 AM, Yuelin Zheng (zyl1812@163.com) wrote:
Hi, Community,
I have implemented a plug-in related to traffic split, and I want to add
the plug-in to apisix. The following is the main information of the plugin:
1. Background
After seeing this issue about traffic split plugin #2303(
https://github.com/apache/apisix/issues/2303), I think this function is
very useful, it can effectively realize the flow control function.
Therefore, this inspired me to implement a dynamic upstream plugin.
2. Why do this
For details, please see: https://github.com/apache/apisix/issues/2303
Traffic split means that requests need to comply with certain rules in
order to reach the designated upstream or a certain node in the upstream.
Through this function, gray release, blue-green release and custom routing
are realized, which is very useful for reducing downtime in the event of a
failure.
3. Design
The dynamic upstream plug-in is mainly composed of two parts `match` and
`upstreams` to implement the rules of the plugin. `match` is the matching
rule of the plugin (the currently supported operations are: ==, ~=, ~~, >,
>=, <, <=, in , ip_in). Only after the `match` rule is passed, can the
`upstreams` rule in the plugin be reached, otherwise the default upstream
is reached. In the `upstreams` rule, `upstream` is the configuration of the
plugin upstream, and the `weight` field is the basis for traffic
segmentation between upstream services (using the roundrobin algorithm).
note:
```
{
"Weight": 1
}
```
When the plug-in upstream configuration has only the weight field, it means
the default upstream traffic ratio.
Example:
Grayscale release:
The traffic is split according to the weight field value configured in the
upstreams part of the plug-in.
If `match` is not configured, match is passed by default. Divide the
request traffic by 4:1, 4/5 of the traffic hits the upstream of the plugin
port of `1981`, and 1/5 of the traffic hits the default upstream of the
`1980` port.
```
"plugins": {
"dynamic-upstream": {
"rules": [
{
"upstreams": [
{
"upstream": {
"name": "upstream_A",
"type": "roundrobin",
"nodes": {
"127.0.0.1:1981":10
}
},
"weight": 4
},
{
"weight": 1
}
]
}
]
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"127.0.0.1:1980": 1
}
}
```
Blue-green release:
All requests hit the upstrean configured by the plugin (when weight is 0,
the corresponding upstream is invalid).
```
"plugins": {
"dynamic-upstream": {
"rules": [
{
"match": [
{
"vars": [
[ "http_new-release","==","blue" ]
]
}
],
"upstreams": [
{
"upstream": {
"name": "upstream_A",
"type": "roundrobin",
"nodes": {
"127.0.0.1:1981":10
}
},
"weight": 1
},
{
"weight": 0
}
]
}
]
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"127.0.0.1:1980": 1
}
}
```
Custom release:
There are multiple conditions in vars, and the relationship between them is
`add`. Multiple vars can be configured, then they have an `or` relationship.
After the `match` rule is passed, the traffic is divided into 4:2, 2/3 of
the traffic hits the plug-in upstream of the `1981` port, and 1/3 of the
traffic hits the default upstream of the `1980` port.
```
"plugins": {
"dynamic-upstream": {
"rules": [
{
"match": [
{
"vars": [
[ "arg_name","==","jack" ],
[ "http_user-id",">=","23" ],
[ "http_apisix-key","~~","[a-z]+" ]
]
}
],
"upstreams": [
{
"upstream": {
"name": "upstream_A",
"type": "roundrobin",
"nodes": {
"127.0.0.1:1981":10
}
},
"weight": 4
},
{
“weight”: 2
}
]
}
]
}
},
"upstream": {
"type": "roundrobin",
"nodes": {
"127.0.0.1:1980": 1
}
}
```
Note: The vars parameter here can be obtained from the http request header,
querystring or nginx variable.
The above is a brief introduction to the dynamic upstream plugin.
I want to add this plugin to the apisix project, what do you think?