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