最近我們 dubbo-go 社群裡面，呼聲很大的一個 feature 就是對 gRPC 的支援。在某位大佬的不懈努力之下，終于弄出來了。
今天我就給大家分析一下大佬是怎麼連接配接 dubbo-go 和 gRPC 。
gRPC
先來簡單介紹一下 gRPC 。它是 Google 推出來的一個 RPC 架構。gRPC是通過 IDL ( Interface Definition Language )——接口定義語言——編譯成不同語言的用戶端來實作的。可以說是RPC理論的一個非常非常标準的實作。
因而 gRPC 天然就支援多語言。這幾年，它幾乎成為了跨語言 RPC 架構的标準實作方式了，很多優秀的rpc架構，如 Spring Cloud 和 dubbo ，都支援 gRPC 。
server 端
在 Go 裡面，server 端的用法是：
它的關鍵部分是：
s := grpc.NewServer()
和
pb.RegisterGreeterServer(s, &server{})
兩個步驟。第一個步驟很容易，唯獨第二個步驟
RegisterGreeterServer
有點麻煩。為什麼呢？
因為
pb.RegisterGreeterServer(s, &server{})
這個方法是通過使用者定義的
protobuf
編譯出來的。
好在，這個編譯出來的方法，本質上是：
也就是說，如果我們在 dubbo-go 裡面拿到這個 _Greeter_serviceDesc ，就可以實作這個 server 的注冊。是以，可以看到，在 dubbo-go 裡面，要解決的一個關鍵問題就是如何拿到這個 serviceDesc 。
Client 端
Client 端的用法是：
這個東西要複雜一點：
1、建立連接配接：conn, err := grpc.Dial(address)
2、建立client：c := pb.NewGreeterClient(conn)
3、調用方法：r, err := c.SayHello(ctx, &pb.HelloRequest{Name: name})
第一個問題其實挺好解決的，畢竟我們可以從使用者的配置裡面讀出 address ；
第二個問題就是最難的地方了。如同 RegisterGreeterServer 是被編譯出來的那樣，這個 NewGreeterClient 也是被編譯出來的。
而第三個問題，乍一看是用反射就能解決，但是我們打開 SayHello 就能看到：
結合 greetClient 的定義，很容易看到，我們的關鍵就在于 err := c.cc.Invoke ( ctx, "/helloworld.Greeter/SayHello", in, out, opts... )。換言之，我們隻需要建立出來連接配接，并且拿到方法、參數就能通過類似的調用來模拟出 c.SayHello 。
通過對 gRPC 的簡單分析，我們大概知道要怎麼弄了。還剩下一個問題，就是我們的解決方案怎麼和 dubbo-go 結合起來呢？
設計
我們先來看一下 dubbo-go 的整體設計，思考一下，如果我們要做 gRPC 的适配，應該是在哪個層次上做适配。
我們根據前面介紹的 gRPC 的相關特性可以看出來，gRPC 已經解決了 codec 和 transport 兩層的問題。
而從 cluster 往上，顯然 gRPC 沒有涉及。于是，從這個圖裡面我們就可以看出來，要做這種适配，那麼 protocol 這一層是最合适的。即，我們可以如同 dubbo protocol 那般，擴充出來一個 grpc protocol 。
這個 gRPC protocol 大體上相當于一個擴充卡，将底層的 gRPC 的實作和我們自身的 dubbo-go 連接配接在一起。
實作
在 dubbo-go 裡面，和 gRPC 相關的主要是：
我們直接進去看看在 gRPC 小節裡面提到的要點是如何實作的。
server端
這樣看起來，還是很清晰的。如同 dubbo- go 其它的 protocol 一樣，先拿到 service ，而後通過 service 來拿到 serviceDesc ，完成服務的注冊。
注意一下上圖我紅線标準的 ds, ok := service.(DubboGrpcService) 這一句。
為什麼我說這個地方有點奇怪呢？是因為理論上來說，我們這裡注冊的這個 service 實際上就是 protobuf 編譯之後生成的 gRPC 服務端的那個 service ——很顯然，單純的編譯一個 protobuf 接口，它肯定不會實作 DubboGrpcService 接口：
那麼 ds, ok := service.(DubboGrpcService) 這一句，究竟怎麼才能讓它能夠執行成功呢？
我會在後面給大家揭曉這個謎底。
Client端
dubbo-go 設計了自身的 Client ，作為對 gRPC 裡面 Client 的一種模拟與封裝：
注意看，這個 Client 的定義與前面 greetClient 的定義及其相似。再看下面的 NewClient 方法，裡面也無非就是建立了連接配接 conn ，而後利用 conn 裡建立了一個 Client 執行個體。
注意的是，這裡面維護的 invoker 實際上是一個 stub 。
當真正發起調用的時候：
紅色框框框住的就是關鍵步驟。利用反射從 invoker ——也就是 stub ——裡面拿到調用的方法，而後通過反射調用。
代碼生成
前面提到過 ds, ok := service.(DubboGrpcService) 這一句，面臨的問題是如何讓 protobuf 編譯生成的代碼能夠實作 DubboGrpcService 接口呢？
有些小夥伴可能也注意到，在我貼出來的一些代碼裡面，反射操作會根據名字來擷取method執行個體，比如NewClient方法裡面的method := reflect.ValueOf(impl).MethodByName("GetDubboStub")這一句。這一句的impl，即指服務的實作，也是 protobuf 裡面編譯出來的，怎麼讓 protobuf 編譯出來的代碼裡面含有這個 GetDubboStub 方法呢？
到這裡，答案已經呼之欲出了：修改 protobuf 編譯生成代碼的邏輯！
慶幸的是，在 protobuf 裡面允許我們通過插件的形式擴充我們自己的代碼生成的邏輯。
是以我們隻需要注冊一個我們自己的插件：
然後這個插件會把我們所需要的代碼給嵌入進去。比如說嵌入
GetDubboStub
方法：
還有
DubboGrpcService
接口：
這個東西，屬于難者不會會者不難。就是如果你不知道可以通過
plugin
的形式來修改生成的代碼，那就是真難；但是如果知道了，這個東西就很簡單了——無非就是水磨工夫罷了。
作者資訊：鄧明，畢業于南京大學，就職于 eBay Payment 部門，負責退款業務開發。