共用方式為

  • 發行項

2017 年 2 月

第 32 卷，第 2 期

本文章是由機器翻譯。

Azure - 一窺 Azure App Service 結構

由Yochay Kiriaty | 2017 年 2 月

Azure 應用程式服務會被視為的絕佳平台即服務 (PaaS)，提供開發人員建置 Web、 行動及 API 應用程式的應用程式平台。它的供應項目範圍從簡單的行銷和數位存在可擴充的電子商務解決方案的應用程式和超小數位數、 可自訂的應用程式。

應用程式服務是完全受管理，這表示沒有系統管理工作所需管理底線計算基礎結構 （伺服器） 執行您的應用程式。您不需要擔心平台就修補程式的作業系統和架構底線伺服器維護。虛擬化的伺服器上執行的應用程式，但您應該只負責設定想要讓應用程式執行的伺服器執行個體數目上限。調整應用程式需要其他的平台控點的計算資源，並在此同時，它會處理流量負載平衡跨多個應用程式執行個體。

雖然應用程式服務小組進行地隱藏任何加上底線的實作詳細資料，最好要注意的項目在封面的運作方式。本文涵蓋基本的內部架構的應用程式服務 （服務建置和方式運作），並提供一些最佳作法特定案例。

全域和地理位置分散的架構

雲端運算快速調整，且具有無止盡的容量。雲端規模可以解釋一樣，在電腦螢幕上看起來。尋找從 afar，您會看到清晰且平滑的圖片。進一步了解時，您會注意到螢幕上的映像包含許多小小的像素為單位。定域機組，像是映像，包括許多伺服器。應用程式服務叢集群體的伺服器成單一單元，稱為 「 延展單位 」 （或 「 戳記 」）。有許多這類縮放單位全球 Azure 資料中心。

Azure 的一部分，應用程式服務沒有遍佈全球。在每個 Azure 支援的區域，您會發現應用程式服務縮放單位執行客戶工作負載 （應用程式） 及地區控制單位的集合。控制單位而言是透明的客戶 （直到它們故障），與在平台的一部分。沒有用於做為閘道管理的所有 API 呼叫的一個特殊的控制項單位。比方說，當客戶提出的要求，以建立新的應用程式，透過入口網站中，命令列介面，或是直接透過 Azure REST API，將要求路由到中央的 Azure 端點 (management.azure.com)。Azure 資源管理員或 ARM (bit.ly/2i6UD07)，可讓您在單一群組的應用程式中使用不同的 Azure 資源。由 ARM 所定義的 API 可讓您管理 Azure 資源。ARM 實際上並不管理個別資源。在 Azure 中的各服務都有它自己是由 ARM 所代理的管理 API 實作。應用程式服務的情況 ARM 會轉送至應用程式服務地理主機的任何應用程式服務 API 呼叫。

地理區域主要內容，說明所有的縮放單位全球有。比方說，當您建立新的應用程式服務應用程式 （或網站），地理主要應用程式找到最適合的縮放單位，然後建立要求轉送給適當的縮放單位縮放單位現在被負責提供新的應用程式，並配置所需的資源。[圖 1顯示建立新的應用程式的流程。

全域發佈的應用程式服務縮放單位
[圖 1 全域發佈的應用程式服務縮放單位

以下是建立新的應用程式的程序︰

  1. 使用者提出要求來建立新的網站。
  2. ARM 可確保使用者具有存取權以允許指定的運算資源 （在此情況下建立） 並將要求轉送到應用程式服務地理主機。
  3. 地理區域主要使用者的要求中尋找最佳的適當縮放單位及轉送要求。
  4. 縮放單位會建立新的應用程式。
  5. 地理區域主要報表建立要求成功。

雖然並不一定要了解應用程式服務有許多的縮放單位，您的應用程式通常會執行內的單一應用程式服務縮放單位。即使是使用 Azure 流量管理員來執行多個區域中，您的應用程式會執行兩個或多個不同的縮放單位中。不過，從個別的延展單位觀點來看，您的應用程式限制為單一縮放單位。

什麼是 App Service 縮放單位？

應用程式服務縮放單位是裝載並執行您的應用程式伺服器的集合。一個典型的縮放單位可以有 1000 個以上的伺服器。伺服器叢集可讓標尺的經濟環境中，重複使用的共用基礎結構。應用程式服務擴充單元基本的建置組塊是 Azure 雲端服務部署 （請記住，在 2012 年 6 月預覽首次發行應用程式服務）。任何指定的縮放單位是自發而且可以作用於其本身。

調整單位主要建置組塊

縮放單位的主要功能是裝載和執行客戶應用程式。應用程式在 Windows 伺服器上執行，稱為 「 Web 背景工作 」 或 「 背景工作簡稱。大部分的伺服器中的特定的縮放單位是背景工作。不過，規模單位包含數個達成應用程式服務所提供的功能所需的其他支援伺服器。支援伺服器有角色，而且每個角色部署的備援和小數位數的多個執行個體上。

前端

前端是圖層七個負載平衡器，做為 proxy，將不同的應用程式和其個別的背景工作之間的內送 HTTP 要求。目前應用程式服務的負載平衡演算法是簡單的循環配置資源之間的一組伺服器配置給特定的應用程式。

Web 背景工作

背景工作可以應用程式服務擴充單元骨幹。執行您的應用程式。

應用程式服務時，您可以選擇您要執行應用程式的方式。您可以選取共用或專用伺服器上執行您的應用程式。您這樣做，選取 [應用程式服務方案。應用程式服務方案會定義一組功能、 功能和伺服器配置。共用背景工作裝載來自多個不同的客戶，確保專用背景工作執行的單一客戶的一或多個應用程式的應用程式。有數個專用的伺服器類型和大小，您可以從中選擇。伺服器越大，更多的 CPU 和記憶體資源可供配置的應用程式。「 應用程式服務計劃定義您的應用程式的預先配置伺服器數量。

應用程式服務縮放單位中所示，有數個集區的工作者預先佈建並且可裝載應用程式， [圖 2、 第 1 節。當您定義您專屬的應用程式服務方案兩部伺服器的大小時，應用程式服務會配置兩部伺服器，如所示**[圖 2、 第 2 節**。接下來，當您向外擴展您的應用程式服務計劃 — 例如，加入更多的兩個背景工作 — 從已備妥要移至背景工作集區配置可用的背景工作中所示**[圖 2、 第 3 節**。工作者已預先佈建和準備，因為必須要做的是您的應用程式部署在背景工作上。應用程式部署之後，工作者插入旋轉和前端可配置給它的流量。這整個程序通常需要幾秒鐘。

應用程式服務縮放單位中的伺服器應用程式處理序
[圖 2 應用程式服務縮放單位中伺服器應用程式處理序

[圖 2、 第 4 節顯示多個應用程式服務計劃，每個均代表應用程式服務計劃可以屬於多個客戶識別為多彩的矩形。

檔案伺服器

任何應用程式需要儲存空間來保存內容，例如 HTML、.js 檔案、 影像或程式碼檔案和應用程式運作所需的任何其他內容。檔案伺服器掛上 Azure 儲存體 blob，並將它們公開為背景工作的網路磁碟機。背景工作，對應為 [本機]，這類網路磁碟機允許任何應用程式在任何給定的背景工作上執行使用的 「 區域 」 的磁碟機，就像您預期的應用程式如果使用其本機磁碟的伺服器上執行。透過檔案伺服器來傳送應用程式所執行的任何檔案相關的讀取/寫入作業。

API 控制器

API 控制器可視為擴充至應用程式服務地理主機。雖然地理主要是知道的所有應用程式服務應用程式分散至所有縮放單位，就會影響您的應用程式的管理作業會實際執行的 API 控制器。地理區域主要委派 API fulfilment 到透過 API 控制器指定的縮放單位。例如，當地理 Master 通過 API 呼叫來建立新的應用程式，API 控制器會協調流程在縮放單位中建立應用程式所需的步驟。當您使用 Azure 入口網站來重設您的應用程式時，它是通知目前配置給您的應用程式重新啟動您的應用程式的所有 Web 背景工作的 API 控制器。

發行者

Azure App Service 支援 FTP 存取任何應用程式。應用程式內容是儲存在 Azure 儲存體 blob 和對應的檔案伺服器，因為應用程式服務都有公開 FTP 功能 「 發行者 」 角色。「 發行者 」 角色可讓客戶使用 FTP 存取其應用程式內容和記錄檔。

請務必注意，有許多其他部署方式 FTP 以外的應用程式。常見的部署方法的其中一個是 Web Deploy （從 Visual Studio)，或任何支援的持續部署選項，例如 Visual Studio 發行管理員或 GitHub。

SQL Azure

每個應用程式服務縮放單位會使用 Azure SQL 資料庫來保存應用程式中繼資料。指派給指定的小數位數單位每個應用程式都有表示方式，在 SQL 資料庫。SQL 資料庫也會用來保存應用程式的執行階段資訊。

資料角色

所有角色都需要在操作資料庫中找到的資料。做為範例︰ Web 背景工作時啟動應用程式; 所需的站台組態資訊前端需要知道哪些伺服器指派給執行特定的應用程式，以便能夠正確地轉送到適當的伺服器的 HTTP 要求而且，控制站讀取和更新根據客戶所進行的 API 呼叫的資料庫中的資料。資料角色可以稱為 SQL 資料庫之間的小數位數的指定單位中的所有其他角色快取層級。它會擷取資料層 (SQL Database) 的角色，改善延展性和效能，以及簡化軟體開發和維護的其餘部分。

較不比明確的最佳作法

既然您知道如何建置 Azure 應用程式服務，我們會檢閱幾個秘訣和訣竅，從應用程式服務小組。這些是由應用程式服務與 numerus 客戶合作的工程團隊的實際操作經驗。

控制密度

大部分的客戶執行少量 (小於 10) 的每個應用程式服務方案的應用程式。不過，有許多案例中執行客戶許多更多的應用程式。請務必避免不小心透過飽和的基礎伺服器的計算容量。

讓我們開始基本應用程式和其運算資源的階層。有兩個 Web 應用程式和一個行動後端應用程式與此應用程式服務方案相關聯。計劃設定為兩部伺服器。

根據預設，包含在指定的應用程式服務方案的所有應用程式執行的所有可用計算資源 （伺服器） 配置給該服務計劃。這兩部伺服器上，執行所有三個應用程式。在簡單的情況下，應用程式服務方案都有一部伺服器時，很容易理解︰ 所有應用程式服務計劃中的應用程式執行單一伺服器上。

它是較不直覺化，並有多個計算資源配置給 App Service 方案時，會發生什麼事。例如，如果單一應用程式服務計劃有 10 計算資源，然後在應用程式服務中的每個應用程式會在每個計算資源上執行。如果有 50 個應用程式服務計劃中的應用程式，所有 50 都執行第一部伺服器，並將在第二個伺服器上，都執行相同的 50 等等，到 10 的伺服器，其都執行所有的 50 應用程式。

某些情況下，您的應用程式需要大量計算資源，通常是為了處理內送 HTTP 要求，增加的位置，您要將所有可用的伺服器上執行的應用程式。不過，有時候這是無心 App Service 方案向外延展從一部伺服器為許多時發生。如果應用程式服務方案是來自應用程式中，執行大量的 CPU 及/或記憶體壓力下增加的伺服器數目，因為應用程式服務方案無法解決問題。

相反地，考慮流量分配，每個應用程式，並分隔到個別的應用程式服務方案長尾端的小型應用程式。請考慮在不同的應用程式服務計劃執行大量的應用程式。使用 50 個應用程式範例更早版本，分析流量模式後您可能會得到下列配置到應用程式服務計劃和計算資源︰

  • 40 小量應用程式在單一應用程式服務計劃中一個計算資源上執行。
  • 五個到低 mid-磁碟區的應用程式使用第二個應用程式服務計劃一個計算資源上執行。
  • 其餘的五個應用程式會發現有大量的使用量。每個應用程式部署到個別的應用程式服務方案。  每個應用程式服務計劃使用最少一個計算資源，來調整輸入/輸出根據的 CPU 和記憶體使用率規則上設定自動調整規則。

這種方法的最後結果是 50 個應用程式時，至少每個皆獨立向外延展，視所需的空餘空間根據負載的五個大量的應用程式使用七個計算資源。

每個應用程式調整

以更有效率的方式執行大量的應用程式的另一個替代方式是使用 Azure 應用程式服務的每個應用程式擴充功能。在文件bit.ly/2iQUm1S涵蓋每個應用程式詳細資料中的縮放比例。每個應用程式調整可讓您控制配置給指定的應用程式伺服器的數目上限和每個應用程式可以執行。在此情況下，應用程式將執行的伺服器定義的最大數目，而不是在所有可用的伺服器。

使用較早的 50 應用程式的範例，但每個應用程式調整 App Service 方案，啟用所有的 50 應用程式可以指派給相同的應用程式服務方案。然後，您可以修改調整個別的應用程式的特性︰

  • 40 小量應用程式設定在單一伺服器每個最大值上執行。
  • 五個 mid-以小型應用程式設定為最多兩部伺服器上執行。
  • 五個剩餘的大量應用程式設定為最多 10 部伺服器上執行。

基礎的應用程式服務方案可以開始在最少的五部伺服器。然後設定自動調整規則，向外延展，以根據所需的記憶體不足的壓力。CPU。

Azure 應用程式服務將會自動處理應用程式，以計算資源的指派。服務也會自動處理條件約束的執行背景工作數目為基礎的應用程式執行個體數目上限設定為每個個別的應用程式。如此一來，增加的數字的應用程式服務計劃中的背景工作不會導致向上微調每個新的可用虛擬機器上的 50 個應用程式執行個體。 

簡單來說，每個應用程式調整 「 套件 」 到基礎應用程式服務方案相關聯的伺服器上的應用程式。每個應用程式調整不會導致每個與 App Service 方案相關聯，如先前所述的每個計算資源上執行的應用程式。

應用程式位置

應用程式服務有一項稱為 「 部署位置 」 功能 (bit.ly/2iJzv3f)。簡單的說，部署位置可讓您有另一個應用程式 （位置） 以外的生產應用程式。就測試新的程式碼，在交換到生產環境之前，您可以使用的另一個應用程式。

應用程式的位置就是在 App Service 中最常使用的功能。不過，務必了解每一個應用程式的位置也是應用程式本身。這表示應用程式的位置可以有不同，SSL 憑證、 不同的應用程式設定等相關聯的自訂網域。這也表示可以分開管理的應用程式服務計劃應用程式位置指派，從應用程式服務方案相關聯的主要生產位置。

根據預設，每一個應用程式的位置會建立在同一個應用程式服務方案與生產位置。小型應用程式，及/或低記憶體使用率的應用程式，這種方法是正常的。

不過，因為相同的伺服器上，執行應用程式服務計劃中的所有應用程式，這表示根據預設，所有應用程式的位置與生產環境完全相同基礎的伺服器執行。這可能會導致問題，例如 CPU 或記憶體條件約束如果您決定對生產應用程式位置的相同伺服器執行的非生產位置執行壓力測試。

如果資源競爭只限於案例，例如執行負載測試，然後暫時將某個位置移到其他應用程式服務方案，與它自己一組伺服器，將會執行下列作業︰

  • 建立其他應用程式服務方案的非生產位置。重要事項： 每個應用程式服務方案必須位於相同的資源群組與生產位置的應用程式服務方案相同的區域中。
  • 將非生產位置移至不同的應用程式服務方案，並因而個別計算資源集區。
  • 在個別的應用程式服務方案執行時執行需要大量資源 （或風險） 的工作。例如，負載測試可以對非生產位置執行，不會影響到生產位置，因為不會有任何資源爭用的情況。
  • 非生產位置交換到生產的準備時，將其移回至相同應用程式服務方案執行生產位置。然後位置交換作業可以執行。

部署至生產環境沒有停機時間

已成功執行應用程式服務方案的應用程式，而且您具有優秀的團隊可讓您的應用程式每日更新。在此情況下，您不想直接在實際執行部署位元。您想要控制部署，並且縮短停機時間。對此您可以使用您應用程式的位置。將您的部署設定為 「 預先生產 」 位置，可以使用生產設定來設定和部署最新的程式碼。您現在可以安全地測試您的應用程式。一旦您滿意，您可以交換到生產的新位元。交換作業不會重新啟動您的應用程式並回報控制器通知前端負載平衡器將流量重新導向至最新的位置。

某些應用程式需要暖機之前所能安全地處理生產負載 — 例如，如果您的應用程式需要將資料載入至快取，或允許.NET 執行階段以 jit 編譯的組件的.NET 應用程式。在此情況下，也要準備您的應用程式交換至生產環境之前使用應用程式的位置。

我們常看到客戶遭遇預先生產位置，用來測試和準備應用程式。若要設定管線的程式碼，以取得部署到生產位置，執行測試的驗證延遲和暖之前交換到生產應用程式中的所有必要的路徑前，您可以使用連續的部署工具如 Visual Studio 發行管理員。

調整單位網路組態

雲端服務部署的應用程式服務擴充單位。這麼一來，就表示某些網路組態，您可能熟悉完全了解您的應用程式上的任何網路影響的功能。

縮放單位已對外界公開的單一虛擬 IP (VIP) 位址。配置給的小數位數的指定單位的所有應用程式會透過此 VIP 服務。VIP 是雲端服務部署的應用程式服務擴充單位的表示法。

應用程式服務應用程式只提供 HTTP （連接埠 80） 和 HTTPS （連接埠 443） 流量。每個應用程式服務應用程式的預設內建的 HTTPS 支援 azurewebsites.net 網域名稱。應用程式服務支援伺服器名稱指示 (SNI) 和 IP 型 Secure Sockets Layer (SSL) 憑證。在 IP SSL 的情況下指定的應用程式就會配置只輸入流量，也就是相關聯的雲端服務部署專用的 IP 位址。請注意： 前端終止所有的 HTTPS 要求的所有應用程式和任何型別之憑證的 SSL 連線。前端接著會將要求轉送至特定應用程式的指定背景工作。

公開 VIP

根據預設，沒有單一的公用 VIP，所有輸入的 HTTP 流量。任何應用程式是單一 VIP 來定址。如果您的應用程式服務有應用程式，嘗試執行 nslookup 命令 （從 Windows 或 PowerShell 主控台），並查看結果。以下為範例：

#1 PS C:\> nslookup awesomewebapp.azurewebsites.net
#2 Server:  UnKnown
#3 Address:  10.221.0.3
#4 Non-authoritative answer:
#5 Name:    waws-prod-bay-001.cloudapp.net
#6 Address:  168.62.20.37
#7 Aliases:  awesomewebapp.azurewebsites.net

以下是輸出的檢閱 awesomewebapp.azurewebsites.net:

  • #1 行執行 nslookup 查詢 awseomwebapp.azurewebsites.net 的解析度。
  • 線 #5 顯示正在執行 awseomwebapp 應用程式的延展單位的網域名稱。您會發現應用程式服務縮放單位部署於 Azure 雲端服務 （由 cloudapp.net 後置詞）。（當 Azure 仍稱為 Windows） WAWS 代表 Windows azure 網站 （應用程式服務的原始名稱）。
  • 線 #6 顯示縮放單位的 VIP。所有的應用程式上執行，以及裝載 waws-prod-灣-001 (列 #5) 來定址上指定的公用 VIP。
  • 線 #7 顯示對應至相同的 IP 位址的所有網域別名。

輸出的 Vip

最有可能您的應用程式會連接到其他 Azure 和非 Azure 服務。這麼一來，您的應用程式會讓輸出網路呼叫的端點不是在您的應用程式的延展單位。這包括 Azure 服務，例如 SQL Database 和 Azure 儲存體向外呼叫。有最多五個 Vip （一個公開 VIP 和四個輸出的專屬的 Vip） 用於輸出通訊。您無法選擇哪些應用程式使用的 VIP，並從縮放單位中的所有應用程式的所有傳出呼叫使用五種配置的 Vip。如果您的應用程式會使用白名單 Ip，才能進行這類服務的 API 呼叫都需要您的服務，您必須註冊縮放單位的所有五個 Vip。若要檢視哪些 Ip 會配置給輸出 Vip 小數位數的指定單位 （或您的應用程式的角度來看） 移至 Azure 入口網站中所示**[圖 3**。

在 Azure 入口網站應用程式服務應用程式輸出 IP 位址檢視
[圖 3 應用程式服務應用程式輸出 IP 位址 Azure 入口網站中檢視

如果您正在尋找一組專用的輸入和輸出 Ip，您可以探索這使用完全隔離和專用 App Service 環境在bit.ly/2hVRSlR。

IP 和 SNI SSL

應用程式服務支援以 IP 為主的 SSL 憑證。使用 IP SSL 時，應用程式服務會配置給您的應用程式專用的 IP 位址只傳入 HTTP 流量。

不同於 Azure 的固定 IP 位址的其餘部分，會將應用程式服務，透過 IP SSL 的 IP 位址配置，只要您選擇使用它。您沒有 IP 位址，當您刪除您的 IP SSL 時，您可能會遺失的 IP 位址 （因為它可能配置給不同的應用程式）。

應用程式服務也支援 SNI SSL，這並不需要專用的 IP 位址，且支援現代瀏覽器。 

網路連接埠的輸出網路呼叫的數量

應用程式的常見需求是能夠進行輸出網路呼叫至其他網路端點。這包括 Azure 內部的服務，例如 SQL Database 和 Azure 儲存體向外呼叫。它也包含應用程式呼叫 API HTTP/HTTPS 端點的位置的情況下，例如 Bing 搜尋 API 的呼叫或呼叫 API 「 應用程式 」，會實作 Web 應用程式後端商務邏輯。

在幾乎所有這些情況下，以隱含方式是開啟網路通訊端和執行傳出呼叫的端點，會被視為 「 遠端 」 從 Azure 網路的觀點來呼叫 Azure 應用程式服務上執行的應用程式。這是很重要的一點，因為從 Azure 應用程式服務上執行遠端端點的應用程式呼叫依賴 Azure 網路設定和管理網路位址轉譯 (NAT) 對應的資料表。

在這個 NAT 對應中建立新的項目很耗時，而且只是有限度的限制，可以建立單一的 Azure App Service 縮放單位的 NAT 對應的總數。因此，應用程式服務會強制執行的時間可以在任何給定時間點存在的傳出連線數目限制。

最大連接限制如下所示︰

  • 每個 B1/S1 P1 執行個體 1,920 連線
  • 每個 B2/S2 P2 執行個體 3,968 連線
  • 每個 B3/S3/P3 執行個體 8,064 連線
  • 64k 最大上限的限制每個 App Service 環境

「 遺漏 」 的連線不會改變的應用程式執行這些連線限制。應用程式會啟動間歇性失敗，因為遠端端點的呼叫失敗，但有時候相互關聯密切至較高的應用程式載入期間失敗。您會經常看到類似下列的錯誤︰ 「 嘗試存取其存取權限 aaa.bbb.ccc.ddd 所禁止的方式通訊端。 」

有一些最佳作法，可以大幅減輕遇到此問題的可能性︰

  • 使用 ADO.NET/EF.NET 應用程式，您可以使用資料庫連線集區。
  • Php/mysql，在使用持續資料庫連線。
  • 若是 Node.js 應用程式進行輸出 HTTP/HTTPS 呼叫，設定持續作用，重複使用的輸出連線。此設定在描述bit.ly/2iGrcoo。
  • 對於.NET 應用程式進行輸出 HTTP/HTTPS 呼叫，集區和重複使用 System.Net.Http.HttpClient 的執行個體或使用 System.Net.HttpWebRequest 保持連線。注意: 請務必增加 System.Net.ServicePointManager.DefaultConnectionLimit，因為否則會限制為兩個並行的傳出連線至相同的端點。

有其他應用程式服務沙箱所加諸的限制。這些是較低層級限制和條件約束，供 Azure App Service 和詳細閱讀這些bit.ly/2hXJ6lL。

總結

Azure 應用程式服務 Web、 行動及 API 應用程式提供豐富的 PaaS 供應項目。雖然服務有許多移動的內部組件，這些被抽象，讓開發人員可以專注於撰寫卓越的應用程式時，此服務處理全球規模執行這些應用程式的複雜性。 

許多應用程式服務的最佳作法是調整應用程式。深入了解如何將應用程式對應到應用程式服務計劃中的 Web 背景工作相當重要，因為增加您的應用程式執行服務時，同時仍維持最佳的縮放設定。

指定雲端優先世界中操作，Azure 和 Azure App Service 永遠不斷演變的腳步。多項創新都必須在 2017年。

調整單位元件

它看起來好像調整單位元件是取決於彼此。不過，根據設計，它們是鬆散耦合。目前正在執行指定的 Web 背景工作 （主動處理 HTTP 流量） 的應用程式可以繼續提供 HTTP 流量，即使縮放單位中的其他角色都無法正常運作。

比方說，「 發行者 」 未正常運作，可能會妨礙 FTP 存取，但是，不會影響應用程式的 HTTP 流量或其他部署選項。如果控制器有錯誤，造成無法建立新的應用程式，它並不表示已指派給縮放單位的應用程式停止運作。

Yochay Kiriaty是 Microsoft Azure 團隊，特別推動 Web、 行動裝置、 API 的首席程式經理和函式體驗 Azure App Service 平台的一部分。 Kiriaty 從事 Web 技術工作自晚期 90s，熱衷於規模和效能。您可以與他連絡︰ yochay@microsoft.com ，關注他的 Twitter: @yochayk。

Stefan Schackow是 Azure 應用程式服務小組的專案經理提供其不曾自 Web 應用程式定域機組已處理的使用者。 在 Azure 中，他領導團隊的開發和部署 Azure 應用程式服務，以及 Microsoft 在內部部署/雲端混合式產品 （Azure Pack 和 Azure Stack） 的開發人員程式管理員。他的連絡stefsch@microsoft.com。

感謝下列 Microsoft 技術專家來檢閱這份文件︰ Eduardo Laureano 和 Nir Mashkowski