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 ([email protected]) 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" <[email protected]> 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 ([email protected]) 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?
