作者：Luc Perkins

我代表雲原生計算基金會，很高興地宣布gRPC-Web的GA版本，這是一個JavaScript客戶端庫，使Web應用程序能夠直接與後端gRPC服務通信，而不需要HTTP伺服器充當中介。這意味著您現在可以通過使用 .proto 文件定義客戶端 和伺服器端數據類型和服務介面，輕鬆構建真正的端到端gRPC應用程序體系結構 。因此，gRPC-Web為整個REST開發Web範例提供了一個引人注目的新選擇。

一 基礎

gRPC-Web使您能夠在客戶端Web應用程序和後端gRPC伺服器之間定義服務「契約」，使用 .proto 定義和自動生成客戶端JavaScript （您可以在 Closure 編譯器JavaScript或更廣泛使用的 CommonJS 之間進行選擇）。您可以放棄這些開發過程：創建自定義JSON序列化和反序列化邏輯，處理HTTP狀態代碼（可能因REST API而異），內容類型協商等。

從更廣泛的架構角度來看，gRPC-Web使端到端gRPC成為可能。下圖說明了這一點：

在左側的gRPC-Web世界中，客戶端應用程序發送Protocol Buffers到gRPC後端伺服器，該伺服器發送Protocol Buffers到其他gRPC後端服務。在右側的REST世界中，Web應用程序將HTTP發送到後端REST API伺服器，然後該伺服器將發送Protocol Buffers到其他後端服務。

需要明確的是，REST應用程序本身沒有任何問題。使用REST API伺服器構建了大量非常成功的應用程序，這些伺服器使用非HTTP協議與後端服務進行通信。但是想像一下，這些應用程序的開發過程圍繞一個協議和一組 .proto 介面（以及一組服務合同）聯合起來，您幾乎可以感受到無數小時的節省和頭痛的避免。gRPC-Web的好處不僅僅是「技術」；也是組織的。明亮的橙色線不僅僅是一個不同的協議 - 它是一個獨立的工作和認知負荷來源，你現在可以很容易地變成亮綠色。

二 使用gRPC-Web的優點

隨著時間的推移，gRPC-Web將提供更廣泛的功能集。但我可以看到它從一開始就提供了一些巨大的便利：

  • 端到端gRPC - 如上所述，使用gRPC-Web，您可以正式從堆棧中刪除REST組件並將其替換為純gRPC，從而使您能夠使用Protocol Buffers創建 整個RPC管道。想像一下客戶端請求轉到HTTP伺服器的情況，然後HTTP伺服器與5個後端gRPC服務進行交互。您花費在構建HTTP交互層的時間可能跟構建整個管道的其餘部分一樣多。
  • 前端和後端團隊之間更緊密的合作 - 回想上面的圖表。使用Protocol Buffers定義整個RPC管道，您不再需要將「微服務團隊」與「客戶團隊」並肩。客戶端與後端交互只是一個gRPC層。老實說，我還沒有完全掌握端到端測試，服務網格集成，持續集成/交付等方面的含義。
  • 輕鬆生成客戶端庫 - 使用gRPC-Web，與「外部」世界交互的伺服器，即將後端堆棧連接到互聯網的隔膜，現在是gRPC伺服器而不是HTTP伺服器，這意味著您的所有服務都是客戶端庫可以是gRPC庫。 需要Ruby，Python，Java和其他4種語言的客戶端庫嗎？您不再需要為所有這些客戶端編寫HTTP客戶端。

三 一個gRPC-Web示例

上一節介紹了gRPC-Web在大規模應用中的一些高級優勢。 現在讓我們通過一個例子來展示：一個簡單的TODO應用程序。在gRPC-Web中，您可以從一個簡單的 todos.proto 定義開始，如下所示：

syntax = 「proto3」;
package todos;
message Todo {
string content = 1;
bool finished = 2;
}
message GetTodoRequest {
int32 id = 1;
}
service TodoService {
rpc GetTodoById (GetTodoRequest) returns (Todo);
}

您可以使用該 .proto 定義使用 protoc 命令行工具生成CommonJS客戶端代碼 ：

protoc echo.proto
--js_out=import_stylex=commonjs:./output
--grpc-web_out=import_stylex=commonjs:./output

現在從後端gRPC伺服器獲取TODO列表可以這麼簡單：

const {GetTodoRequest} = require(『./todos_pb.js』);
const {TodoServiceClient} = require(『./todos_grpc_web_pb.js』);
const todoService = new proto.todos.TodoServiceClient(『http://localhost:8080』);
const todoId = 1234;
var getTodoRequest = new proto.todos.GetTodoRequest();
getTodoRequest.setId(todoId);
var metadata = {};
var getTodo = todoService.getTodoById(getTodoRequest, metadata, (err, response) => {
if (err) {
console.log(err);
} else {
const todo = response.todo();
if (todo == null) {
console.log(`A TODO with the ID ${todoId} wasn』t found`);
} else {
console.log(`Fetched TODO with ID ${todoId}: ${todo.content()}`);
}
}
});

同樣，沒有HTTP代碼或方法，沒有JSON解析，沒有頭協商。您聲明了數據類型和服務介面，並且gRPC-Web摘錄了所有「硬接線」樣板，為您提供了一個乾淨且人性化的API（基本上與當前用於gRPC API的Node.js相同的API ，只是轉移到客戶端）。

在後端，gRPC伺服器可以用任何支持gRPC的語言編寫，包括Go，Java，C ++，Ruby，Node.js等等（請參閱官方gRPC文檔中的語言特定文檔 ）。最後一塊拼圖是服務代理。從一開始，gRPC-Web將支持 Envoy 作為默認服務代理，它具有內置的 envoy.grpc_web 過濾器，只需幾行複製和可配置配置即可應用。 我很快就會在 Envoy博客 上詳細說明這一點 。

四 下一步

邁向GA意味著核心構建塊已牢固到位，可以在生產Web應用程序中使用。但是gRPC-Web還有很多其他的東西要來。查看官方路線圖，了解核心團隊在不久的將來所設想的內容。

如果您有興趣為gRPC-Web做出貢獻，那麼核心團隊會喜歡社區幫助的一些事項：

  • 前端框架集成 - 常用的前端框架（如 React，Angular 和 Vue）尚未提供對gRPC-Web的官方支持。但我們希望看到這些框架能夠支持它，因為每個框架都會從gRPC中受益匪淺。
  • 特定於語言的代理支持 - 從GA版本開始，Envoy 是gRPC-Web的默認代理，通過特殊模塊提供支持。但我們也很樂意看到特定語言的進程內代理的開發。進程內代理消除了對特殊代理的需求 - 例如Envoy和nginx - 並且使得使用gRPC-Web變得更加容易。

我們也很樂意收到社區的功能請求。目前，提出功能請求的最佳方法是填寫 gRPC-Web路線圖功能調查。只需列出您想要查看的功能，並告訴我們您是否願意為這些功能的開發做出貢獻 。gRPC-Web工程師一定會在項目開發過程中牢記這些信息。

號外！最新K8S Meetup深圳站

活動時間：2018.11.10 13:00-17:00

活動地點：深圳市南山區海天二路33號騰訊濱海大廈北塔3F多功能廳

Topics：

Kubernetes集群安全配置與集成（周亮宇，騰訊雲高級工程師）

易捷行雲EasyStack基於Kubernetes的spinnaker實踐分享（曹永亮，EasyStack雲架構師）

Istio調用鏈埋點原理剖析——是否真的「零修改」？（張超盟，華為雲微服務平台架構師）

淺談企業微服務架構轉型（王煒，騰訊雲高級工程師）

報名鏈接：11.10坐標深圳@容器新大陸尋寶會，兄台敢來？ -百格活動


推薦閱讀：
相关文章