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