建立個別的後端服務，以由特定前端應用程式或介面取用。 當您想要避免為多個介面自定義單一後端時，此模式很有用。 這個模式首先由山姆·紐曼描述。
內容和問題
應用程式一開始可能會以桌面 Web UI 為目標。 一般而言，後端服務會以平行方式開發，以提供該UI所需的功能。 隨著應用程式的使用者基底成長，開發的行動應用程式必須與相同的後端互動。 後端服務會變成一般用途的後端，同時滿足桌面和行動介面的需求。
但是，行動裝置的功能與桌面瀏覽器在螢幕大小、效能和顯示限制方面有很大的不同。 因此，行動應用程式後端的需求與桌面 Web UI 不同。
這些差異會導致後端的競爭需求。 後端需要一般且重大的變更，才能同時提供桌面Web UI和行動應用程式。 通常，個別的介面小組會在每個前端上運作，導致後端成為開發程式中的瓶頸。 衝突的更新需求，以及讓服務同時在前端運作的需求，可能會導致花費大量精力在單一可部署的資源上。
當開發活動著重於後端服務時，可能會建立個別小組來管理和維護後端。 最後，這會導致介面和後端開發小組之間中斷連線，讓後端小組負擔，以平衡不同UI小組的競爭需求。 當某個介面小組需要變更後端時，這些變更必須先與其他介面小組進行驗證，才能將其整合到後端。
解決方案
為每個使用者介面建立一個後端。 微調每個後端的行為和效能，以最符合前端環境的需求，而不必擔心影響其他前端體驗。
因為每個後端都專屬於一個介面，所以可以針對該介面進行優化。 因此，它比嘗試滿足所有介面需求的泛型後端要小、複雜且可能更快。 每個介面小組都有自主性來控制自己的後端，而且不依賴集中式後端開發小組。 這可讓介面小組在語言選擇、發行頻率、工作負載的優先順序，以及其後端的功能整合方面具有彈性。
如需詳細資訊，請參閱 模式：前端的後端。
問題和考慮
- 請考慮要部署多少個後端。
- 如果不同的介面（例如行動用戶端）會提出相同的要求，請考慮是否需要為每個介面實作後端，或單一後端是否足夠。
- 實作此模式時，跨服務的程式代碼重複極有可能。
- 以前端為主的後端服務應該只包含用戶端特定的邏輯和行為。 一般商業規則和其他全域功能應該在應用程式中的其他地方進行管理。
- 思考此模式如何反映在開發小組的責任中。
- 請考慮實作此模式所需的時間。 建置新後端的努力是否會產生技術債務，同時繼續支持現有的一般後端？
使用此模式的時機
當下列情況時，請使用此模式：
- 共用或一般用途的後端服務必須維持在開發額外負荷上。
- 您要針對特定用戶端介面的需求優化後端。
- 自定義是一般用途後端，以容納多個介面。
- 程序設計語言更適合特定使用者介面的後端，但不適用於所有使用者介面。
此模式可能不適合：
- 當介面對後端提出相同或類似的要求時。
- 當只有一個介面用來與後端互動時。
工作負載設計
架構設計人員應該評估前端的後端模式如何用於其工作負載的設計，以解決 Azure 架構良好架構支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 可靠性設計決策可協助工作負載復原到故障，並確保它會在發生失敗后復原到完全正常運作的狀態。 | 擁有專屬於特定前埠的個別服務包含故障，因此一個用戶端的可用性可能會影響另一個用戶端存取的可用性。 此外，當您以不同的方式處理各種用戶端時，您可以根據預期的用戶端存取模式來排定可靠性工作的優先順序。 - RE：02 重要流程 - RE：07 自我保護 |
| 安全性 設計決策有助於確保 工作負載數據和系統的機密性、 完整性和 可用性 。 | 由於此模式中引進的服務區隔，支援一個用戶端的服務層中的安全性和授權可以針對該用戶端所需的功能量身打造，而可能會減少 API 介面區，並在可能會公開不同功能的不同後端之間橫向移動。 - SE：04 分割 - SE：08 強化資源 |
| 效能效率 可透過調整、數據、程式代碼的優化，有效率地協助您的工作負載 符合需求 。 | 後端區隔可讓您以無法使用共用服務層的方式進行優化。 當您以不同的方式處理個別用戶端時，您可以針對特定客戶端的條件約束和功能優化效能。 - PE：02 容量規劃 - PE：09 重大流程 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。