Azure App 服務是功能強大的 Web 應用程式裝載平臺。 Azure Functions 建置在 App Service 基礎結構之上，可讓您輕鬆地建置無伺服器和事件驅動的計算工作負載。 這兩個服務經常用於多租使用者解決方案。
支援多租使用者Azure App 服務和 Azure Functions 的功能
Azure App 服務和 Azure Functions 包含許多支援多租使用者的功能。
自訂網域名稱
Azure App 服務可讓您使用 萬用字元 DNS ，並新增您自己的 萬用字元 TLS 憑證 。 當您使用 租使用者特定的子域 時，萬用字元 DNS 和 TLS 憑證可讓您輕鬆地將解決方案調整為大量租使用者，而不需要為每個新租使用者手動重新設定。
當您使用 租使用者特定的自訂功能變數名稱 時，可能會有大量需要新增至應用程式的自訂功能變數名稱。 管理許多自訂功能變數名稱可能會變得麻煩，尤其是在需要個別 TLS 憑證時。 App Service 提供 受控 TLS 憑證 ，可減少使用自訂網域時所需的工作。 不過，有一些 可考慮 的限制，例如可以套用至單一應用程式的自訂網域數目。
與 Azure Front Door 整合
App Service 和 Azure Functions 與 Azure Front Door 整合，以作為解決方案的網際網路對應元件。 Azure Front Door 可讓您新增 Web 應用程式防火牆 （WAF） 和邊緣快取，並提供其他效能優化。 您可以根據變更的商務或技術需求，輕鬆地重新設定流量，將流量導向不同的後端。
當您搭配多租使用者應用程式使用 Azure Front Door 時，您可以使用它來管理自訂功能變數名稱，以及終止 TLS 連線。 接著，您的 App Service 應用程式會設定為單一主機名稱，而且所有流量都會流向該應用程式，這可協助您避免在多個位置管理自訂功能變數名稱。
如上述範例所示， Azure Front Door 可以設定為修改要求的 Host 標頭 。 用戶端傳送的原始 Host 標頭會透過 X-Forwarded-Host 標頭傳播，而您的應用程式程式碼可以使用此標頭將 要求對應至正確的租使用者 。
警告
如果您的應用程式傳送 Cookie 或重新導向回應，您必須特別小心。 要求 Host 標頭中的變更可能會使這些回應失效。 如需詳細資訊，請參閱 主機名稱保留最佳做法 。
您可以使用 私人端點 或 App Service 存取限制 ，以確保流量已流經 Front Door，再連線到您的應用程式。
如需在多租使用者方案中使用 Azure Front Door 的詳細資訊，請參閱 在多租使用者方案中使用 Azure Front Door
驗證和授權
Azure App 服務可以 代表您的應用程式 驗證驗證權杖。 當 App Service 收到要求時，它會檢查是否符合下列每個條件：
- 要求包含權杖。
- 權杖有效。
- 要求已獲授權。
如果不符合任何條件，App Service 可以封鎖要求，也可以將使用者重新導向至您的識別提供者，讓他們可以登入。
如果您的租使用者使用 Microsoft Entra ID 作為其身分識別系統，您可以將Azure App 服務設定為使用 /common 端點 來驗證使用者權杖。 這可確保無論使用者的 Microsoft Entra 租使用者為何，其權杖都會經過驗證並接受。
您也可以將Azure App 服務與 Azure AD B2C 整合，以驗證取用者。
其他資訊：
存取限制
您可以使用存取限制 來限制應用程式的 流量。 這些可用來指定 IP 位址範圍或允許連線到應用程式的虛擬網路。
當您使用多租使用者解決方案時，請注意存取限制規則的最大數目。 例如，如果您需要為每個租使用者建立存取限制規則，可能會超過允許的規則數目上限。 如果您需要大量的規則，請考慮部署反向 Proxy，例如 Azure Front Door 。
隔離模型
使用 Azure App 服務 或 Azure Functions 處理多租使用者系統時，您必須決定您想要使用的隔離等級。 請參閱租使用者模型來考慮多租使用者解決方案，以及多租使用者解決方案 中計算架構方法中 提供的指引，以協助您為案例選取最佳的隔離模型。
當您使用 Azure App 服務 和 Azure Functions 時，您應該注意下列重要概念：
- 在 Azure App 服務 中，方案 代表您的裝載基礎結構。 應用程式代表在該基礎結構上執行的單一應用程式。 您可以將多個應用程式部署到單一方案。
- 在 Azure Functions 中，您的裝載和應用程式也會分開，但您有 額外的裝載選項可供 彈性裝載 ，其中 Azure Functions 會為您管理調整。 為了簡單起見，我們將裝載基礎結構視為 本文中的計畫 ，因為此處所述的原則適用于 App Service 和 Azure Functions，不論您使用的裝載模型為何。
下表摘要說明 Azure App 服務 和 Azure Functions 的主要租用隔離模型之間的差異：
| 考量事項 | 共用的應用程式 | 具有共用方案的每個租使用者的應用程式 | 每個租使用者的方案 |
|---|---|---|---|
| 設定隔離 | 低 | 一般。 應用程式層級設定專用於租使用者，共用方案層級設定 | 高。 每個租使用者都可以有自己的設定 |
| 效能隔離 | 低 | 中低。 可能受限於吵雜的鄰居問題 | 高 |
| 部署複雜度 | 低 | 中 | 高 |
| 作業複雜度 | 低 | 高 | 高 |
| 資源成本 | 低 | 視應用程式而定，低高 | 高 |
| 範例案例 | 具有共用應用層的大型多租使用者解決方案 | 將不知道租用的應用程式移轉至 Azure，同時獲得一些成本效益 | 單一租使用者應用層 |
共用的應用程式
您可以在單一方案上部署共用應用程式，並針對所有租使用者使用共用應用程式。
這通常是最符合成本效益的選項，而且需要最少的作業額外負荷，因為要管理的資源較少。 您可以根據負載或需求調整整體方案，而共用方案的所有租使用者都將受益于增加的容量。
請務必注意 App Service 配額和限制 ，例如可新增至單一應用程式的自訂網域數目上限，以及可布建的方案實例數目上限。
若要能夠使用此模型，您的應用程式程式碼必須是多租使用者感知。
具有共用方案的每個租使用者的應用程式
您也可以選擇在多個租使用者之間共用方案，但為每個租使用者部署個別的應用程式。 這可讓您在每個租使用者之間進行邏輯隔離，而此方法提供下列優點：
- 成本效益： 藉由共用裝載基礎結構，您通常會降低每個租使用者的整體成本。
- 設定區隔： 每個租使用者的應用程式都可以套用自己的功能變數名稱、TLS 憑證、存取限制和權杖授權原則。
- 升級區隔： 每個租使用者的應用程式二進位檔可以獨立于相同方案中的其他應用程式進行升級。
不過，因為方案的計算資源是共用的，因此應用程式可能受限於 Noisy Neighbor 問題 。 此外，可以部署至單一方案 的應用程式數量有一些 限制。
注意
請勿針對不同的租使用者使用 部署位置 。 位置不會提供資源隔離。 當您需要短時間內執行多個版本的應用程式，例如藍綠部署和 Canary 推出策略時，其設計適用于部署案例。
每個租使用者的方案
最強的隔離等級是部署租使用者的專用方案。 此專用方案可確保租使用者完全使用配置給該計畫的所有伺服器資源。
此方法可讓您調整解決方案，為每個租使用者提供效能隔離，並避免 Noisy Neighbor 問題 。 不過，其成本也較高，因為資源不會與多個租使用者共用。 此外，您必須考慮 可部署到單一 Azure 資源群組的方案 數目上限。
主機 API
您可以在 Azure App 服務 和 Azure Functions 上裝載 API。 您選擇的平臺將取決於您需要的特定功能集和調整選項。
無論您使用哪個平臺來裝載 API，請考慮在 API 應用程式前面使用 Azure API 管理 。 API 管理提供許多對多租使用者解決方案有説明的功能，包括下列各項：
- 所有 驗證 的集中式點。 這可能包括從權杖宣告或其他要求中繼資料判斷租使用者識別碼。
- 將要求路由傳送至不同的 API 後端 ，這可能以要求的租使用者識別碼為基礎。 當您使用自己的獨立 API 應用程式來裝載多個 部署戳記 時，這非常有用，但您需要針對所有要求擁有單一 API URL。
網路和多租使用者
IP 位址
許多多租使用者應用程式需要連線到租使用者的內部部署網路以傳送資料。
如果您需要從已知的靜態 IP 位址或從一組已知的靜態 IP 位址傳送輸出流量，請考慮使用 NAT 閘道。 如需如何在多租使用者解決方案中使用 NAT 閘道的詳細資訊，請參閱 多租使用者的 Azure NAT 閘道考慮。 App Service 提供 如何與 NAT 閘道 整合的指引。
如果您不需要靜態輸出 IP 位址，但您需要偶爾檢查應用程式用於輸出流量的 IP 位址，您可以 查詢 App Service 部署 目前的 IP 位址。
配額
因為 App Service 本身是多租使用者服務，因此您必須注意如何使用共用資源。 網路是一個您需要特別注意的區域，因為有一定 限制 會影響應用程式如何使用輸入和輸出網路連線，包括來源網路位址轉譯 （SNAT） 和 TCP 埠限制。
如果您的應用程式連線到大量的資料庫或外部服務，則您的應用程式可能會面臨 SNAT 埠耗盡 的風險。 一般而言，SNAT 埠耗盡表示您的程式碼未正確重複使用 TCP 連線，即使在多租使用者解決方案中，您也應該遵循重複使用連線的建議做法。
不過，在某些多租使用者解決方案中，相異 IP 位址的輸出連線數目可能會導致 SNAT 埠耗盡，即使您遵循良好的編碼作法也是如此。 在這些案例中，請考慮下列其中一個選項：
- 部署 NAT 閘道，以增加可供應用程式使用的 SNAT 埠數目。 如需如何在多租使用者解決方案中使用 NAT 閘道的詳細資訊，請參閱 多租使用者的 Azure NAT 閘道考慮。
- 當您連線到 Azure 服務時，請使用 服務端點 來略過負載平衡器限制。
即使已就地控制這些控制項，您仍可能會使用大量租使用者來接近限制，因此您應該計畫調整為額外的 App Service 方案或 部署戳記 。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- John Downs |適用于 Azure 的主要客戶工程師 FastTrack
其他投稿人：
- Thiago Almeida |主要程式管理員、Azure Functions
- 阿森·弗拉基米爾斯基 | 適用于 Azure 的主要客戶工程師 FastTrack
若要查看非公用LinkedIn設定檔，請登入 LinkedIn。
下一步
檢閱 多租使用者解決方案 架構設計人員和開發人員的資源。