> One quick question, In this plugin, how do you deal with healthcheck and retry? I will keep following it.
it seems that this PR does not support health check now. welcome to discuss to add `health check` at github PR. ^_^ On Fri, Dec 11, 2020 at 8:03 PM 黄一天 <[email protected]> wrote: > Fantastic !! It is definitely a very solid foundation to me. This plugin > supports "upstream group" targeting traffic splitting. What I am expecting > is a "upstream group management structure". One quick question, In this > plugin, how do you deal with healthcheck and retry? I will keep following > it. > > 在 2020/12/11 下午5:55，“YuanSheng Wang”<dev-return-2458-wfgydbu= > [email protected] 代表 [email protected]> 写入: > > hi: > > welcome to take a look at this PR[1] > > A new way to set the upstream, it may useful > > [1] https://github.com/apache/apisix/pull/2935 > > > On Sat, Dec 5, 2020 at 3:34 PM wei jin <[email protected]> wrote: > > > Agree, I think it is reasonable and a big feature. > > What other people think? > > > > 黄一天 <[email protected]> 于2020年12月1日周二 下午6:24写道： > > > >> Hi Community, > >> > >> > >> > >> Consider this scenario: > >> > >> In a single datacenter, there are several cluster nodes(or > machines, not > >> the node in upstream definition), each node deploys multiple > instances as > >> head services. All head services are functionally equivalent. Using > Apisix > >> as the gateway to access all instances. Then we have this logic > structure: > >> > >> In this case, node1-3 can be considered as upstreams, and each > upstream > >> has N nodes(port1…N) in route configuration. > >> > >> We found current route configuration may sometimes be unclear and > hard to > >> manage. Consider: > >> > >> (1) if one instance was down, to maintain the SLA of the whole > system, we > >> may pessimistically consider all instances on the same node were > down > >> either and immediately kick-off the whole node. In this case, we > can simply > >> remove one "upstream group" in the route. (possibly done by > healthcheck) > >> > >> (2) if one single request had failed, it is safer to make it retry > with > >> the instance on other nodes, not another instance on the same node. > >> (without upstream group, it is a bit difficult to find the right > instance > >> to retry.) > >> > >> (3) if we consider node3 as a superior node (has more CPU cores or > >> Memory, which leads to higher perf), we expect most of the traffic > to be > >> forwarded to this node. (In this case, maybe we could just adjust > this > >> upstream group’s weight) > >> > >> > >> > >> What if allow one route to support upstream list, not one upstream? > >> > >> What do you think? > >> > >> Thanks. > >> > >> > >> > > > > -- > > *MembPhis* > My GitHub: https://github.com/membphis > Apache APISIX: https://github.com/apache/apisix > > > -- *MembPhis* My GitHub: https://github.com/membphis Apache APISIX: https://github.com/apache/apisix
