0.19.0
Highlight
Multi-upstream support in services
ADC now supports the inclusion of multiple upstreams in a single service in such a structure:
services:
- name: demo
upstream:
<default upstream>
upstreams:
- name: non-default-upstream-1
<upstream config 1>
- name: non-default-upstream-2
<upstream config 2>
routes: []
That is, it lets users create multiple new upstreams with service.upstreams
. Where service.upstream
is the default upstream, it will be used as the default upstream for all requests, or users can use the traffic-split
plugin if users want to route some traffic to other upstreams proportionally or conditionally.
The service.upstreams
supports setting a name or ID for the upstream, which is inferred and generated using sha1(service_name.upstream_name)
if users don't specify the ID manually, and which can be used in the weighted_upstreams.upstream_id
in the traffic-split
plugin, allowing users to get rid of the requirement to inline upstream resources in the traffic-split
plugin and enjoy the full functionality of the upstream health check.
Please note that when using custom IDs, users must ensure the uniqueness of the IDs, as conflicts can result in unintended coverage of resources.
In API7, upstream is natively associated with the service, which is a built-in capability, so support is native.
Whereas in APISIX upstreams are unable to proactively record associations with services, so we record the services that the upstream belongs to in labels, even though this is simulated, it works out of the box, please be careful not to manage and manually modify the records in labels by means other than ADC.
What's Changed
- feat(api7): support multiple upstream of service by @bzp2010 in #252
- fix(apisix): log scope typo by @bzp2010 in #253
- feat(apisix): support multiple upstream of service by @bzp2010 in #254
- fix(apisix): tolerate instance without stream proxy enabled by @bzp2010 in #255
- feat: bump to 0.19.0 by @bzp2010 in #256
Full Changelog: v0.18.0...v0.19.0