共计 3323 个字符，预计需要花费 9 分钟才能阅读完成。
在之前的文章中别离介绍了应用 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-…
播种更多架构常识，请关注微信公众号 萤火架构。原创内容，转载请注明出处。
