[FEATURE] Service first workflow

[wenerme]

Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

When use a service

mysvcv1.NewProviderService("provider-server-name", client)

but the consumer do not care provider-server-name or provider-alt-server-name, the service name is already know hen gen grpc

var ProviderService_ServiceDesc = grpc.ServiceDesc{
        // micro should allowed registry by this service name
	ServiceName: "wener.mysvc.v1.ProviderService",
}

ignore the provider server name make micro more service oriented.

Describe the solution you'd like A clear and concise description of what you want to happen.

use grpc ServiceName, per service registry entry.

same service can provided by different server.

mysvcv1.NewProviderService(client)

micro gen should include some basic metadata.

Additional context Add any other context or screenshots about the feature request here.

[asim]

@xpunch what do you think?

[xpunch]

The grpc do provide ServiceDesc, but it only intended for direct use with grpc.RegisterService(Source). So it only used to handle single service defined in proto files, which already implemented by go micro. The service name in go micro is used to handle service registration and service discovery, and a micro service may provide multiple grpc services, so use grpc.ServiceDesc as service name is not acceptable, which I think is a misunderstand between micro service name and grpc service name.

[wenerme]

micro's server is a set of services, but when consuming service, consumer should not care the producer's server name.

micro should provide a way for consuming service by FQDN, like in java world, every service is identified by a FQDN name, e.g com.wener.crm.CustomerService. grpc.ServiceDesc just contain FQDN for every service.

current registry is based on server name, but should be ok to support service name ?

[xpunch]

What do you mean:

current registry is based on server name, but should be ok to support service name ?

[wenerme]

manually register service by FQDN, consuming by FQDN, like

registry.Register(&registry.Service{
    Name: agentv1.AgentService_ServiceDesc.ServiceName,
})
as := agentv1.NewAgentService(agentv1.AgentService_ServiceDesc.ServiceName, client.DefaultClient)

not tested.

[xpunch]

I still don't think we should support this.

1. As I said, a micro service may provide multiple grpc service, there is no need to register every single grpc services.
2. Same grpc service can provide different service with different configuration, ServiceDesc.ServiceName cannot always represents the real service.
3. As I know, in spring cloud service name is defined by developers in config files.

[wenerme]

I used to work in java env, really like consuming service by interface, interface imply the destination service name.

like in dubbo https://dubbo.apache.org/en/docs/v2.7/user/recommend/

<dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService"
    timeout="300" retry="2" loadbalance="random" actives="0"
/>

this xml consume com.alibaba.hello.api.HelloService .

nowadays, grpc is the interface.

[asim]

I think what @xpunch is trying to say is the model differs here. We treat grpc services as handlers and the service name could differ. With grpc you still have to register against a server and the client has to dial a destination. We use service names to resolve that so you're just doing it by name.

If we removed that it would 1. Be backwards incompatible and 2. Would lose the ability to specify multiple handlers on one service because the client code wouldn't allow for calling I'm happy to potentially accept some new signature function that lets you do it without names but just noting it should clash with any existing functions or grpc generated functions.

[xpunch]

As I said, you misunderstand the grpc service name and micro service name. The "grpc service name" is implemented by go micro in different way, clients do not care grpc service name(handled by protoc-gen-micro), what the client need to care is micro service name. go micro service name is more like:

<dubbo:application name="myalibaba" >

[wenerme]

Yes, I know current micro's server & service, this is a feature request or proposal, wondering how to make micro work in this situation.

Like micro's registry can index grpc Endpoint of service, when GetService told to find by grpc service name, return the correct registry.Service .

This is just some thoughts.

[asim]

Well if you have some ideas, feel free to show us example code of how it would work without breaking backwards compatibility