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”<[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


Reply via email to