[Feature] Some specification issues when Kratos registers services on Polaris about kratos HOT 9 CLOSED

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

Feature-request

1. Register on Polaris, and the service name and agreement are directly spliced ​​together.

2. There are some problems with the input of the protocol field during registration.

3. The current service name after registration

2. At present, the protocol field cannot be filled in at all, because after writing it, the two registered service instances will have the same protocol tag. According to the design, the corresponding protocol fields should be filled in directly in the Kratos registration implementation code, so it is useless for developers to fill it in here.

Proposal

1. When registering on Polaris, it should not be a direct concatenation of service name + protocol. There should be at least a separator, such as rc-user.http or rc-user-http. Although it does not affect use currently, I think this is also a norm.

2. The protocol fields for registered service instances should be specified internally in the contrib/registry/polaris/registry.go file in the Kratos project instead of being passed in by developers.

from kratos.

Which SDK is being used? contrib/registry/polaris or contrib/polaris

from kratos.

you can try using contrib/polaris

from kratos.

All right , I am currently using contrib/registry/polaris

from kratos.

But contrib/registry/polaris more in line with framework usage for kratos

from kratos.

subsequent collaborations with Polaris will be conducted in contrib/polaris

from kratos.

ok. I switch to contrib/polaris

from kratos.

我已经使用了 contrib/polaris 包进行了注册，我发现现在的实现逻辑是 同一个服务名称 下 注册实例是通过协议区分的。这确实更符合注册逻辑，非常科学

但是我想问下，关于限流，那现在是不是不能根据协议进行区分 限流规则了？比如同一个接口 http 我想 1分钟 1次请求，grpc 1分钟 2次请求的配置，这种现在能支持吗？

from kratos.

Bot detected the issue body's language is not English, translate it automatically. 👯👭🏻🧑‍🤝‍🧑👫🧑🏿‍🤝‍🧑🏻👩🏾‍🤝‍👨🏿👬🏿

I have used the contrib/polaris package to register, and I found that the current implementation logic is that registered instances under the same service name are distinguished by protocols. This is indeed more in line with the registration logic and very scientific

But I would like to ask, regarding current limiting, is it not possible to distinguish current limiting rules based on protocols? For example, I want to configure the same interface http to request once per minute, and grpc to request twice per minute. Can this be supported now?

from kratos.