將後端服務與前端實作分離，以針對不同的用戶端介面量身打造體驗。 當您想要避免自定義提供多個介面的後端時，此模式很有用。 此模式是以 模式為基礎：Sam Newman 所描述的前端後端。
內容和問題
請考慮一開始使用桌面 Web UI 和對應的後端服務所設計的應用程式。 隨著商務需求隨著時間變更，已新增行動介面。 這兩個介面都會與相同的後端服務互動，但行動裝置的功能與桌面瀏覽器在螢幕大小、效能和顯示限制方面有很大的不同。
後端服務通常會面臨來自不同前端的競爭需求，導致開發程式中經常發生變更和潛在瓶頸。 衝突的更新和維護相容性的需求會導致單一可部署資源的過度工作。
讓個別小組管理後端服務，可以在前端和後端小組之間建立中斷聯機，導致延遲取得共識和平衡需求。 例如，在整合之前，必須先與其他前端小組驗證一個前端小組要求的變更。
解決方法
引進僅處理介面特定需求的新層。 這個層稱為後端 for-frontend （BFF） 服務，位於前端用戶端與後端服務之間。 如果應用程式支援多個介面，請為每個介面建立 BFF 服務。 例如，如果您有 Web 介面和行動應用程式，您可以為每個服務建立個別的 BFF 服務。
此模式會針對特定介面量身打造客戶端體驗，而不會影響其他介面。 它也會微調效能，以最符合前端環境的需求。 由於每個 BFF 服務較小且較不複雜，因此應用程式可能會有某種程度的優化優點。
前端小組擁有自己的 BFF 服務自主權，可在不依賴集中式後端開發小組的情況下，彈性地選擇語言、發行頻率、工作負載優先順序和功能整合。
雖然許多 BF 依賴 REST API，但 GraphQL 實作正成為替代專案，因此不需要 BFF 層，因為查詢機制不需要個別的端點。
如需詳細資訊，請參閱 模式：前端的後端。
問題和考慮
評估最適合的服務數目，因為這會產生相關聯的成本。 維護和部署更多服務表示增加作業額外負荷。 每個個別服務都有自己的生命週期、部署和維護需求，以及安全性需求。
新增服務時，請檢閱服務等級目標（SLO）。 延遲增加可能會因為用戶端未直接連絡您的服務，而新的服務引進額外的網路躍點。
當不同的介面提出相同的要求時，請評估要求是否可以合併成單一 BFF 服務。 在多個介面之間共用單一 BFF 服務可能會導致每個用戶端的不同需求，這會使 BFF 服務的成長和支援複雜化。
程式代碼重複是此模式的可能結果。 評估程式代碼重複與每個用戶端更量身打造的體驗之間的取捨。
BFF 服務應該只處理與特定用戶體驗相關的用戶端特定邏輯。 應抽象化跨領域功能，例如監視和授權，以保持 BFF 服務輕視。 BFF 服務中可能浮出水面的一般功能，會分別使用 Gatekeeping、速率限制、路由和其他功能來處理。
在學習和實作此模式時，請考慮對開發小組的影響。 建置新的後端需要時間和精力，在維護現有的後端服務的同時，可能會產生技術債務。
評估您是否完全需要此模式。 例如，如果您的組織使用 GraphQL 搭配前端特定解析程式，BFF 可能不會將值新增至您的應用程式。
另一個範例是結合 API 閘道 與微服務的應用程式。 在先前建議使用 BFF 的一些案例中，此方法可能就已足夠。
使用此模式的時機
當下列情況時，請使用此模式：
共用或一般用途的後端服務必須維持在開發額外負荷上。
您要針對特定用戶端介面的需求優化後端。
自定義是一般用途後端，以容納多個介面。
程序設計語言更適合特定使用者介面的後端，但不適用於所有使用者介面。
此模式可能不適合：
當介面對後端提出相同或類似的要求時。
當只有一個介面用來與後端互動時。
工作負載設計
架構設計人員應該評估前端的後端模式如何用於其工作負載的設計，以解決 azure Well-Architected Framework 支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 可靠性設計決策可協助工作負載復原到故障，並確保它會在發生失敗后復原到完全正常運作的狀態。 | 擁有專屬於特定前埠的個別服務包含故障，因此一個用戶端的可用性可能會影響另一個用戶端存取的可用性。 此外，當您以不同的方式處理各種用戶端時，您可以根據預期的用戶端存取模式來排定可靠性工作的優先順序。 - RE：02 重要流程 - RE：07 自我保護 |
| 安全性 設計決策有助於確保 工作負載數據和系統的機密性、 完整性和 可用性 。 | 由於此模式中引進的服務區隔，支援一個用戶端的服務層中的安全性和授權可以針對該用戶端所需的功能量身打造，而可能會減少 API 介面區，並在可能會公開不同功能的不同後端之間橫向移動。 - SE：04 分割 - SE：08 強化資源 |
| 效能效率可透過調整規模、資料、程式碼達到最佳化，有效率地協助您的工作負載符合需求。 | 後端區隔可讓您以無法使用共用服務層的方式進行優化。 當您以不同的方式處理個別用戶端時，您可以針對特定客戶端的條件約束和功能優化效能。 - PE：02 容量規劃 - PE：09 重大流程 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。
範例
此範例示範您有兩個不同用戶端應用程式的模式使用案例：行動應用程式和傳統型應用程式。 這兩個用戶端都會與 Azure API 管理 （資料平面閘道） 互動，其可作為抽象層，處理常見的跨領域考慮，例如：
授權 – 確保只有具有適當存取令牌的已驗證身分識別，才能使用具有 Microsoft Entra ID 的 Azure API 管理 （APIM） 呼叫受保護的資源。
監視 – 擷取和傳送要求和回應詳細數據，以用於 Azure 監視器的可觀察性用途。
要求快取 – 使用 APIM 內建功能提供來自快取的回應來優化重複的要求。
路由 & 匯總 – 將連入要求導向至前端 （BFF） 服務的適當後端。
每個用戶端都有一個專用的 BFF 服務，以 Azure 函式的形式執行，做為閘道與基礎微服務之間的媒介。 這些用戶端特定的 BFF 可確保為分頁提供量身打造的體驗，以及其他功能。 雖然行動裝置更具頻寬意識的應用程式和快取可改善效能，但桌面會在單一要求中匯總多個頁面，以優化更豐富的用戶體驗。
此圖表結構化為四個不同的區段，說明要求、驗證、監視和用戶端特定處理流程。 在最左邊，兩個用戶端裝置會起始要求：針對有頻寬效率的用戶體驗優化行動應用程式，以及提供完整功能介面的網頁瀏覽器。 箭頭會從這兩個裝置延伸至中央進入點，也就是 Azure API 管理閘道，表示所有要求都必須通過這一層。 在第二個區段中，以虛線矩形括住，架構會分成兩個水準群組。 左群組代表 Azure API 管理，負責處理連入要求，並判斷應如何處理這些要求。 兩個箭頭會從此數據平面網關向外延伸：一個指向上至Microsoft管理授權的 Entra ID，另一個指向負責記錄和可觀察性的 Azure 監視器。 此外，箭頭會從網關迴圈回到行動用戶端，代表重複相同要求時快取的回應，減少不必要的處理。 虛線矩形內的右群組著重於根據發出要求的客戶端類型來量身打造後端回應。 它提供兩個不同的前端後端用戶端，兩個用戶端都是使用 Azure Functions 進行無伺服器運算裝載的，一個專用於行動用戶端，另一個是桌面用戶端。 兩個箭頭會從閘道延伸至這些後端前端客戶端，說明每個傳入要求都會根據客戶端類型轉送至適當的服務。 在此層之外，虛線箭號會向右延伸，將後端前端用戶端連線到各種微服務，以處理實際的商業規則。 若要將此圖表可視化，想像一下用戶端要求從行動和 Web 用戶端移至閘道的由左至右流程。 此閘道會處理每個要求，同時將驗證委派給識別提供者，然後向下記錄至監視服務。 從該處，它會根據要求是否來自行動或桌面用戶端，將要求路由傳送至適當的前端用戶端。 最後，每個前端後端用戶端會將要求轉送至特製化微服務，這些微服務會執行必要的商業規則，並傳回必要的回應。 如果快取的回應可用，網關會攔截要求，並將預存的回應直接傳送至行動用戶端，以防止備援處理。
流程 A：行動用戶端 – 第一頁要求
- 行動用戶端會傳送頁面
GET要求，1在授權標頭中包含OAuth 2.0 令牌。 - 要求會到達 Azure APIM 閘道，以攔截它並：
- 檢查授權狀態 – APIM 會深入實作防禦，因此它會檢查存取令牌的有效性。
- 將要求活動串流為記錄至 Azure 監視器 – 系統會記錄要求的詳細資料以進行稽核和監視。
- 系統會強制執行原則，然後 Azure APIM 會將要求路由傳送至 Azure Function Mobile BFF。
- Azure Function Mobile BFF 接著會與必要的微服務互動，以擷取單一頁面並處理要求的數據，以提供輕量型體驗。
- 回應會傳回給用戶端。
流程 B：行動用戶端 - 第一頁快取要求
- 行動用戶端會再次傳送頁面
1相同的GET要求，包括授權標頭中的 OAuth 2.0 令牌。 - Azure APIM 閘道可辨識此要求之前和：
- 會強制執行原則，並在之後識別符合要求參數的快取回應。
- 立即傳回快取的回應，而不需要將要求轉送至 Azure Function Mobile BFF。
流程 C：桌面用戶端 – 第一個要求
- 桌面用戶端會第一次傳送
GET要求，包括授權標頭中的 OAuth 2.0 令牌。 - 要求會到達 Azure APIM 閘道，其中會處理類似的跨領域考慮：
- 授權 – 一律需要令牌驗證。
- 串流要求活動 – 系統會記錄要求詳細數據以取得可觀察性。
- 強制執行所有原則后，Azure APIM 會將要求路由傳送至 Azure 函式桌面 BFF，負責處理大量數據的應用程式處理。 桌面 BFF 會先使用基礎微服務呼叫來匯總多個要求，然後再以多個頁面回應回應來回應用戶端。
設計
Microsoft Entra ID 做為雲端式識別提供者，針對行動和桌面用戶端發出量身訂做的物件宣告，這些宣告隨後會用於授權。
Azure API 管理 做為用戶端與其 BBF 之間新增周邊的 Proxy。 其已設定原則來 驗證 JSON Web 令牌 （JWT），拒絕沒有令牌或宣告抵達的要求對目標 BFF 無效。 此外，它會將所有活動記錄串流至 Azure 監視器。
Azure 監視器 作為集中式監視解決方案，匯總所有活動記錄，以確保完整的端對端可檢視性。
Azure Functions 是無伺服器解決方案，可順暢地跨多個端點公開 BFF 邏輯、啟用簡化的開發、降低基礎結構額外負荷，以及降低營運成本。