將共用或特定服務功能轉移至閘道代理。 此方法簡化應用程式開發，將跨領域關注事項集中於閘道器，例如面向客戶端的 TLS 憑證終止，而非在各服務間重複處理。
當多個服務共同負責認證、監控或協定轉譯等任務時，將這些問題整合到單一閘道器中，可以降低每項服務的設定負擔與部署風險。
內容和問題
某些功能通常用於多個服務，這些功能需要設定、管理和維護。 每次應用程式部署時分發的共享或專用服務會增加管理負擔，並增加部署錯誤的可能性。 你必須在所有共享該功能的服務中部署任何共享功能的更新。
安全議題如令牌驗證、加密及TLS憑證管理，可能需要團隊成員具備高度專業技能。 例如，若沒有閘道器，你可能需要在每個應用程式實例上設定並部署面向用戶端的憑證。 你必須追蹤它的有效期限，並在這些情況下更新、測試並驗證。
其他常見的服務，例如驗證、授權、記錄、監視或 節流 ，可能難以在大量部署中實作和管理。 整合這類功能可降低開銷與錯誤機率。
解決方案
將部分功能卸載到閘道器。 閘道接著處理跨領域的問題，如面向用戶端的憑證管理、認證、TLS 終止、監控、協定轉譯，以及代表後端服務的限速。
下圖展示了一個閘道器，該閘道終止入站的 TLS 連線並套用共享能力。 閘道器會驗證後端憑證，並透過獨立的 TLS 連線重新加密流量至後端服務。
此模式的優點包括：
透過集中共享配置（如認證、限速和請求記錄）來簡化服務開發，而非在每個後端服務中實作。 集中化提升一致性，使服務升級更為簡單。
允許專用小組實作需要特殊專業知識的功能，例如安全性。 你的核心團隊可以專注於應用程式功能，將這些專門但跨領域的問題交由相關專家處理。
為請求和回應的記錄與監控提供一致性。 即使服務未正確安裝，閘道器仍能提供基線的監控與記錄。
集中化碳排放感知交通管理。 閘道器可根據即時碳強度訊號調整快取、速率限制及日誌行為。 Azure API 管理 提供這些功能，提供有限預覽版、特定區域及經典層級（開發者、基礎、標準與高級）。 關於可用性與設定細節，請參閱 Azure API 管理 中的環境永續 API。
問題和考慮
當您決定如何實作此模式時，請考慮下列幾點：
高可用性與韌性。 確保閘道具備高可用性並能抵禦故障。 執行閘道的多個實例，以避免單一失敗點。 由於閘道器會終止用戶端連線並可緩衝請求實體，請考慮在實例失敗時如何處理正在進行的請求。 使用連線清空或正常關機機制，避免在移除或重新啟動閘道實例時中斷使用中的工作階段。
容量與規模。 請確定閘道是針對應用程式和端點的容量和調整需求所設計。 請確定閘道不會成為應用程式的瓶頸，且具有足夠的可擴展性。 閘道器必須配置以處理尖峰流量突發，而非僅僅是平均負載。 為了降低成本而對閘道器配置不足，會直接降低背後所有服務的效能。
卸載瞄準鏡。 將多個服務或路由共用的功能卸載，當集中管理時，可以減少重複的實作與管理。
商業邏輯分離。 絕對不要把商業邏輯卸給閘道器。
交易追蹤。 如果您需要追蹤交易，請考慮針對記錄目的產生相互關聯標識符。
額外延遲。 閘道器會在每個請求中加入一個網路跳點。 閘道執行的每個卸載功能，如 TLS 終止、認證或請求檢查，都會為請求路徑增加處理時間。 閘道的連線集區與對後端服務的持續連線，可透過重複使用既有連線，而非為每個請求建立新連線，來部分抵消延遲成本。 評估閘道跳與卸載功能的綜合延遲是否符合工作負載的效能目標。
操作複雜度。 集中式閘道不僅整合管理，也集中營運責任。 你必須將閘道設定、憑證生命週期、政策更新及版本升級視為共同關注事項來管理。 確保負責閘道器的團隊具備能力與工具，能在所有依賴該閘道服務的規模上管理閘道。
安全問題。 閘道是一個高價值的目標，因為它集中管理跨領域的安全功能，如認證、TLS 終止及請求檢查。 閘道器一旦被入侵，可能會暴露所有下游服務。 強化閘道器的安全性，限制其管理介面，並在其所保護的後端服務之外獨立監控閘道器的異常行為。
防止閘道繞過 設定後端服務只接受透過預定閘道路徑的請求。 否則，用戶端可直接連線至後端，繞過在閘道進行的認證、流量限制、請求檢查及記錄。
身份傳播。 定義每個後端是否授權原始呼叫者、閘道器的工作負載身份，或兩者皆有授權。 只有當後端需要委派使用者上下文時，才保留呼叫者權杖或受信任的聲明。 務必將閘道與後端分別進行驗證。 不要將未經驗證的轉寄標頭視為身分識別依據。
TLS 維護。 如果閘道終止 TLS，請重新建立 TLS 到後端。 不要透過未加密的 HTTP 轉發流量。 把所有網路都當作不可信。 此拓撲仍需執行後端憑證的發行、輪替及撤銷程序。
轉送標頭與用戶端上下文。 當閘道器終止用戶端連線並建立與後端服務的新連線時，除非閘道器明確轉發，否則用戶端 IP 位址、原始協定及主機名稱等資訊會遺失。 關於緩解策略，請參見「 在反向代理與其後端網頁應用程式之間保留原始 HTTP 主機名稱」。
使用此模式的時機
當下列情況時，請使用此模式：
- 應用程式部署有共同的關注點，例如TLS憑證或加密。
- 一個在應用程式部署中常見的功能，可能有不同的資源需求，例如記憶體資源、儲存容量或網路連線。
- 你應該把像網路安全、限速或其他網路邊界問題的責任，交給更專業的團隊處理。
在下列情況下，此模式可能不適用：
- 閘道必須包含服務專屬邏輯或路由規則，將後端服務變更與閘道設定變更緊密結合。 將閘道層與內部服務結合，意味著後端更新可能迫使閘道重新部署，降低部署獨立性。
- 卸載的處理項目較為輕量，且該工作負載對延遲敏感。 當額外負擔超過集中化帶來的好處時，經由閘道所增加的額外一跳可能並不合理。
- 將關切集中於共享閘道會造成變更管理瓶頸。 若閘道團隊的發布週期比服務團隊慢，卸載可能會延遲憑證、認證政策或網路規則的更新。
工作負載設計
架構設計人員應該評估閘道卸除模式如何用於其工作負載的設計，以解決 Azure 良好架構架構支柱中涵蓋的目標和原則。 例如：
| 支柱 | 此模式如何支援支柱目標 |
|---|---|
| 可靠性 設計決策有助於使工作負載具有韌性，並確保在故障發生後能復原到正常運作的狀態。 | 將此責任卸載至閘道可降低後端節點上應用程式程式碼的複雜性。 在某些情況下，卸載會將功能完全轉移為由平臺提供的可靠功能。 - RE：01 簡單性和效率 |
| 安全性 設計決策有助於確保 工作負載數據和系統的機密性、 完整性和 可用性 。 | 在請求流程中加入閘道器，可以集中管理像是網頁應用程式防火牆和用戶端 TLS 政策等控制。 由平台提供的任何卸載功能都已具備增強的安全性。 - SE：06 網路控制 - SE：08 強化資源 |
| 成本優化 專注於 維持並提升 您的工作負載的 投資報酬率。 | 此模式可讓您將成本從每個節點花費的資源重新導向至閘道實作。 集中式處理模型中的成本經常低於分散式模型的成本。 - CO：14 合併 |
| 卓越營運有助於透過標準化流程和團隊凝聚力來提供工作負載品質。 | 在此模式中，卸載功能的配置與維護皆由單一節點負責，而非多個節點管理。 這種集中化標準化了跨領域議題的應用方式，使日常及臨時的營運變更保持一致且可預測。 - OE：02 標準化作業 |
| 效能效率 可透過調整、數據和程式碼的優化， 有效率地協助您的工作負載符合需求 。 | 在請求流程中加入卸載閘道，可以減少每個節點的資源使用，因為功能集中在閘道器。 您可以優化與應用程式程式代碼無關之卸除功能的實作。 已經轉移的平臺提供功能可能已具高度效能。 - PE：03 選擇服務 |
如果此模式在一個支柱內部引入取捨，請將它們與其他支柱的目標進行考量。
Example
Azure 應用程式閘道 WAF_v2可以實作此模式用於區域網路應用程式。 閘道器終止用戶端 TLS 連線，套用 WAF 與路由政策，並建立新的 TLS 連線至後端服務。 此設計避免了共享的請求處理問題進入後端應用程式碼。
具備 TLS 卸載的應用閘道
下圖顯示應用閘道如何終止入站的 TLS 連線，檢查並過濾流量，並在透過 TLS 轉發至後端池前重新加密。
此架構使用以下應用閘道元件來卸載共享能力並重新加密後端流量：
- HTTPS 監聽器。 位於 443 埠的 HTTPS 監聽器接受用戶端的 TLS 入站連線。
- TLS 證書。 一個來自 Azure Key Vault 的 PFX 憑證會附加在 HTTPS 監聽器上。 應用閘道會解密入站流量以檢查並路由，然後再重新加密到後端池。 後端伺服器仍需憑證來執行重新加密的連線，但在許多情況下可以使用平台管理憑證。
- 後端池。 後端池定義接收重新加密流量的 HTTPS 伺服器集合。 後端目標可以是虛擬機、Azure 虛擬機器擴展集、IP 位址或 Azure App 服務 實例。 限制後端存取，讓用戶端無法直接連線繞過 Application Gateway 及其 WAF 政策。
- 後端 HTTP 設定。 將後端協定設為 HTTPS，埠口設為後端的 TLS 埠，例如 443。 設定憑證信任與與後端憑證相符的主機名稱。 若為私有憑證授權單位，請設定受信任根憑證。 如需詳細資訊，請參閱 v2 SKU 的端對端 TLS。
- 路由規則。 請求路由規則將監聽者與後端池及後端 HTTP 設定關聯起來。 基於路徑的規則可以將不同的 URL 路徑路由到不同的後端池。
- WAF 政策。 該政策定義了用於檢查請求的管理與自訂規則，包括任何地理匹配規則。
由於應用閘道會解密流量，因此它可以檢查請求內容以進行智慧路由、重寫 HTTP 標頭與網址，並套用 WAF 規則。 接著它會重新加密流量，然後將請求轉發到後端。
關於設定指引，請參閱 《端對端 TLS 加密與應用閘道器》。
支援技術
以下 Azure 服務能協助你實作此模式：
針對區域性 Web 流量，請使用 Application Gateway。
針對 AKS 工作負載，使用 Azure 應用程式閘道 for Containers 作為 Kubernetes 原生輸入。
使用 Azure Front Door 來處理全球或多區域的網頁流量。
使用 Azure API 管理 來處理 API 專屬的問題，例如認證、限速、轉換和監控。