背景
gRPC是Google開始的一個RPC服務框架, 是英文全名為Google Remote Procedure Call的簡稱。
廣泛的應用在有RPC場景的業務系統中,一些架構中將gRPC請求都經過一個gRPC服務代理節點或閘道器,進行服務的許可權限制,限流,服務呼叫監控,增加請求統計等等諸多功能。
如下以Golang和gRPC為例,簡要分析gRPC的轉發原理。
gRPC Proxy原理
基本原理如下
基於TCP啟動一個gRPC代理服務端
攔截gRPC框架的服務,能將gRPC請求的服務攔截到轉發代理的一個函式中執行。
接收客戶端的請求,處理業務指標後轉發給服務端。
接收服務端的響應,處理業務指標後轉發給客戶端。
基於如上原理描述,如下圖所示,gRPC的客戶端將所有的請求都發給gRPC Server Proxy,這個代理閘道器實現請求轉發。
將gRPC Client的請求流轉發到gRPC 服務實現的節點上。並將服務處理結果響應返回給客戶端。
在這個圖中的轉發需要回答如下幾個問題
Proxy怎麼知道哪些請求轉發到哪些服務節點上,轉發的依據是什麼?
Proxy是否需要解析gRPC協議?
Proxy上沒有服務的實現,該如何轉發?
簡化的gRPC服務處理流程
在回答如下問題之前,我們先簡單的分析一下gRPC伺服器的實現原理和流程。
編寫自己的服務實現,例子中以HelloWorld為例。
把自己的服務實現HelloWorldServer註冊到gRPC框架中
建立一個TCP的服務端監聽
基於TCP監聽啟動一個gRPC服務
gRPC服務接收gRPC客戶端的TCP請求
解析gRPC的頭部資訊,找出服務名
根據服務名找到第一步註冊的服務和方法實現處理器handler
處理函式執行
返回處理結果
簡化的註冊服務處理器函式,啟動gRPC服務,呼叫請求和執行資料流圖如下所示:
詳細的gRPC服務執行原理
第一步,定義和編寫HelloWorld的IDL檔案
syntax = “proto3”;package demoapi;// HelloWorld Serviceservice HelloWorldService { rpc HelloWorld(HelloWorldRequest) returns (HelloWorldResponse){};}// Request messagemessage HelloWorldRequest { string request = 1;}// Response messagemessage HelloWorldResponse { string respose = 1;}
在這個簡單的IDL中,定義了一個HelloWorldService的gRPC服務Service,這個服務中有一個HelloWorld方法Method。
第二步,編譯IDL檔案
將IDL的proto檔案編譯成helloworld。pb。go的gRPC程式碼檔案。
生成的程式碼檔案中,我們可以看到如下資訊
// Hello World的客戶端介面type HelloWorldServiceClient interface { HelloWorld(ctx context。Context, in *HelloWorldRequest, opts 。。。grpc。CallOption) (*HelloWorldResponse, error)}// Hello World的服務端介面type HelloWorldServiceServer interface { HelloWorld(context。Context, *HelloWorldRequest) (*HelloWorldResponse, error)}// HelloWorld的服務註冊處理器函式Handlerfunc _HelloWorldService_HelloWorld_Handler(srv interface{}, ctx context。Context, dec func(interface{}) error, interceptor grpc。UnaryServerInterceptor) (interface{}, error) { in := new(HelloWorldRequest) if err := dec(in); err != nil { return nil, err } if interceptor == nil { return srv。(HelloWorldServiceServer)。HelloWorld(ctx, in) } info := &grpc。UnaryServerInfo{ Server: srv, FullMethod: “/demoapi。HelloWorldService/HelloWorld”, } handler := func(ctx context。Context, req interface{}) (interface{}, error) { return srv。(HelloWorldServiceServer)。HelloWorld(ctx, req。(*HelloWorldRequest)) } return interceptor(ctx, in, info, handler)}// gRPC服務註冊的服務描述資訊// gRPC服務註冊時,會建立以ServiceName為Key,Methods為Value的一個Map對映// Methods中的Handler就是如上的服務處理Handlervar _HelloWorldService_serviceDesc = grpc。ServiceDesc{ ServiceName: “demoapi。HelloWorldService”, HandlerType: (*HelloWorldServiceServer)(nil), Methods: []grpc。MethodDesc{ { MethodName: “HelloWorld”, Handler: _HelloWorldService_HelloWorld_Handler, }, }, Streams: []grpc。StreamDesc{}, Metadata: “demoapi/HelloWorld。proto”,}
如上程式碼中有如下幾個關鍵資訊需要解釋
服務Service名稱 demoapi。HelloWorldService,對應IDL檔案的package包名。service服務名稱
方法Method名稱 HelloWorld,對應IDL檔案的rpc方法
第三步,註冊HelloWorld服務到gRPC的服務對映中
grpc。ServiceDesc是 gRPC服務註冊的服務描述資訊。
gRPC服務註冊時,會建立以ServiceName為Key,包裝Methods為Value的一個Map對映m。
Methods中的Handler就是如上的服務處理Handler。
對應的註冊程式碼如下
// 註冊gRPC服務func RegisterHelloWorldServiceServer(s *grpc。Server, srv HelloWorldServiceServer) { s。RegisterService(&_HelloWorldService_serviceDesc, srv)}// Server is a gRPC server to serve RPC requests。type Server struct { // 。。。 m map[string]*service // service name -> service info}// gRPC service。go的服務註冊func (s *Server) register(sd *ServiceDesc, ss interface{}) { srv := &service{ server: ss, md: make(map[string]*MethodDesc), sd: make(map[string]*StreamDesc), mdata: sd。Metadata, } for i := range sd。Methods { d := &sd。Methods[i] srv。md[d。MethodName] = d } for i := range sd。Streams { d := &sd。Streams[i] srv。sd[d。StreamName] = d } s。m[sd。ServiceName] = srv}
第四步,接收客戶端gRPC請求並處理
在這一步中,會進行如下幾個步驟和函式的呼叫,也會回答前面的第一個問題。
gRPC客戶端透過TCP連結,連線到gRPC服務端
gRPC的Serve函式觸發TCP的Accept函式呼叫,生成一個和客戶端的網路連線
grpc框架程式碼執行handleRawConn方法,將這個網路連線設定打破gRPC的傳輸層,做為網路的讀和寫實現
依次呼叫grpc流的handlerStream方法,用於處理gRPC資料流
這個函式中會接收gRPC請求的頭資訊,並解析得到服務名 如第二步中的服務名 demoapi。HelloWorldService
透過如下的服務名中的方法名HelloWorld,並在Method的map中找到這個方法的處理器函式Handler,並執行這個Handler函式,實現gRPC服務的呼叫
最後將處理結果返回
整體的資料流整理如下:
我們發現在gRPC框架程式碼中的handleStream存在兩類服務,
一類是已知服務 knownService, 第二類是unknownService
這兩個有什麼區別呢?
已知服務 knownService就是gRPC服務端程式碼註冊到gRPC框架中的服務,叫做已知服務,其他沒有註冊的服務叫做未知服務。
為什麼我們要提到這個未知服務unknownService呢?著就是我們實現gRPC服務程式碼的關鍵所在,是前面問題三的答案,
要實現gRPC服務代理,我們在建立grpc服務grpc。NewServer時,傳遞一個未知服務的handler,將未知服務的處理進行接管,然後透過註冊的這個Handler實現gRPC代理轉發的邏輯。
基於如下描述,gRPC代理的原理如下圖所示:
建立grpc服務時,註冊一個未知服務處理器Handler和一個自定義的編碼Codec編碼和解碼,此處使用proto標準的Codec(回答前面第二個問題)
這個handle給業務方預留一個director的介面,用於代理重定向轉發的grpc連接獲取,這樣proxy就可以透過redirector得到gRPCServer的grpc連線。
proxy接收gRPC客戶端的連線,並使用gRPC的RecvMsg方法,接收客戶端的訊息請求
proxy將接收到的gRPC客戶端訊息請求,透過SendHeader和SendMsg方法傳送給gRPC服務端。
同樣的方法,RecvMsg接收gRPC服務端的響應訊息,使用SendMsg傳送給gRPC客戶端。
至此gRPC程式碼服務就完成了訊息的轉發功能,企業的限流,許可權等功能可以透過轉發的功能進行攔截處理。
gRPC Proxy的實現邏輯如下圖所示:
gRPC 代理服務的關鍵程式碼如下所示:
服務端到客戶端的轉發
// 轉發服務端的資料流到客戶端func (s *handler) forwardServerToClient(src grpc。ServerStream, dst grpc。ClientStream) chan error { ret := make(chan error, 1) go func() { f := &frame{} for i := 0; ; i++ { if err := src。RecvMsg(f); err != nil { ret <- err // this can be io。EOF which is happy case break } if err := dst。SendMsg(f); err != nil { ret <- err break } } }() return ret}
客戶端到服務端的轉發
// 轉發客戶端的資料流到服務端func (s *handler) forwardClientToServer(src grpc。ClientStream, dst grpc。ServerStream) chan error { ret := make(chan error, 1) go func() { f := &frame{} for i := 0; ; i++ { if err := src。RecvMsg(f); err != nil { ret <- err // this can be io。EOF which is happy case break } if i == 0 { // This is a bit of a hack, but client to server headers are only readable after first client msg is // received but must be written to server stream before the first msg is flushed。 // This is the only place to do it nicely。 md, err := src。Header() if err != nil { ret <- err break } if err := dst。SendHeader(md); err != nil { ret <- err break } } if err := dst。SendMsg(f); err != nil { ret <- err break } } }() return ret}