建立協助程式服務，代表取用者服務或應用程式傳送網路要求。 可以把大使服務想像成一個與客戶共置的流程外代理。
利用大使模式以語言無關的方式卸下常見的客戶端連接任務，如監控、日誌記錄、路由、安全管理（如傳輸層安全，TLS）及 韌性模式 。 透過使用大使模式，擴展舊有應用程式或其他難以修改的應用程式的網路能力。 專業團隊也可以使用 Ambassador 模式來實作這些功能。
內容和問題
具備韌性的雲端應用需要如 斷路、路由、計量與監控，以及網路相關的配置更新等功能。 如果開發團隊不維護程式碼或無法輕易修改，更新舊有應用程式或現有程式碼庫以加入這些功能可能會變得困難甚至不可能。
網路通話也可能需要大量的連線、認證與授權設定。 當多個應用程式在不同語言和框架間使用這些呼叫時，你必須為每個實例分別配置呼叫。 組織內的中央團隊可能需要管理網路與安全功能。 在龐大的程式碼庫中，團隊更新不熟悉的應用程式程式碼可能風險較高。
解決方案
將客戶端框架和函式庫放入外部進程，作為應用程式與外部服務之間的代理。 為了控制路由、韌性與安全功能，並避免主機相關的存取限制，請在與應用程式相同的主機環境中部署代理伺服器。 使用大使模式來標準化並擴充儀器配置。 代理伺服器可以在與應用程式相同的主機環境中監控效能指標，如延遲或資源使用。
你可以獨立管理這些分配給代理的功能，而非應用程式本身。 您可以更新和修改大使，而不干擾應用程式的舊版功能。 獨立且專業的團隊也能實作並維護已移交大使的安全性、網路或認證功能。
你可以將大使服務部署為 副車 ，以配合消費型應用程式或服務的生命週期。 或者，如果在同一主機上的多個獨立進程共用代理服務，你可以將其部署為守護進程或 Windows 服務。 如果消費服務是容器化的，請在同一主機上建立大使作為獨立容器，並設置適當的通訊連結。
問題和考慮
當您決定如何實作此模式時，請考慮下列幾點：
Proxy 會增加一些延遲額外負荷。 考慮應用程式直接呼叫的客戶端函式庫是否是更好的方法。
請考慮在 Proxy 中包含一般化功能的可能影響。 例如，大使可以處理重試，但除非所有操作都是冪元操作，否則這種做法可能不安全。
考慮一種機制，讓客戶端能將上下文傳遞給代理伺服器，再回傳給客戶端。 例如，包含 HTTP 標頭來選擇不重試或指定重試的最大次數。
考慮如何打包和部署代理伺服器。
請考慮針對所有用戶端使用單一共享實例，還是針對每個用戶端使用實例。
使用此模式的時機
當下列情況時，請使用此模式：
你必須為多種語言或框架建立一套通用的客戶端連接功能。
你必須將跨領域的客戶連線問題交給基礎架構開發者或其他更專業的團隊。
你必須支援舊有應用程式或難以修改的應用程式中的雲端或叢集連接需求。
你必須支援 API 閘道、服務網狀或標準進出口控制無法輕易處理的協定或連線模式。
在下列情況下，此模式可能不適用：
網路請求延遲至關重要。 代理伺服器帶來的開銷極低，而這種開銷可能會影響應用程式本身。
客戶端連接功能由單一語言實現。 在這種情況下，更好的選擇可能是用客戶端函式庫作為套件分發給開發團隊。
連接功能無法被泛化，這些功能需要與客戶端應用程式更深入的整合。
你的應用平台支援預先建置的解決方案，例如服務網狀網路，來處理互助 TLS（mTLS）、流量管理及政策功能。 使用這些解決方案，而不是建立客製化大使解決方案。
工作負載設計
評估如何在工作負載設計中使用大使模式，以達成 Azure Well-Architected Framework 支柱所涵蓋的目標與原則。 下表提供此模式如何支援每個要素目標的指引。
| 支柱 | 此模式如何支援支柱目標 |
|---|---|
| 可靠性 設計決策有助於使工作負載具有韌性，並確保在故障發生後能復原到正常運作的狀態。 | 此模式引入網路通訊中介點，因此你可以為網路通訊加入可靠性模式，如重試或緩衝。 - RE：07 自我保護 |
| 安全性 設計決策有助於確保 工作負載數據和系統的機密性、 完整性和 可用性 。 | 透過這種模式，你可以在網路通訊上實作安全措施，而客戶端無法直接處理。 - SE：06 網路控制 - SE：07 加密 |
如果此模式在一個支柱內部引入取捨，請將它們與其他支柱的目標進行考量。
範例
下圖顯示一個應用程式藉由 ambassador proxy 向遠端服務發出請求。 大使會提供路由、斷路器和記錄。 它呼叫遠端服務，然後將回應回傳給用戶端應用程式。
在容器化環境中，這個大使會作為側車容器運行，緊鄰應用程式容器。 在非容器化環境中，你會把它實作為本地程序或同一主機上的 Windows 服務。