You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apisix.apache.org by 黄一天 <wf...@163.com> on 2020/12/01 10:24:12 UTC
[Discussion]is it reasonable to allow one route to support multiple
upstreams (aka. "upstream group")?
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.
Re: [Discussion]is it reasonable to allow one route to support
multiple upstreams (aka. "upstream group")?
Posted by YuanSheng Wang <me...@apache.org>.
> 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 黄一天 <wf...@163.com> 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=
> 163.com@apisix.apache.org 代表 membphis@apache.org> 写入:
>
> 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 <kv...@apache.org> wrote:
>
> > Agree, I think it is reasonable and a big feature.
> > What other people think?
> >
> > 黄一天 <wf...@163.com> 于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
Re: [Discussion]is it reasonable to allow one route to support
multiple upstreams (aka. "upstream group")?
Posted by 黄一天 <wf...@163.com>.
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=163.com@apisix.apache.org 代表 membphis@apache.org> 写入:
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 <kv...@apache.org> wrote:
> Agree, I think it is reasonable and a big feature.
> What other people think?
>
> 黄一天 <wf...@163.com> 于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
Re: [Discussion]is it reasonable to allow one route to support
multiple upstreams (aka. "upstream group")?
Posted by YuanSheng Wang <me...@apache.org>.
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 <kv...@apache.org> wrote:
> Agree, I think it is reasonable and a big feature.
> What other people think?
>
> 黄一天 <wf...@163.com> 于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
Re: [Discussion]is it reasonable to allow one route to support
multiple upstreams (aka. "upstream group")?
Posted by wei jin <kv...@apache.org>.
Agree, I think it is reasonable and a big feature.
What other people think?
黄一天 <wf...@163.com> 于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.
>
>
>