2017 年 4 月

第 32 卷，第 4 期

本文章是由機器翻譯。

Azure - 新的 Azure App Service Environment

由Christina Compy | 2017 年 4 月

Azure App Service 環境 (ASE) 是一項進階功能的 Azure 應用程式服務供應項目。執行中提供網路隔離您的 Azure 虛擬網路 (VNet)，以滑鼠右鍵，並改善調整功能，它會讓 Azure 應用程式服務的單一租用戶執行個體。「 原始 」 功能提供給客戶什麼所尋找的網路控制和隔離方面，而不是以 「 平台即服務 (PaaS) 類似 」 做為一般的應用程式服務。這會造成混淆客戶，有一些麻煩，管理系統之間。與新 relaunched ASE，不過，現在一切多租用戶應用程式服務相同。

歷史

Azure 應用程式服務是裝載服務的多租用戶應用程式。如果您想要執行一項 PaaS 服務中的 HTTP 接聽程式，應用程式服務是最快速又輕鬆的方式，以移，並有許多開發人員支援的功能。您可以執行類似與連續整合 (CI) 系統整合作業、 調整應用程式時立即利用滑鼠以及其他等等。有限制，服務，不過，以封鎖特定使用案例。

無法符合應用程式服務主要是圍繞小數位數和應用程式隔離的多租用戶中的使用案例。雖然您可以輕鬆地調整您的應用程式，多租用戶應用程式服務中，則根據價格方案的限制。您可以調整應用程式，以在多租用戶應用程式服務的執行個體的最大數目為 20。

相隔離，對於沒有任何方法可在多租用戶應用程式服務在網路層級鎖定應用程式存取權。應用程式服務有兩個功能來存取 Azure 虛擬網路 (VNet) 整合和混合式連線，其他網路中的資源，但是沒有可以鎖定應用程式服務在網路層級和主應用程式完全隔離網際網路應用程式無法關閉應用程式。這表示您無法裝載您想在多租用戶應用程式服務僅適用於私人 IP 位址的特定業務 (LOB) 應用程式。

若要解決的縮放比例和隔離限制，我們 2015年提供高階 ASE 功能。它是在部署以使用較少的資源來執行相同的程式碼做為多租用戶應用程式服務，但有一些變更客戶的 VNet 中執行 Azure 應用程式服務的執行個體。

ASE 的第一個版本，可以調整最多 50 個執行個體，使用較大的專用背景工作。ASE 都能夠裝載 Web 應用程式、 行動應用程式、 API 應用程式和功能。ASE 是客戶的 VNet 中的子網路中執行，所以在 ASE 中的應用程式有資源可用在本身的 VNet 或跨 ExpressRoute 或站台對站 VPN 連線，讓您輕鬆存取。此外，如所示**[圖 1**，ASE 是客戶的子網路中，因為它可以限制存取其應用程式在網路層級使用網路安全性群組 (Nsg)。

[圖 1 App Service 環境高階網路模型

此部署的優點模型是可用於這兩個輸入和輸出 IP 位址在 ASE 中的應用程式的靜態 IP 位址。多租用戶應用程式服務的本質是多個租用戶所共用的輸入和輸出的位址。雖然也可以設定 IP SSL 的應用程式，並取得 IP 位址指派給該應用程式，但是沒有辦法鎖定的輸出位址。

裝載在 VNet 中的 ASE 是很好的開始，但它仍然無法完全解決隔離問題 ASE 首次發行時。ASE 仍然需要 HTTP/S 和發行存取的公用虛擬 IP (VIP)。它也僅部署在傳統 Vnet，這是許多客戶的問題。若要解決這些問題，起，支援 2016 年 6 月資源管理員的 Vnet，也用於內部負載平衡器 (ILBs)，如所示**[圖 2**。

[圖 2 App Service 環境高層級網路的內部負載平衡器

新增的 ILB 支援為了客戶現在可以裝載在雲端中的內部網路網站。您可能需要您不想網際網路存取，並將它部署至 ILB 啟用 ASE 的 LOB 應用程式。ILB 位於其中一個 VNet IP 位址，所以只能從存取 VNet 中或透過 VPN 存取 VNet 的主機。

ILB 啟用 ASE 打開了其他的可能性，例如 Web 應用程式防火牆 (WAF)-fronted 應用程式和兩層式應用程式。對於 WAF fronted ASE 的應用程式，客戶可以使用 WAF 虛擬裝置來做為網際網路端點針對其 ILB ASE 裝載應用程式，其會新增可存取網際網路的應用程式的額外的安全性層。在兩層式應用程式中，無法裝載 Web 存取的應用程式，在多租用戶應用程式服務或從另一個的 ASE 和後端保護 API 應用程式無法再裝載於 ILB ASE。如果您將多租用戶應用程式服務用於此一目的，您就可以安全地存取您的 API 應用程式，然後使用 VNet 整合功能。

當 ASE 原先的設計和計劃時，假設是它會考量 IT 專業人員會想要控制此應用程式服務的個人部署，如同它是在自己的資料中心內執行的系統。這一點之後，ASE 被設計為有彈性。ASE 有兩種角色類型來管理︰ 前端可做為應用程式和裝載應用程式的背景工作的 HTTP 端點。您可以擴充的數量，以及變更用於該角色類型的虛擬機器 (VM) 大小。

沒有特定的後果以為這種方式 — ASE 角色被視為資源，系統管理員可以獨立管理，但其實客戶不想或擁有其雲端服務的系統管理員。他們想要保持一樣容易使用做為多租用戶應用程式服務 ASE。需要管理的資源集區和他們的應用程式是太令人困惑，受影響的功能採用。

新的 ASE

（這我將其稱為 ASEv1） ASE 的初始版本已發行時，發生大量的意見反應，從客戶想，並發現它不符合其商務需求，其中一個原因或另一個。有關所提供的主要原因︰

• 管理 ASEv1 角色，以及他們的應用程式的複雜度是已經惡化，非直覺化。
• ASE 中加入更多容量時間太長。因為 ASEv1 交由系統管理員為其租用戶執行建置時，考量尚未與速度角色佈建。但事實上是當使用 ASEv1 時，向外延展 ASE 角色的人員，以及部署應用程式的使用者是通常同一個，並且延遲發生問題。
• 系統管理模型強制更注意 ASE 架構和行為的非他們想要的客戶。

把我們帶到新版本的 ASE，我將稱之為 ASEv2。核心小組所花的意見反應，並針對 ASEv2 我們著重於更 UX 相同，就是在多租用戶應用程式服務，而不會遺失 ASEv1 所提供的優點。

建立應用程式服務方案App Service 方案 (ASP) 是保留的所有應用程式調整容器。所有的應用程式都在 Asp，當調整 ASP 時，您正在也調整所有應用程式中的 ASP。多租用戶應用程式服務和 ASE，也是如此。這表示，若要建立應用程式您需要選擇或建立 ASP。在您需要選取 ASE 做為路徑，然後選取 [背景工作集區中所示的 ASEv1 中建立 ASP [圖 3。如果您想要部署至背景工作集區沒有足夠的容量，您必須在您可以在其中建立您的 ASP 之前加入更多背景工作。

[圖 3 建立的應用程式服務計劃中 ASEv1

與 ASEv2，當您建立 ASP 仍選取 ASE 做為路徑，但而不是選擇背景工作集區，您使用定價卡片之外 ASE 一樣。沒有更多的背景工作集區來管理。當您建立或調整您的 ASP 時，會自動加入必要的背景工作。

ASEv2 包含用來裝載您的應用程式的升級的 Vm。ASEv2 背景工作都建置於 Dv2 系列 Vm，勝過多租用戶應用程式服務中使用的背景工作。若要區別 ASE 中的 Asp，而多租用戶服務，已建立新價格 SKU。此 SKU 的名稱是隔離中所示**[圖 4**。當您選擇隔離的 SKU 時就表示您想在 ASEv2 中建立相關聯的 ASP。

[圖 4 建立的應用程式服務計劃中 ASEv2

建立 ASE妨礙 ASE 採用的問題之一是缺乏可見性。許多客戶還不知道 ASE 功能存在。若要建立 ASE，您必須尋找 ASE 建立流程，也就是完全分開建立應用程式。在客戶必須加入至其背景工作集區的背景工作，才能建立 Asp ASEv1。現在，建立或調整 Asp 時，會自動加入背景工作，ASEv2 建立體驗可將其置於玩意兒 ASP 建立流程中所示**[圖 5**。

[圖 5 App Service 環境建立應用程式服務計劃建立流程

若要建立新的 ASEv2 ASP 建立體驗期間，您只需選取非 ASE 區域，然後選取其中一個新的隔離 SKU 卡片。當您這樣做時，會顯示 ASE 建立 UI，可讓您建立新的或現有的 VNet 中的全新 ASEv2。

小數位數的時間加速提供新的工作者處理序是因為新的 ASP 建立流程也變得可行。當您建立或調整 ASP ASEv2 會自動佈建 Asp 新背景的工作。若要將此合理的客戶體驗的唯一方法是減少建立及向外延展所需的時間。若要將此工作時，儘可能已預先載入到最小化補充必要的重新開機的 Vhd 來佈建角色執行個體。移至 Dv2 工作者是也很有幫助他們有更快的核心，而且使用 SSDs。這兩個這些作法使安裝和重新啟動速度更快。

系統管理中 ASEv1 客戶必須管理前端結束背景工作和更新網域的背景工作。前端角色會處理 HTTP 流量，並將流量傳送到背景工作。背景工作可以裝載您的應用程式的 Vm。更新網域工作者做為備用的主機，在升級或背景工作失敗時。使用 ASEv1 客戶必須知道如何這些元件全部一起合作，並適當地調整資源集區。當背景工作有向外延展以處理多個 ASP 執行個體時，使用者必須加入更多前端和更新網域的背景工作。

ASEv2，相較之下，隱藏基礎結構。現在使用者只要向外擴充其應用程式服務計劃，並視需要加入基礎結構。當 ASP 需要更多背景工作時，會新增背景工作。前端和更新網域的背景工作會自動加入為向外擴充的背景工作數量。如果客戶有不尋常的需要，需要更積極的前端調整，他們可以變更前端加入至其 ASE 的速度。

如您所見 ASEv2 入口網站頁面中**[圖 6**，事情就簡單多了。不再需要的背景工作集區或前端 UI 頁面。現在所有的縮放比例是自動的會有與沒有更多的小數位數或自動調整控制項。ASE 所使用的 IP 位址是要了解很重要，因為 UI 彙總資訊。

[圖 6 App Service 環境的第 2 版入口網站頁面

ASEv2 版本是不可能是 ASE 功能的開發工作的結尾。那里仍將是穩定的資料流的改進，但不是會影響的範圍與 ASEv2 所做的變更並未 UX。

額外的好處ASEv2 對系統架構的變更，因為透過 ASEv1 有幾個額外的好處。使用 ASEv1，最大的預設小數位數是 50 的背景工作。已有許多系統架構為何該限制已設定，但在建立新的 ASEv2 經驗解決這些問題的原因。最大的預設小數位數與 ASEv2 現在是的 100，這表示您可以有最多 100 個 ASP 執行個體裝載於 ASEv2。這可以是從 100 個執行個體的 ASP 到 100 個別的可靠性與任何項目之間的任何項目。

此外，ASEv2 現在是使用 Dv2 架構專用的背景工作。這些新的專用背景工作的速度比 A 系列 Vm ASEv1 依存性。它們有更快的 Cpu，進而改善產能和 SSDs，進而改善檔案存取效能。多租用戶應用程式服務，例如，適用於專用的背景工作時建立 ASP 會單一核心、 雙核心或四核心。新的 ASE 專用背景工作，但是有兩倍多租用戶對應的記憶體，而分別隨附 3.5 GB，7 GB 或 14 GB 的 RAM。

總結

ASEv1 是絕佳的第一個步驟讓客戶可以將其應用程式服務主控之應用程式的網路隔離等級。ASEv2 上建置，遇到了更類似 PaaS 的功能，不只是容易使用，但還有更強大。

所有變更已記下以下的 ASE 物件有大量的 Mvp 和客戶的驗證。即使開發程序開始之前，小組會想要驗證其方法與已經曾經嘗試使用 ASE 的人。這個輸入嚴謹的方法，因為我們很確信新 ASE 經驗會被視為大幅提升，而且很期待在欄位中成功。

Christina Compy原本是航太工程師哈伯太空望遠鏡上運作正常，而且已在軟體產業 20 年以上。 她已自 2013年的 Microsoft 和適用於企業導向的專屬功能的專案經理。

感謝下列 Microsoft 技術專家來檢閱這份文件︰  Stefan Shackow
Stefan 是 Azure 應用程式服務小組的專案經理提供其不曾自 web 應用程式定域機組已處理的使用者。在 Azure 中，Stefan 會導致一群開發和部署 Azure 應用程式服務，以及 Microsoft 在內部部署/雲端混合式產品的開發人員程式管理員。