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

波斯馬發表於2022-04-22
GoRPC框架

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 的服務端。

go-micro+gRPC

以上就是本文的主要內容，示例程式碼已經上傳到Github，歡迎訪問：https://github.com/bosima/go-demo/tree/main/go-micro-grpc-hello-compatible

收穫更多架構知識，請關注微信公眾號 螢火架構。原創內容，轉載請註明出處。
掃描二維碼關注公眾號

相關文章