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" <[email protected]> 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 <[email protected]> 于2020年11月1日周日 下午12:52写道： > >> +1 agree >> LGTM >> >> Yuelin Zheng <[email protected]> 于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? >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >>
