開發(fā)基于 gRPC 協(xié)議的 Node 服務(wù)

前言

在 Shopee 任職期間，我在開發(fā) gRPC 協(xié)議的 node 微服務(wù)時有過不錯的一些實踐，配置中心、差分服務(wù)、官網(wǎng)服務(wù)等。因此我寫下這篇文章，做一些些的總結(jié)，記錄一下碰到的問題、解決的方法以及一些個人的小小見解。

這篇文章主要會介紹一下在前端領(lǐng)域使用 gRPC 協(xié)議的方法、使用時碰到的一些問題以及目前開源社區(qū)的一些反應(yīng)。所有的內(nèi)容不僅出自個人的感受，還會有一些相應(yīng)的資料作為支撐。文章里面不會有具體的實現(xiàn)細(xì)節(jié)，我覺得沒太必要，官方文檔告訴你得更多更準(zhǔn)確，更多的可能會是一些方法論的內(nèi)容。

開始之前給大家簡單介紹一下 gRPC 的背景知識，有基礎(chǔ)的同學(xué)可以直接跳過。

What is gRPC？

gRPC is a modern, open source remote procedure call (RPC) framework that can run anywhere. It enables client and server applications to communicate transparently, and makes it easier to build connected systems.

Read the longer Motivation & Design Principles^[1] post for background on why we created gRPC.

gRPC 是一個由 Google 推出的、高性能、開源、通用的 rpc 框架。它是基于 HTTP2 協(xié)議標(biāo)準(zhǔn)設(shè)計開發(fā)，默認(rèn)采用 Protocol Buffers 數(shù)據(jù)序列化協(xié)議，支持多種開發(fā)語言。通俗說就是一種 Google 設(shè)計的二進(jìn)制rpc協(xié)議。

What is protobuf？

hello.pb

// The greeter service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

gRPC 協(xié)議是基于 protobuf 進(jìn)行通信的。開發(fā)者在 protobuf 文件里面定義詳細(xì)的 service，message。在 messgae 內(nèi)部，為請求、返回的字段定義精確的數(shù)據(jù)類型。protobuf 文件再通過編譯成各種語言版本的文件，提供給 grpc 服務(wù)的 server、client 使用。

server & client 的使用

動態(tài)編譯

官方提供了 node-grpc 類庫，為 node 端使用 gRPC 協(xié)議提供了一系列的支持。其中 `packages/proto-loader`^[2] 提供了一個動態(tài)編譯 protobuf 文件的功能。它會將一個 protobuf 文件內(nèi)的 server 轉(zhuǎn)化成一個實例對象返回。如下我們就獲取了一個 routeguide 對象，然后我們就可以使用這個對象去做接口訪問或者創(chuàng)建一個server。

var PROTO_PATH = __dirname + '/../../../protos/hello.proto';
var grpc = require('@grpc/grpc-js');
var protoLoader = require('@grpc/proto-loader');
// Suggested options for similarity to existing grpc.load behavior
var packageDefinition = protoLoader.loadSync(
    PROTO_PATH,
    {keepCase: true,
     longs: String,
     enums: String,
     defaults: true,
     oneofs: true
    });
var protoDescriptor = grpc.loadPackageDefinition(packageDefinition);
// The protoDescriptor object has the full package hierarchy
var helloObj = protoDescriptor.hello;

使用 helloObj 對象為創(chuàng)建 gRPC server 提供 protobuf 對象的定義

import grpc from "@grpc/grpc-js";

// 具體方法實現(xiàn)可以去看官方的樣例。
// https://grpc.io/docs/languages/node/basics/
// 這里的方法都是（call，callback，metedata）=>{} 類型的。
// 這里只舉一個例子
function sayHello(call,callback) {
  // do something
  callback();
}

function getServer() {
  var server = new grpc.Server();
  server.addService(helloObj.Greeter.service, {
    sayHello: sayHello,
  });
  return server;
}

var greeterServer = getServer();
greeterServer.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), () => {
 routeServer.start();
});

使用 helloObj 對象建立 gRPC 連接

真正應(yīng)用于業(yè)務(wù)時，服務(wù)具體接口的實現(xiàn)及代碼結(jié)構(gòu)應(yīng)該要更有邏輯，這里只是作為調(diào)用樣例展示。

var client = new helloObj.Greeter('localhost:50051',
                                       grpc.credentials.createInsecure());

function sayHello(callback) {
  const helloReq = {
    name: "you"
  };
  var call = client.sayHello(name, function(err, response) {
    console.log('Greeting:', response.message);
  });
}

靜態(tài)編譯

使用官方的類庫 grpc-tools，編譯生成 _pb.d.ts 和 _grpc_pb.d.ts 文件，前者將 protobuf 里面的 message、enum 等定義生成代碼的具體實現(xiàn)，后者則生產(chǎn) client、server 的接口及具體的類。下面的例子會列舉 hello_pb.d.ts 及 hello_grpc_pb.d.ts 文件這個例子。

因為有生成 ts 聲明文件，因此在靜態(tài)編譯時，我們也因此可以使用 ts 類型啦。

// hello_pb.d.ts 里面 HelloRequest 的定義
import * as jspb from "google-protobuf";

export class HelloRequest extends jspb.Message { 
    getName(): string;
    setName(value: number): HelloRequest;
  
    serializeBinary(): Uint8Array;
    toObject(includeInstance?: boolean): HelloRequest.AsObject;
    static toObject(includeInstance: boolean, msg: Book): HelloRequest.AsObject;
}
                        
export namespace HelloRequest {
    export type AsObject = {
        name: string,
    }

hello_grpc_pb.d.ts 的 GreeterClient，第一個參數(shù)接收 address（即服務(wù)地址），生成可調(diào)用的 client 去訪問 server。目前最新的版本支持 uds、dns 兩種格式，如果需要支持 etcd，需要自行實現(xiàn)官方的 resolver 去做 etcd 地址的解析及獲取。^[3]

// hello_grpc_pb.d.ts 文件里面截取需要的內(nèi)容

import * as hello_pb from "./hello_pb";
import * as grpc from "@grpc/grpc-js";

interface IGreeterService extends grpc.ServiceDefinition<grpc.UntypedServiceImplementation> {
    sayHello: IGreeterServiceService_ISayHello;
}
export const GreeterService: IGreeterService;
                        
                        
export class GreeterClient extends grpc.Client {
  constructor(address: string, credentials: grpc.ChannelCredentials, options?: object);
  sayHello(
    argument: helloworld_pb.HelloRequest,
    callback: grpc.requestCallback<helloworld_pb.HelloReply>
  ): grpc.ClientUnaryCall;
  sayHello(
    argument: helloworld_pb.HelloRequest,
    metadataOrOptions: grpc.Metadata | grpc.CallOptions | null,
    callback: grpc.requestCallback<helloworld_pb.HelloReply>
  ): grpc.ClientUnaryCall;
  sayHello(
    argument: helloworld_pb.HelloRequest,
    metadata: grpc.Metadata | null,
    options: grpc.CallOptions | null,
    callback: grpc.requestCallback<helloworld_pb.HelloReply>
  ): grpc.ClientUnaryCall;
}

使用靜態(tài)文件建立服務(wù)

import {GreeterService, IGreeterService} from "./proto/hello_grpc_pb";

function sayHello(call,callback,metedata){
  // do something
  callback();
}

function main() {
  var server = new grpc.Server();
  server.addService(GreeterService,
                         {sayHello: sayHello});
  server.bindAsync('0.0.0.0:50051', grpc.ServerCredentials.createInsecure(), () => {
    server.start();
  });
}

使用靜態(tài)文件建立 Client 連接

import { GreeterClient } from "./proto/hello_grpc_pb";
import { HelloRequest, HelloReply } from "./proto/hello_pb";

const client = new GreeterClient("127.0.0.1:50051", grpc.credentials.createInsecure());

const helloRequest = new HelloRequest();
helloRequest.setName('hello world!')

// 完成一次調(diào)用
client.sayHello(request, (err, reply: HelloReply) => {
  if (err != null) {
    debug(`[sayHello] err:\nerr.message: ${err.message}\nerr.stack:\n${err.stack}`);
    reject(err); return;
  }
  log(`[sayHello] HelloReply: ${JSON.stringify(reply.toObject())}`);
  resolve(book);
});

二進(jìn)制rpc協(xié)議？

這里用一張圖簡單解釋一下，一次gRPC請求發(fā)生的事情。就以客戶端發(fā)起一次sayHello請求為例。

如果是動態(tài)調(diào)用的話，在序列化HelloRequest前還有一個步驟。json對象向HelloRequest的轉(zhuǎn)化。

Why use gRPC?

在版本推進(jìn)的過程中，ShopeePay 的前端團(tuán)隊承接的一些內(nèi)容越來越多，從最開始簡單的微服務(wù)接口的合并轉(zhuǎn)發(fā)、到技術(shù)項目以 node 服務(wù)實現(xiàn)、再到部分業(yè)務(wù)服務(wù)直接由 node 承擔(dān)。那為什么 shopee 的前端 node 服務(wù)要使用 gRPC 呢？直接使用 http 協(xié)議的 koa、express 開源框架不香嗎？

其實最開始的時候，最早有一些 node 服務(wù)是用 http 協(xié)議去實現(xiàn)的。但是隨著基建漸漸成熟、開發(fā)環(huán)境逐漸穩(wěn)定、前端尋求承擔(dān)團(tuán)隊更多的業(yè)務(wù)職責(zé)之后，我們最終還是開始使用 gRPC。那除了上面介紹的 gRPC 二進(jìn)制流協(xié)議本身的優(yōu)勢之外，這里當(dāng)然也有一部分是為了開發(fā)環(huán)境的兼容。

協(xié)議同步

在微服務(wù)的架構(gòu)中，前后端網(wǎng)關(guān)（grpc 微服務(wù)）和 node 微服務(wù)的通訊、后臺 go 微服務(wù)和 node 微服務(wù)的相互調(diào)用是避免不了。如果使用 http 服務(wù)，就會面臨協(xié)議溝通上的問題，即網(wǎng)關(guān)會增加特殊邏輯去訪問 http 接口、go 服務(wù)及網(wǎng)關(guān)訪問 node 的 http 服務(wù)時也無法直接發(fā)起 grpc 連接，http 服務(wù)也無法直接訪問一個 gRPC 服務(wù)。

下圖簡單的介紹了一下區(qū)別，當(dāng) http 服務(wù)的職責(zé)比較單一，或者是作為一個單純的”資源提供者“，那還是可以接受的，開發(fā)者需要在代碼里面重新定義新的網(wǎng)關(guān)地址，為該服務(wù)封裝新的 http 前綴地址；反之則是相對比較麻煩的。當(dāng)然總可以通過一些 hack 的手法去達(dá)到目的，但無疑都會增加很多的開銷，得不償失。

而在協(xié)議統(tǒng)一之后，我們的 gRPC 服務(wù)就與語言無關(guān)了。通訊時即不需要做特殊邏輯的代碼，又可以享受統(tǒng)一網(wǎng)關(guān)的支持、監(jiān)控平臺數(shù)據(jù)的采集等通用的功能支持，不需要自實現(xiàn)一套。

服務(wù)路由復(fù)雜化

ShopeePay 的線上環(huán)境是是部署在 Kubernetes 集群內(nèi)部的。由 ingress 分配給 pod 對應(yīng)的 ingress 域名，可以理解為內(nèi)部域名，只能在集群內(nèi)部訪問。線上環(huán)境，集群內(nèi)部不允許訪問任何公網(wǎng)域名，需要申請白名單。因此我們需要訪問集群內(nèi)的node服務(wù)的話，需要做以下幾件事情：

• 為集群內(nèi)的 node 服務(wù)申請公網(wǎng)域名，通過公網(wǎng)域名訪問。
• 同時也需要向運維申請對應(yīng)域名在集群內(nèi)部的訪問白名單權(quán)限。

帶來的后果就是，服務(wù)數(shù)量對應(yīng)申請的域名也越來越多，接口路由的這些職責(zé)本來就應(yīng)該由網(wǎng)關(guān)去承擔(dān)，但卻因此復(fù)雜化了。

同時就在前端網(wǎng)關(guān)中應(yīng)用的實際場景來說，前端網(wǎng)關(guān)適配了一些額外的 http 服務(wù)，既有業(yè)務(wù)相關(guān)，也有技術(shù)側(cè)相關(guān)的一些服務(wù)。當(dāng)用戶請求這些服務(wù)的接口時，會先去訪問前端網(wǎng)關(guān)，網(wǎng)關(guān)再去請求服務(wù)對外的公網(wǎng)域名，公網(wǎng)域名經(jīng)過 nginx 代理到 ingress 域名，然后才訪問到接口。

全鏈路

對于從客戶端發(fā)起一次請求，再到客戶端接收響應(yīng)，在復(fù)雜的業(yè)務(wù)場景里面整個鏈路是相當(dāng)長的，業(yè)務(wù)網(wǎng)關(guān)（gRPC 服務(wù)）會將唯一的 trace-id 存放在 metadata 里面，然后在一整個鏈路上傳遞下去。metedata 可以理解為 gRPC 協(xié)議的特有的 header，http 服務(wù)從協(xié)議層就無法獲取。如果鏈路中訪問的有 http 服務(wù)，那么一整個請求鏈路就會出現(xiàn)斷鏈，這樣對我們線上查找鏈路的錯誤日志會造成比較大的麻煩。

挑戰(zhàn)

其實拋開 gRPC 協(xié)議不談，開發(fā)微服務(wù)和普通的node服務(wù)沒什么差別。我們沒有使用 protobuf.js^[4]，它也使用 node 實現(xiàn)了 gRPC 協(xié)議，同時在我看來這個 gRPC 庫更靈活，可以攔截請求，完成一些比如 json 解析器等比較好用的事情，但是官方項目的 manager 認(rèn)為這種攔截請求并更改的行為是相當(dāng)不安全的，對比之下我們就堅持官方庫。

適配后臺網(wǎng)關(guān)

正好說到這個，在業(yè)務(wù)進(jìn)展的過程里，我們前后端其實都碰到了針對網(wǎng)關(guān)的優(yōu)化。對于網(wǎng)關(guān)這一主體來說，不應(yīng)該也不需要存儲任何 pb 文件的，鑒權(quán)的 pb 接口除外。之前介紹的時候有說過，gRPC 必須基于 gRPC 的 pb 文件通訊，不同語言編譯成不同的版本的源文件。那這里前后端是分別怎么解決這個問題的呢？

后端網(wǎng)關(guān)發(fā)送請求時傳遞一個標(biāo)志位和 json 數(shù)據(jù)，當(dāng) go 服務(wù)接收請求獲取到該標(biāo)志位時，就由服務(wù)側(cè)將 json 轉(zhuǎn)化為 go 服務(wù)需要的 pb struct 對象。從實現(xiàn)層看起來，就是網(wǎng)關(guān)傳遞 json，go 服務(wù)接收 json，協(xié)議沒變但是沒有涉及二進(jìn)制的轉(zhuǎn)換。

而前端服務(wù)因為底層庫直接給開發(fā)者的就是 call 對象，不支持?jǐn)r截請求。所以我們放棄了去更改，而是為接入后端網(wǎng)關(guān)時做了一層適配，我們采用了一個統(tǒng)一的 protobuf message，我們稱之 CommonMessage，發(fā)起請求和獲取請求都由 CommonMessage 去序列化、反序列化。因為 CommonMessage 的 messgae 只有一個二進(jìn)制，帶來的問題是，前端開發(fā)者調(diào)試的時候需要費一下心轉(zhuǎn)化哈哈。

CommonMessage 的pb定義

// The request message containing the common content.
message CommonMessage {
  byte content = 1;
}

grpc vs grpc-js

當(dāng)你打開 grpc-node^[5] 這個地址時，明晃晃的告訴大家，node 的 grpc 官方庫有兩個版本。一個是純 c 的 grpc，一個是純 js 的 grpc-js。在我們決定使用并開發(fā) grpc 微服務(wù)時，當(dāng)時的版本是 grpc，因此我們也經(jīng)歷的一次版本升級。這里不會詳細(xì)的介紹兩者的區(qū)別，因為沒有比這寫的更詳細(xì)的了。https://github.com/grpc/grpc-node/blob/master/PACKAGE-COMPARISON.md

當(dāng)然，推動我們更新大版本的動力是，grpc 在使用 http2 協(xié)議打包傳送的數(shù)據(jù)越大，性能就越差。而 grpc-js 則不會有這個性能損耗。之前面臨的一個問題，在我們的測試環(huán)境只傳遞 300KB 的數(shù)據(jù)為返回時，grpc 消耗 1000~2000ms，grpc-js 則維持在了 20~30ms。其余的遷移可以參考https://github.com/grpc/grpc-node/tree/master/packages/grpc-js

callback 參看兩個版本庫的源碼，可以知道它主要做了反序列化、打包的一些事情。

// grpc 源碼
/**
 * Send a response to a unary or client streaming call.
 * @private
 * @param {grpc.Call} call The call to respond on
 * @param {*} value The value to respond with
 * @param {grpc~serialize} serialize Serialization function for the
 *     response
 * @param {grpc.Metadata=} metadata Optional trailing metadata to send with
 *     status
 * @param {number=} [flags=0] Flags for modifying how the message is sent.
 */
function sendUnaryResponse(call, value, serialize, metadata, flags) {
  // a 
  var end_batch = {};
  var statusMetadata = new Metadata();
  var status = {
    code: constants.status.OK,
    details: 'OK'
  };
  if (metadata) {
    statusMetadata = metadata;
  }
  var message;
  try {
    message = serialize(value);
  } catch (e) {
    common.log(constants.logVerbosity.ERROR, e);
    e.code = constants.status.INTERNAL;
    handleError(call, e);
    return;
  }
  status.metadata = statusMetadata._getCoreRepresentation();
  if (!call.metadataSent) {
    end_batch[grpc.opType.SEND_INITIAL_METADATA] =
        (new Metadata())._getCoreRepresentation();
    call.metadataSent = true;
  }
  message.grpcWriteFlags = flags;
  end_batch[grpc.opType.SEND_MESSAGE] = message;
  end_batch[grpc.opType.SEND_STATUS_FROM_SERVER] = status;
  // 打點
  // b
  call.startBatch(end_batch, function (){});
  // 打點 
  // c
}

在 grpc 庫的源碼里，a-b：組裝返回的 messge 和 metadata，b-c：使用 http2 發(fā)起請求。a-b 的序列化數(shù)據(jù)、打包數(shù)據(jù)耗時打點約為 1~2ms，主要的耗時都在 b-c 這一段代碼。startBatch 方法是用 c 實現(xiàn)的，無從優(yōu)化，因此只能選擇升級為 grpc-js。截止到寫這篇文章時，grpc 庫已經(jīng)處于 deprecated 狀態(tài)了。

擁抱？.開源社區(qū)

gRPC node 版本的開源生態(tài)感覺起來不是特別好。在 GitHub 上看一些項目 issue 查找問題的過程中，我時不時碰到這樣的回答 “放棄node，轉(zhuǎn)入go語言的懷抱”，因此常常不得不自己上手解決一些問題，比如為 grpc 協(xié)議 fork一個 node-grpc-interceptors^[6] （ctx 增加 response、增加 errorcallback）、壓測嘗試 grpc 是否支持 worker（多進(jìn)程）等等。這屬實讓人感受到一些沮喪，蓽露藍(lán)蔞的感受。

在 20 年 4 月份 @grpc/grpc-js 1.0.0^[7]正式發(fā)布之后，官方又開始迅速迭代。這反而引發(fā)了上文所說的 grpc-js 新舊版本的 Resolver 類不兼容，導(dǎo)致之前我們一位大神自定義的 etcd 的 Resolver 在新版本報錯的情況；proto-tools 的版本與 grpc-js 的版本有相對比較嚴(yán)格的定義；官方的實現(xiàn)的 plugin 插件與私人實現(xiàn)的 plugin 重名沖突，導(dǎo)致無法生成必要的 ts 文件等。為了解決這些問題，我們采取了一些不太合適的解決方式（固定版本等），但我相信隨著版本的逐漸穩(wěn)定，這些問題也就會不再出現(xiàn)。

新的 Protobuff 倉庫

Protobuff 是在 ShopeePay 做的一個管理前端 protobuff 文件、生成的 static 文件以及為網(wǎng)關(guān)類服務(wù)提供 proto client 對象的公共項目。

在 ShopeePay 的前端服務(wù)越來越來多的場景下，我們也不得不面對和業(yè)務(wù)服務(wù)一樣的問題，越來越多的服務(wù)對應(yīng)越來越多的 protobuff 文件及配置、node 服務(wù)的 gRPC 請求調(diào)用這樣的公共模塊（發(fā)起 gRPC 調(diào)用需要 proto 文件，一個服務(wù)的 proto 在多個服務(wù)的代碼里面維護(hù)）越來越強烈剝離出去的需求。

因此我們就做了這樣的一個公共倉庫，由于 grpc-js 不暴露任何接口攔截的可能，于是上文說的 json 解析器（json to protobuff message 對象）的應(yīng)用也就無從說起。那怎么做呢？最終我們采取了給前端網(wǎng)關(guān)提供一個存儲在內(nèi)存的 client 對象列表的方案（動態(tài)編譯），供網(wǎng)關(guān)服務(wù)調(diào)用接口使用。同時我們也手動實現(xiàn) etcd 的 resolver，注冊，解決了我們動態(tài)獲取 Kubernetes 部署的 pod的內(nèi)網(wǎng) ip 地址的需求。于是就完美的滿足了當(dāng)前的環(huán)境開發(fā)、使用的需求。

主要的受益在以下幾個方面：

• 前端網(wǎng)關(guān)是存儲 protobuff 文件的，但是在 node_modules 里面存放，所以服務(wù)、網(wǎng)關(guān)和 pb 文件是解耦的。
• 在網(wǎng)關(guān)類應(yīng)用時，靜態(tài)生成的類只有通過屬性的 set 方法才能設(shè)置，因此不被采納。所以網(wǎng)關(guān)類應(yīng)用獲益于這個項目，實現(xiàn)了 pb 配置和網(wǎng)關(guān)代碼的耦合。
• 發(fā)布上線時，從網(wǎng)關(guān)一份 pb、服務(wù)本身一份 pb、n 個調(diào)用方的 n 份 pb 的改動轉(zhuǎn)變?yōu)?Protobuff 倉庫的一份 pb。
• ...

總結(jié)

兜兜轉(zhuǎn)轉(zhuǎn)寫了很多，其實每一段內(nèi)容都可以更加深入的展開來講講。gRPC 協(xié)議的 ‘hello world’，一些為了推動前端微服務(wù)化在 ShopeePay 做的嘗試，在需求迭代時碰到的一些問題以及去解決的過程等等。gRPC 很好用也很不好用，很好用是指接入很方便、上手很快、性能很穩(wěn)定、日常需求 cover 很簡單，很不好用是指深入碰到問題得自己解決，目前的版本還在快速迭代等等。

即是總結(jié)語，也是展望語。

以上就是我在 ShopeePay 任職期間接觸 gRPC 相關(guān)的全部日常。感謝前老大 BrandonXiang、HeyLi 的在 Shopee 任職時提供的各方面的幫助，同時也很幸運在那個優(yōu)秀的前端團(tuán)隊內(nèi)擰了許久的螺絲釘（~_~）。展望即是，在新的團(tuán)隊也可以摸摸索索的前行，把自己不熟悉的領(lǐng)域變得熟悉起來，繼續(xù)擰好自己手里的那顆不太一樣的新螺絲釘。

關(guān)注我們

我們將為你帶來最前沿的前端資訊。