歡迎光臨
每天分享高質量文章

NGINX 宣佈支援 gRPC,可在下個版本 1.13.10 中使用

來自:開源中國

連結:https://www.oschina.net/news/94342/nginx-1-13-10-grpc

近日,NGINX 在其部落格宣佈,NGINX 已完成對 gRPC 的原生支援,並將在下一個 OSS 版本 1.13.10 中提供使用,如果迫不及待希望嘗鮮,可下載 snapshot 快照來體驗一把,也可以給開發團隊反饋意見


而下一個 NGINX Plus 版本將引入對 gRPC 和 HTTP/2 伺服器推送的支援。


有了對 gRPC 的支援,NGINX 可以代理 gRPC TCP 連線,還可以終止、檢查和跟蹤 gRPC 的方法呼叫。你可以:


  • 釋出 gRPC 服務,然後使用 NGINX 應用 HTTP/2 TLS 加密、速率限制、基於 IP 的訪問控制串列和日誌記錄

  • 透過單個端點釋出多個 gRPC 服務,使用 NGINX 檢查並跟蹤每個內部服務的呼叫

  • 使用 Round Robin, Least Connections 或其他方法在叢集分配呼叫,對 gRPC 服務叢集進行負載均衡


關於  gRPC


gRPC是一種遠端過程呼叫協議,用於客戶端和伺服器應用程式之間的通訊。他具有緊湊(節省空間)和可跨多種語言移植的特點,並且支援請求響應和流式互動。 由於其廣泛的語言支援和簡單的面向使用者的設計,該協議越來越受歡迎,其中包括服務網格實現。


一個簡單的基於 gRPC 的應用程式


gRPC 透過 HTTP / 2 傳輸,無論是明文還是 TLS 加密。 gRPC 呼叫被實現為具有高效編碼主體的 HTTP POST 請求(協議緩衝區是標準編碼)。 gRPC 響應使用類似的編碼體,併在響應結束時使用 HTTP trailers 傳送狀態碼。


按照設計,gRPC 協議不能透過 HTTP 傳輸。 gRPC 協議規定使用 HTTP / 2,是為了利用 HTTP / 2 連線的復用和流式傳輸功能。


使用 NGINX 管理 gRPC 服務


公開簡單的 gRPC 服務


首先,我們在客戶端和伺服器應用程式之間插入 NGINX。 NGINX 為伺服器應用程式提供了一個穩定可靠的閘道器。


NGINX 代理 gRPC 流量


先透過 gRPC 更新部署 NGINX。 如果您想從原始碼構建 NGINX,記得包含 http_ssl 和 http_v2 模組:



NGINX 使用 HTTP 伺服器監聽 gRPC 流量,並使用 grpc_pass 指令代理流量。 為 NGINX 建立以下代理配置,在埠 80 上偵聽未加密的 gRPC 流量並將請求轉發到埠 50051 上的伺服器:



確保 grpc_pass 指令中的地址是正確的。 重新編譯客戶端以指向 NGINX 的 IP 地址並監聽埠。


當您執行修改後的客戶端時,您會看到與之前相同的響應,但事務將由 NGINX 終止並轉發。 您可以在您配置的訪問日誌中看到它們:



使用 TLS 加密釋出 gRPC 服務


Hello World 快速入門示例使用未加密的 HTTP / 2(明文)進行通訊。 這對測試和部署來說非常簡單,但它不提供生產部署所需的加密。 你可以使用 NGINX 來新增這個加密層。



NGINX SSL 終止 gRPC 流量


建立一個自簽名證書對並修改您的 NGINX 伺服器配置,如下所示:



修改 gRPC 客戶端以使用 TLS,連線到埠 1443,並禁用證書檢查 – 使用自簽名或不可信證書時必需這麼做。 例如,如果您使用 Go 示例,則需要:


  • 將 crypto / tls 和 google.golang.org/grpc/credentials 新增到您的匯入串列中

  • 將 grpc.Dial() 呼叫修改為以下內容:

這就是使用 NGINX 來確保 gRPC 流量所需要做的。 在生產部署中,您需要將自簽名證書替換為受信任的證書頒發機構(CA)頒發的證書。 客戶端將被配置為信任該 CA。


代理加密的 gRPC 服務


您可能還想要在內部加密 gRPC 流量。 您首先需要修改伺服器應用程式以偵聽 TLS 加密(grpcs)而不是未加密(grpc)連線:


在 NGINX 配置中,您需要更改用於將 gRPC 流量代理到上游伺服器的協議:


路由 gRPC 流量


如果您有多個 gRPC 服務,每個服務都由不同的伺服器應用程式實現,你可以做什麼? 如果您可以透過單個 TLS 加密的端點釋出所有這些服務,豈不是很棒?


NGINX 路由和 SSL 終止 gRPC 流量


使用 NGINX,您可以識別服務和方法,然後使用位置指令路由流量。 您可能已經推斷出每個 gRPC 請求的 URL 是從 proto 規範中的包,服務和方法名稱派生的。 考慮這個示例 SayHello RPC 方法:


呼叫 SayHello RPC 方法為 /helloworld.Greeter/SayHello 發出 POST 請求,如以下日誌條目所示:


192.168.20.1 – – [01/Mar/2018:13:35:02 +0000] “POST /helloworld.Greeter/SayHello HTTP/2.0” 200 18 “-” “grpc-go/1.11.0-dev”


使用 NGINX 路由流量非常簡單:


你可以自己嘗試一下。 我們擴充套件了示例 Hello World 包(在 helloworld.proto 中)以新增一個名為 Dispatcher 的新服務,然後建立了一個實現 Dispatcher 方法的新伺服器應用程式。 客戶端使用單個 HTTP / 2 連線為 Greeter 和 Dispatcher 服務發出 RPC 呼叫。 NGINX 將呼叫分開並路由到合適的 gRPC 伺服器。


請註意“catch‑all” / location 塊。 該塊處理與已知 gRPC 呼叫不匹配的請求。 您可以使用像這樣的位置塊從相同的 TLS 加密端點提供 Web 內容和其他非 gRPC 服務。


負載平衡 gRPC 呼叫


您現在如何擴充套件 gRPC 服務以增加容量並提供高可用性? NGINX 的上游團隊是這樣做的:


當然,如果您的上游正在偵聽 TLS,則可以使用 grpc_pass grpcs:// upstreams。


NGINX 可以採用一系列負載平衡演演算法來分配上游 gRPC 伺服器上的 gRPC 呼叫。 NGINX 的內建執行狀況檢查將檢測伺服器是否無法響應或產生錯誤,然後使伺服器停止運轉。 如果沒有伺服器可用,則 / error502grpc 位置將傳回符合 gRPC 的錯誤訊息。


以上是 gRPC 代理支援的最初版本。原文連結:


  • https://www.nginx.com/blog/nginx-1-13-10-grpc/


有任何問題歡迎留言探討,或透過以上連結進行反饋。


●編號463,輸入編號直達本文

●輸入m獲取到文章目錄

推薦↓↓↓

駭客技術與網路安全

更多推薦18個技術類公眾微信

涵蓋:程式人生、演演算法與資料結構、駭客技術與網路安全、大資料技術、前端開發、Java、Python、Web開發、安卓開發、iOS開發、C/C++、.NET、Linux、資料庫、運維等。

贊(0)

分享創造快樂