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. > > >
