解決go-micro與其它gRPC框架之間的通信問題

在之前的文章中分別介紹了使用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

識訓更多架構知識，請關注微信公眾號 螢火架構，原創內容，轉載請注明出處，

標籤：其他

上一篇：【大話云原生】微服務篇-五星級酒店的服務方式

下一篇：VS配置屬性存盤在哪里