2017 年 4 月

第 32 卷，第 4 期

通过 Christina Compy | 2017 年 4 月

Azure App Service 环境 (ASE) 是一项高级功能的 Azure 应用程序服务的产品/服务。运行正题提供网络隔离自己 Azure 虚拟网络 (VNet)，改进了缩放功能，它使 Azure App Service 的单租户实例。原始功能向客户传达了它们当时在查找什么网络控制和隔离方面，而不是作为"平台即服务 (PaaS) 像"作为正常的应用程序服务。这会引起客户，有一些难以管理系统之间的混淆。与新 relaunched ASE，但是，现在工作与多租户应用程序服务相同。

发展历史

Azure App Service 是承载服务的多租户应用程序。如果您想要在 PaaS 服务中运行 HTTP 侦听应用程序，应用程序服务是一种非常快速而简单的方法，以转和具有许多开发人员支持功能。您可以执行某些操作，如与持续集成 (CI) 系统集成，缩放您的应用程序出可立即使用鼠标和其他更多的笔势。有到服务，但是，阻止特定用例的限制。

无法在多租户应用程序服务很大程度上围绕缩放和应用程序隔离中满足这些用例。尽管您可以在多租户应用程序服务中轻松地缩放您的应用程序，有一些限制基于价格计划。您可以在多租户应用程序服务缩放应用程序的实例的最大数量为 20。

隔离，方面是没有办法在多租户网络级别上的 App Service 中锁定对您的应用程序访问。应用程序服务有两个功能来访问其他 Azure 虚拟网络 (VNet) 集成和混合连接的网络中的资源，但没有任何可以在 App Service 中锁定在网络级别和承载完全与 Internet 隔离应用程序不能向下的应用程序。这意味着您无法承载您想要将其仅适用于专用的 IP 地址在多租户应用程序服务的业务线 (LOB) 应用程序。

若要解决的缩放和隔离的限制，我们提供于 2015 年的高级 ASE 功能。它是运行在客户的 VNet 中运行相同的代码为多租户应用程序服务，但具有某些更改部署，以使用较少的资源的 Azure 应用程序服务实例。

ASE 的第一个版本无法缩放最多 50 个实例，并使用更大的专用辅助角色。ASE 都能够托管 Web 应用程序、 移动应用程序、 API apps 和函数。由于 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，这是许多客户的问题。若要解决这些问题，支持添加在 6 月 2016年资源管理器 Vnet，还负责内部负载平衡器 (ILBs) 中所示图 2。

图 2 App Service 环境使用内部负载平衡器的高级网络

添加 ILB 支持意味着客户现在可以托管在云中的 intranet 站点。你可能需要花费不想进行 Internet 访问，并将其部署到您 ILB 启用 ASE 的 LOB 应用程序。ILB 位于其中一个 VNet IP 地址，因此只能在 VNet 内部或从主机有权访问 VNet 通过 VPN 访问。

ILB 启用 ASE 开启了其他功能，如 Web 应用程序防火墙 (WAF) 的前面是应用程序和两个层应用程序。对于 WAF 前面 ASE 应用程序，客户可以使用 WAF 虚拟设备作为 Internet 的终结点为其 ILB ASE 托管的应用程序，也就是添加额外的安全层用于 Internet 访问的应用程序。在两层应用程序中，可通过 Web 访问的应用程序无法在多租户应用程序服务或从另一个 ASE 承载后, 端保护 API 应用程序无法再承载 ILB ASE 中。如果您使用多租户应用程序服务对此类用途，将使用 VNet 集成功能可以安全地访问您的 API 应用程序。

当 ASE 最初的设计和计划时，这样做是假定它将满足 IT 专业人员想要控制此个人部署的应用程序服务，就像它是他们在其自己数据中心中运行的系统。这一点，ASE 设计得非常灵活。ASE 中有两种角色类型来管理︰ 前端 act 作为应用程序和托管应用的工作人员的 HTTP 终结点。您可以横向扩展的任何一个，数量，以及更改为该角色类型使用的虚拟机 (VM) 的大小。

没有考虑这种方式对某些结果 — ASE 角色则被视为系统管理员将独立管理的但事实证明，资源的客户不想为，或将其云服务的系统管理员。他们想 ASE 保持易用作为多租户应用程序服务。无需管理资源池和他们的应用程序是太令人困惑，受影响功能采用。

新 ASE

在 ASE （其中我将称它为 ASEv1） 的初始版本后就发布后，没有它试用并找到它并不适合其业务需求的一个原因或另一个客户的大量反馈。他们所提供的主要原因而言︰

• 管理 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 包括升级用于承载您的应用程序的虚拟机。工作进程供 ASEv2 基于 Dv2 系列 Vm，并在多租户应用程序服务中使用的工作人员的性能优于。若要区分是 ASE 中的 Asp 和多租户服务中的那些，已创建新的定价 SKU。此 SKU 的名称是分离后，请如中所示图 4。当您选择独立 SKU 则表示您希望在 ASEv2 中创建关联的 ASP。

图 4 创建 App Service 计划中 ASEv2

创建 ASE受阻 ASE 采用的其他问题之一是它没有可见性。许多客户甚至不知道 ASE 功能已存在。若要创建 ASE 中，您必须寻找 ASE 创建流程，这是完全独立于应用程序创建。在客户不得不将工作人员添加到他们的工作线程池，才能创建 Asp ASEv1。现在，Asp 创建或扩展时，将自动添加工作人员，ASEv2 创建体验可放置完全落在 ASP 创建流程，如中所示图 5。

图 5︰ 创建 App Service 环境从 App Service 计划创建流程

若要创建新 ASEv2 在 ASP 创建体验期间，您只需选择非 ASE 区域，然后选择一个新的独立 SKU 卡。执行此操作时，将显示 ASE 创建用户界面，这样您就可以在新的或预先存在的 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 所做的更改的范围内的用户体验。

**更多好处，**由于对系统体系结构所做的更改，ASEv2 中通过 ASEv1 还有几个其他好处。ASEv1，最大默认的小数位数是 50 工作人员。出现了大量的系统体系结构为什么该限制选项已设置，但没有创建新的 ASEv2 体验提出这些问题的原因。与 ASEv2 最大默认的小数位数现在为的 100，这意味着您可以具有最多 100 个 ASEv2 中承载的 ASP 实例。这可以是任何内容，从 100 单个 asp 而言，与其他任何知识 ASP 的 100 个实例。

此外，ASEv2 现在使用基于 Dv2 的专用辅助角色。这些新的专用工作线程都比 ASEv1 依存的在其的 A 系列 Vm 快得多。他们可以更快的 Cpu，这样可以提高吞吐量和固态硬盘，从而提高了文件访问性能。如下所示的多租户应用程序服务，专用辅助角色创建 ASP 时的选项是单核、 双核或四核。新的 ASE 专用工作线程，但是，有两倍多租户的对应的内存，并且分别有 7 GB 或 14 GB 的 RAM，3.5 GB。

总结

ASEv1 是使客户能够具有其应用服务承载的应用程序的网络隔离的朝向第一个重要步骤。ASEv2 上构建的体验更加类似于 PaaS 功能会不只是易于使用，但也是功能强大得多。

所有更改此处的 ASE 记录具有已审查大量 Mvp 和客户。即使开发启动之前，团队想要验证它已尝试使用 ASE 中的人的方法。由于此输入繁重方法时，我们确信新 ASE 体验将被视为一项重大改进，期待的字段中其成功。

Christina Compy最初是从事哈勃空间望远镜和 20 年以上使用在软件行业航空航天工程师。 她已经工作面向企业的功能，并自 2013年的 Microsoft 项目经理。

衷心感谢以下 Microsoft 技术专家对本文的审阅：  Stefan Shackow
Stefan 是一种 Azure 应用程序服务团队的程序经理，他曾在 web 应用程序云自从其最早的产品/服务。在 Azure 中，Stefan 带领团队的项目经理，从事开发和部署 Azure 应用程序服务，以及 Microsoft 的本地/云混合产品的开发工作。