feat(nacos): add metadata filtering support to nacos discovery
Description
Add metadata filtering support to nacos discovery.
Which issue(s) this PR fixes:
Fixes https://github.com/apache/apisix/issues/12392
Checklist
- [x] I have explained the need for this PR and the problem it solves
- [x] I have explained the changes or the new features added to this PR
- [x] I have added tests corresponding to this change
- [x] I have updated the documentation to reflect this change
- [x] I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)
There seems to be duplicate work https://github.com/apache/apisix/pull/12448 (coincidentally, we have similar demands). According to my understanding of apisix, all routes share the same service discovery results, so it is not suitable to filter in the discovery.
There seems to be duplicate work #12448 (coincidentally, we have similar demands). According to my understanding of apisix, all routes share the same service discovery results, so it is not suitable to filter in the discovery.
I don't think it's a duplicate at the moment. Using metadata to filter nacos services is a very useful feature. For more information, you can check the related issue.
I don't think it's a duplicate at the moment. Using metadata to filter nacos services is a very useful feature. For more information, you can check the related issue.
Got it, thanks for you reply :)
This is used to filter when pulling the service list from service discovery to avoid pulling a large number of useless instances. We also have similar demands when using Consul. I will try to add the following.
@beardnick ping
After checking #12392 and #12464, I have a question:
I haven't seen any discussions that should be implemented as single-value matching or multi-value matching?
#12464 Propose:
Currently, someone in Nacos is also implementing the same function #12392 #12445, but only supports single value matching. However, we hope to support multi-value matching. This is because user requests often do not have any tags, so if we want to allow multiple instances with different metadata to provide services together, we must register a special metadata to group them, but this grouping cannot be changed dynamically.
I think it makes sense.
But I am not an expert in this field, so what do you think?
Certainly, that sounds very reasonable. I’m happy to support multi-value matching.
@beardnick Are you planning to implement this in this PR, or in another one?
If you want to implement it in other PRs, then this PR is ready for review.
@beardnick Are you planning to implement this in this PR, or in another one?
If you want to implement it in other PRs, then this PR is ready for review.
In this PR.
@beardnick Please fix the errors reported in the CI.
@beardnick Please fix the errors reported in the CI.
The failed tests seem unrelated to my PR. Could you please rerun them?
@SkyeYoung Please rerun the failed tests.
@Baoyuantop @SkyeYoung ping
@Baoyuantop @SkyeYoung The failed tests appear to be unrelated to my PR. Could you continue reviewing it?
Hi @beardnick, could you merge the code from the main branch again to make CI pass?
Hi @beardnick, could you merge the code from the main branch again to make CI pass?
Done
@SkyeYoung @bzp2010 @nic-6443 @Revolyssup @AlinsRan @membphis The failed tests appear to be unrelated to my PR. Could you continue reviewing it?
Hi @beardnick, please check those comments