適用於： ✔️ Front Door 標準 ✔️ Front Door 進階
在本文中，您將學習如何透過 Azure Front Door Standard 與 Premium 配置並測試原生 gRPC 服務。 你可以依服務和方法路由呼叫，將流量分散到健康的來源伺服器，並套用支援的請求中繼資料控制。
Important
Azure Front Door 的 gRPC 支援目前處於公開預覽階段。 請參閱Microsoft Azure 預覽的補充使用條款，以了解適用於 Azure 測試版、預覽版或其他尚未正式發布的功能的法律條款。
公開預覽版對所有 Azure Front Door Standard 及 Premium 用戶開放。 你不需要註冊預覽版，也不需要符合額外的預覽存取權要求。
什麼是 gRPC？
gRPC 是一個開源的遠端程序呼叫框架。 用戶端透過定義的服務合約呼叫遠端服務的方法。 原生 gRPC 使用 HTTP/2，並常用 Protocol Buffers 來序列化訊息。
gRPC 提供以下好處：
- 透過 HTTP/2 二進位分幀、標頭壓縮及連線多工的高效傳輸。
- 強型別的服務合約，並能針對所有支援的語言產生客戶端與伺服器程式碼。
- 支援一元呼叫、用戶端串流、伺服器串流及雙向串流，並支援截止期限、取消、元資料及狀態碼。
欲了解更多資訊，請參閱 gRPC 核心概念、架構與生命週期。
Protocol Buffers 與方法路徑
Protocol Buffers 提供語言中立、平台中立的結構化資料序列化。
.proto 檔案會定義訊息、服務和 RPC 方法。 Protocol Buffers 編譯器 protoc 會產生對應的程式碼。
以下 greet.proto 範例定義了 SayHello 一元方法：
syntax = "proto3";
package greet;
service Greeter {
rpc SayHello (HelloRequest) returns (HelloReply);
}
message HelloRequest {
string name = 1;
}
message HelloReply {
string message = 1;
}
完整限定請求路徑為 /greet.Greeter/SayHello。 使用此路徑來比對 Azure Front Door 路由中的方法。
gRPC 如何與 Azure Front Door 合作
客戶端的 TLS 連線終止於 Azure Front Door 邊緣。 Front Door 會比對 gRPC 路由，根據 HTTP/2 要求中繼資料評估支援的原則，選取狀態良好的來源，並透過獨立的 HTTPS 和 HTTP/2 連線轉送呼叫。 回應訊息與 gRPC 尾端標頭會返回用戶端。
預覽期間啟用 gRPC 路由的行為如下：
| Area | 行為或限制 |
|---|---|
| 級別 | 僅限標準版和高級版。 |
| Transport | HTTPS 和 HTTP/2 是從用戶端到 Front Door，以及從 Front Door 到來源伺服器都必須使用的。 |
| RPC 模式 | 支援一元、用戶端串流、伺服器串流及雙向串流呼叫。 |
| 路由比對 | 使用完整 /package.Service/Method 路徑，或有意使用廣泛的模式，如 /*。 |
| Caching | 不支援快取，並且在啟用 gRPC 的路由上會停用快取。 |
| 重定向與轉發 | 重定向對 gRPC 流量無效。 保持路由和規則集轉送設定為 HTTPS。 |
| 規則集和邊緣動作 | 支援，但須遵守本表中的 HTTPS 轉發要求及預覽限制。 |
| Private Link | 在預覽期間，gRPC 啟用的 Origin 不支援 Private Link。 |
| 路由配置覆寫 | 啟用 gRPC 的原始群組在預覽期間不能成為路由設定覆寫規則的目標。 |
| Web 應用程式防火牆 （WAF） | 支援的請求中繼資料檢查適用。 Protobuf 訊息不會解碼以進行要求本文檢查。 |
Prerequisites
- Azure Front Door 標準或進階設定檔。 要建立一個，請參見建立 Azure Front Door 設定檔。
- 一個 gRPC 來源，能在其設定的 HTTPS 來源埠上接受 TLS 和 HTTP/2。 路由起源群組中的每個起點都必須啟用 gRPC。
設定來源與健康探查器
在將來源群組附加至 gRPC 路由前，請先進行設定：
- 在 Azure 入口網站中，開啟您的 Front Door 設定檔。
- 在 設定中，選擇 Origin 群組，然後新增或編輯你 gRPC 服務的 Origin 群組。
- 新增或編輯每個來源。 為每個來源啟用 gRPC，並設定其 HTTPS 埠與 gRPC 服務相符。 預覽期間不要啟用這些來源的 Private Link。
- 請使用以下表格設定健康探針。
- 儲存來源群組。
| Setting | Configuration |
|---|---|
| 健康探針 | 啟用探測器以檢查源站健康狀態。 |
| Protocol | 選擇 gRPC 作為原生 gRPC 探針。 每個來源都必須實作標準 grpc.health.v1.Health/Check RPC。 |
| HTTP 或 HTTPS 探測 | 做為原生 gRPC 探查的替代方案，請選取 [HTTP] 或 [HTTPS]，並在來源設定 HTTP 健康情況端點。 |
| 探針間隔與負載平衡 | 選擇符合您應用健康檢測與來源負載需求的數值。 |
原生 gRPC 探針需要 標準的 gRPC 健康服務，而非僅是應用程式 RPC（如 SayHello）。 欲了解更多資訊，請參閱 gRPC健康檢查。 關於 HTTP 和 HTTPS 探測器，請參見 Azure Front Door 健康探測器。
螢幕擷取畫面顯示了探查和負載平衡的範例設定。 選擇符合您應用程式需求的數值。
設定 gRPC 路由
建立或更新路由，將 gRPC 呼叫傳送至來源群組：
- 在您的 Front Door 設定檔中，於 Settings 下，選取 Front Door manager。
- 選擇端點，然後新增或編輯路由。
- 選擇網域，以及包含你已啟用 gRPC 來源的來源群組。
- 開啟 啟用 gRPC。
- 請使用以下表格配置路由。
- 保存路線。
| Setting | Configuration |
|---|---|
| 要比對的模式 | 對於一個 RPC，輸入完整 /package.Service/Method 路徑，例如 /greet.Greeter/SayHello。 只有在您打算公開多個方法或伺服器反射時，才使用廣泛 /* 路由。 |
| 接受的通訊協定 | 啟用 gRPC 會自動將此值設為 僅限 HTTPS。 |
| 轉送通訊協定 | 啟用 gRPC 會自動將此值設為 僅限 HTTPS。 |
| Caching | 已針對啟用 gRPC 的路由停用。 |
截圖展示了一條範例路線。 使用你自己的網域、來源群組和 RPC 方法路徑。
在支援 gRPC 的路由中，支援規則集與邊緣動作。 如果規則集將轉發協定設定為 HTTP，Azure Front Door 會回傳 HTTP 301 回應給 gRPC 用戶端。 此回應未針對 gRPC 流量啟用重新導向支援。 保持路由和規則集轉發設定為 HTTPS。
如果你透過基礎架構即程式碼（IaC）設定路由，請明確使用相容的 HTTPS 和 gRPC 設定。 不相容的 HTTP 協定組合會被拒絕。
用 grpcurl 測試
要執行以下測試範例，請安裝 grpcurl。 你不需要這個工具來設定 Azure Front Door 的 gRPC 支援。
使用你已部署服務的 .proto 檔案或編譯描述符來測試方法專屬的路由，而不必依賴伺服器反射。 伺服器反射是一種可選的替代方式。 以下範例使用先前所示的 greet.Greeter 合約。
用你的 Front Door 端點或自訂網域取代 contoso.azurefd.net 。 使用與端點的 TLS 憑證相符的網域。 所有範例都透過 TLS 連線，使用連接埠 443；不要加上 -plaintext。
用本地的 proto 檔案測試特定方法的路由
請將服務定義儲存為 greet.proto，並儲存到您目前的目錄中。 若路線符合 /greet.Greeter/SayHello，請執行：
grpcurl -import-path "." -proto "greet.proto" -d "{}" contoso.azurefd.net:443 greet.Greeter/SayHello
| Argument | Purpose |
|---|---|
-import-path "." |
包含你的 proto 檔案的目錄。 如果檔案位於其他目錄，請取代 .。 |
-proto "greet.proto" |
服務定義與部署來源相符。 |
-d "{}" |
JSON 要求本文。 用服務所需的訊息來取代它。 |
contoso.azurefd.net:443 |
Front Door 端點或自訂網域，以及 HTTPS 埠。 |
greet.Greeter/SayHello |
完整限定的 RPC 名稱，不包含路由模式中使用的前導 /。 |
提供本機 proto 可讓 grpcurl 無需預備反射呼叫即可叫用應用程式方法。 您也可以使用 grpcurl 提供已編譯的描述項，而不是 proto 檔案。
測試具備伺服器反射功能的刻意設計的廣泛路由
伺服器反射是可選的。 當您沒有提供本機 proto 或描述項時，grpcurl 會使用伺服器反射來探索服務合約。 來源必須實作反射，且 Front Door 路由必須與其 RPC 路徑相符。
例如，反射 RPC grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo 使用請求路徑 /grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo。 限制為 /greet.Greeter/SayHello 的路由與該路徑不相符。 即使應用程式路徑正確，測試也可能在應用程式 RPC 被呼叫前失敗。
如果您刻意設定了廣泛 /* 路由並在來源上啟用了反射，則列出服務：
grpcurl contoso.azurefd.net:443 list
然後利用使用反射取得的合約呼叫該方法：
grpcurl -d "{}" contoso.azurefd.net:443 greet.Greeter/SayHello
Important
僅在刻意時才公開反射。 測試方法專屬路由時，建議使用本地的 proto 或描述符檔案，而不是只為了讓探索正常運作而擴大路由。
疑難排解 grpcurl 測試
| 徵兆 | 檢查或動作 |
|---|---|
grpcurl list 失敗了，但呼叫 -proto 成功。 |
檢查路由是否與應用程式的 RPC 相符，但與反射 RPC 不符。 繼續使用本機 proto 或描述項，以用於特定方法的路由。 |
| 反射探索失敗。 | 檢查來源是否實作了反射，且路由是否與其 RPC 路徑相符。 否則，請提供本機 proto 或描述項。 |
| 請求的方法與路由不符。 | 將已部署的 proto 中的套件、服務與方法與完整路由路徑進行比較。 在路由模式中包含前導 /，但不包含在傳遞給 grpcurl 的 RPC 引數中。 |
| 發生 TLS 主機名稱或憑證錯誤。 | 檢查提供給 grpcurl 的主機名稱是否與 Front Door 網域及憑證相符。 使用 TLS，不要使用 -plaintext。 |
Web 應用程式防火牆考量事項
Azure Front Door WAF 可以評估支援的 HTTP/2 請求元資料，例如 URI、標頭、用戶端 IP 位址和地理位置。 支援的基於元資料的速率限制情境也可適用。
Front Door 不會解碼 protobuf 訊息。 依賴檢查 gRPC 訊息體的 WAF 規則不提供 protobuf 有效載荷檢查。 在 gRPC 應用程式或其他理解 protobuf 架構的元件中驗證訊息。 不要把元資料檢查當作訊息層級的保護。
更多資訊請參見 Azure Front Door 的 Web 應用程式防火牆。
監控 gRPC 流量
設定診斷日誌，並將 Front Door 存取日誌與來源端的 gRPC 應用日誌相互關聯。 檢查尾端標頭中傳回的 HTTP 狀態和 gRPC 狀態。 HTTP 200 回應仍可攜帶非 OK gRPC 應用程式狀態。
如果你將存取日誌傳送到 Log Analytics 工作區中的 AzureDiagnostics 資料表，請使用以下查詢來檢查範例服務的 HTTP 中繼資料：
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.CDN"
and Category == "FrontDoorAccessLog"
| where TimeGenerated > ago(1d)
| where requestUri_s contains "/greet.Greeter/"
| project TimeGenerated, ResourceId, requestUri_s,
httpVersion_s, httpStatusCode_s
用您的服務路徑取代 /greet.Greeter/。 查詢顯示的是請求的 URI、HTTP 版本和 HTTP 狀態碼，而非回應尾部中的 gRPC 狀態。 使用來源端的 gRPC 日誌來調查應用程式狀態，並將失敗與 Front Door 存取日誌關聯起來。