知識星球來自：開源中國
連結：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、資料庫、運維等。
