在之前的文章中别离介绍了应用gRPC官网插件和go-micro插件开发gRPC应用程序的形式，都能失常走通。不过当两者混合应用的时候，相互拜访就成了问题。比方应用go-micro插件生成的gRPC客户端拜访基于gRPC官网插件创立的服务端时就会呈现如下谬误：

{"id":"go.micro.client","code":501,"status":"Not Implemented"}

通过一番摸索，发现是因为go-micro的插件生成代码时抛弃了proto定义中的package，客户端API和服务端API都没有应用这个package，所以它本人也能逻辑自洽，然而和其它框架或者语言的gRPC服务通信时就呈现问题了。

这里以 hello.proto 为例：

syntax = "proto3";

option go_package="/proto";

package Business;

service Hello {
  rpc Say (SayRequest) returns (SayResponse);
}

message SayResponse {
  string Message = 1;
}

message SayRequest {
  string Name = 1;
}

对于客户端代理，protoc-gen-go-grpc生成的是：

err := c.cc.Invoke(ctx, "/Business.Hello/Say", in, out, opts...)

protoc-gen-micro生成的是：

req := c.c.NewRequest(c.name, "Hello.Say", in)

能够显著看到，go-micro生成的gRPC method中短少package。当然这个method的格调也有些差别，不过这个不是问题，因为go-micro还会它进行一些格式化解决，格式化代码在grpc插件中。

plugins/client/grpc/request.go :

func methodToGRPC(service, method string) string {
    // no method or already grpc method
    if len(method) == 0 || method[0] == '/' {
        return method
    }

    // assume method is Foo.Bar
    mParts := strings.Split(method, ".")
    if len(mParts) != 2 {
        return method
    }

    if len(service) == 0 {
        return fmt.Sprintf("/%s/%s", mParts[0], mParts[1])
    }

    // return /pkg.Foo/Bar
    return fmt.Sprintf("/%s.%s/%s", service, mParts[0], mParts[1])
}

能够看到go-micro间接把服务名称作为了package名称，这两者不能等同，不雷同时就会呈现问题。

网上也没有人提过这个问题，可能混合应用的人不多吧。于是我钻研了一下 go-micro 的源码，因为是生成的代码中短少信息，所以要解决这个问题还是得从protoc-gen-micro动手。

留神这里应用的是go-micro v4版本，其它版本未跟进。

客户端革新

针对客户端问题，我做了如下一些批改：

在生成客户端method时加上package，并间接生成gRPC格调method（go-micro外部其实反对这种格调），批改文件：cmd/protoc-gen-micro/plugin/micro/micro.go

func (g *micro) generateClientMethod(pkg, reqServ, servName, serviceDescVar string, method *pb.MethodDescriptorProto, descExpr string) {
    reqMethod := fmt.Sprintf("%s.%s", servName, method.GetName())
    useGrpc := g.gen.Param["use_grpc"]
    if useGrpc != "" {
        reqMethod = fmt.Sprintf("/%s.%s/%s", pkg, servName, method.GetName())
    }
...

因为还要向前兼容，不能影响现有用户，所以给这个逻辑加了一个开关，应用参数 use_grpc 才会利用新的生成形式。generateClientMethod 办法的 pkg 参数原来并没有，是新加的，从上下文中也比拟容易获取到。具体改变能够看这里：https://github.com/asim/go-mi…

当初如果明确只应用gRPC进行通信，或者须要和其它框架或者语言的gRPC应用程序通信，生成代码时能够这样做：

protoc --go_out=. --micro_out=. --micro_opt=use_grpc=1 xxx.proto

要害就是 –micro_opt=use_grpc=1，use_grpc这个参数会传递给 protoc-gen-micro，而后就能够在上边批改过的代码中获取到，不论这个参数的值是什么，只有应用了它，就会生成gRPC格调的带package的method。当初生成的代码是这样的：

req := c.c.NewRequest(c.name, "/Business.Hello/Say", in)

用这个客户端代理拜访其它框架或者语言开发的gRPC服务就没有问题了，当然拜访go-micro的gRPC服务也没有问题。

怎么获取到这个最新版的 protoc-gen-micro 呢？这个批改提了PR之后，目前曾经合并到官网的Github仓库中，然而还没有打tag，能够这样装置：

go install go-micro.dev/v4/cmd/protoc-gen-micro@1919048c8f20

这可能不是一个好的批改，因为还须要晓得有 use_grpc 这么个参数。必定还有别的批改计划，然而因为对go-micro理解的不多，所有只抉择了这个不会影响现有通信形式的计划。

服务端革新

服务端没有问题，别的框架或者开发语言的gRPC客户端能够调用基于go-micro的gRPC服务。

一开始我测试的时候也遇到了问题，先入为主的认为protoc-gen-micro生成的服务端也有package的问题，因而还提交了个PR，而后被啪啪打脸。而后我又读了读源码，发现go-micro服务端特地奇妙的把客户端申请中的package信息擦除了，所以客户端是否传递package都没有影响，反正服务端不须要。

服务端的注册逻辑在 plugins/server/grpc/server.go 中的 register 办法：

s := new(service)
s.typ = reflect.TypeOf(rcvr)
s.rcvr = reflect.ValueOf(rcvr)
sname := reflect.Indirect(s.rcvr).Type().Name()
...
server.serviceMap[s.name] = s

能够看到这里间接用反射获取的类型名称作为服务名称，没有package什么事。

而后接管到客户端的gRPC申请时，go-micro又把申请中的package擦除了。这段逻辑在 plugins/server/grpc/grpc.go 中的 handler 办法中：

serviceName, methodName, err := mgrpc.ServiceMethod(fullMethod)
service := g.rpc.serviceMap[serviceName]

通过 mgrpc.ServiceMethod 获取服务名称时去掉了package名称，所以客户端带不带package都没有问题。

运行成果

当初把程序跑起来，试试用 protoc-gen-micro 生成的客户端拜访 基于 protoc-gen-go-grpc 的服务端。

以上就是本文的次要内容，示例代码曾经上传到Github，欢送拜访：https://github.com/bosima/go-…