jizhuozhi opened a new issue, #12464: URL: https://github.com/apache/apisix/issues/12464
### Description As a user, I hope that for the same service name, different instances can be filtered in different routes, upstreams, and services. ## Q. Why do we need metadata filtering? A. For the same service, we will have different metadata for management. For example, when the recommendation system model changes, the model version will be modified and traffic switching and ab experiments will be performed through client coloring. ## Q. Why not use different service names? A. We will create multiple environments based on the same service template. They only have some different metadata, such as env or lane, and model version. As the metadata dimension increases, the service names we need to locate specific coordinates will increase nonlinearly. ## Q. What upstream types need to be supported? A. Including Consul, Eureka, Nacos and other registration center types, as well as the registration center selection that may be added in the future or within the enterprise can directly inherit this capability ## Q. Any other context? A1. I'm sorry I broke the process. I have implemented filtering in the upstream dimension internally and submitted PR https://github.com/apache/apisix/pull/12448. During the communication process, I conservatively changed to only support Consul's implementation, but following the DRY principle, I think it may be suitable to put it in the upstream instead of implementing it once for each discovery. A2. Currently, someone in Nacos is also implementing the same function https://github.com/apache/apisix/issues/12392 https://github.com/apache/apisix/pull/12445, but only supports single value matching. However, we hope to support multi-value matching. For example, for env, we hope to support prod, canary but not uat (User Acceptance Testing), so that when we have multiple metadata that need to be combined, we can avoid the expansion of the routing table. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
