《大話雲原生》系列文章期望用最通俗、簡單的語言說明雲原生生態系統內的組成及應用關係。此專欄的前兩篇文章 《【大話雲原生】煮餃子與docker、kubernetes之間的關係》 《【大話雲原生】負載均衡篇-小飯館的流量變大了》 歡迎品鑒！ 一、服務接待中心與微服務網關 老婆最近快過生日了，我答應她去旅 ...
在之前的文章中分別介紹了使用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-micro/pull/2474/commits/0d435a690ea21a3f64b0534d1fa244f512601493
現在如果明確只使用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-demo/tree/main/go-micro-grpc-hello-compatible
收穫更多架構知識，請關註微信公眾號 螢火架構。原創內容，轉載請註明出處。
