Share via

规划 SharePoint 2013 中新的应用程序模型所需的基础架构

  • Article

原文发布于 2012 年 9 月 4 日（星期二）

SharePoint 2013 带来了一个全新的应用程序模型，我们姑且称之为“应用程序模型”或“云应用程序模型”。从发展的角度看，该模型会带来整个新系列的商机，与此同时，也会带来规划和建立基础架构的需求，以便支持这些机会。在实际思考应用程序模型时，我重点关注以下三大块：

  1. 开发模型 — 主要涉及如何开发应用程序以及要利用哪些新功能等。这主要是开发人员的活动。
  2. 安全模型 — 对这些新的应用程序而言，安全模型是一些“事项”的有趣组合。您头脑里有应用主体的新概念，那就是如何为您的应用程序定义权限。OAuth 模型定义了您能获得哪些内容，以及通过描述您身份的令牌来呈现 SharePoint 的机制（与应用程序声明非常相似）。安全模型以及创建和呈现这些令牌的手段各式各样，具体情况取决于您的应用程序是承载在 SharePoint 上还是其他地方，以及您是否使用访问控制服务 (ACS) 作为信任代理等。那里涉及到很多内容，我不准备在这篇博客文章中讨论，它们主要是关乎开发人员和 IT 专业人员的活动。
  3. 基础架构 — 我们将在这里谈谈使应用程序在组织内工作的所有“粘豆包”，其中包括服务应用程序、应用程序域和前缀、DNS、SSL 和 Web 应用程序配置。这主要是 IT 专业人员活动，也是这篇博客文章的基础。本文还将侧重于比较 SharePoint 自身承载的应用程序和在另一个站点或云（像 Windows Azure）中在外部承载的应用程序。当安装 SharePoint 承载的应用程序时，系统会为它创建一个新的 SPWeb。通过这种方式，每个应用程序获得它自己的数据集，并且不能为另一个应用程序重写数据。另外，它还提供一个安全层，使得对一个应用程序拥有权利的人不能拥有恶意代码，从而防止利用当前用户的权限来访问位于服务器场中另一个网站的数据。这是基于新的应用程序模型的应用程序的一个重要基本原则，请记住，当在 SharePoint 中承载时，一个应用程序等于一个 SPWeb。

现在，让我们开始着手处理这些不同基础架构组件的列表。首先，您需要确保拥有在服务器场中创建并运行的应用程序管理服务应用程序和订阅设置服务应用程序的一个实例。应用程序管理服务用于跟踪应用程序和部署以及授权等事务。订阅设置服务也是用于多租户部署的服务应用程序，而应用程序模型还用它来创建供应用程序使用的唯一 Url。

那么，这些 Url 是如何创建的？它始于您在管理中心所做的应用程序配置。当进入管理中心后，您会发现一个新的称为“应用程序”的部分。如果单击它，您会看到一个选项“配置应用程序 Url”。在那里，您会发现用来创建应用程序 Url 的两个值，一个是应用程序域 (App Domain)，一个是应用程序前缀 (App Prefix)。应用程序域类似于将用于服务器场中所有应用程序的主机名。下面是在规划此名称时需要考虑的三个事项：

  1. 因为名称将用于整个服务器场，所以应当站在与其他 Web 应用程序相同的层次上进行规划和思考。
  2. 此外，该名称还需要一个完全限定的域名，您会发现，尝试采用 NetBIOS 样式的名称对于名称解析而言，并不是理想的方式。
  3. 最后，名称不得为您的 Web 应用程序的子域。

让我们看一个具体例子。假设您具有类似 team.contoso.com、my.contoso.com 和 portal.contoso.com 这样的 Web 应用程序。首先，您可能不会就将“contoso.com”作为应用程序域，因为如果这样做，您需要为所有指向您的应用程序终结点的 contoso.com 创建一个通配符 DNS 条目（稍后作详细解释）。另外，您也不会使用像“apps.contoso.com”这样的形式，因为这是用于您的 Web 应用程序（全都以“contoso.com”为根）的子域。因此，基于以上规则，选择像“contosoapps.com”这样的形式比较好。 

应用程序前缀值由您自己决定，它会插入到应用程序 Url 的第一部分，我们接下来会讨论这部分。

我在上面提到使用通配符 DNS 条目，下面就来谈谈这个问题。当安装一个应用程序时，如果该应用程序寄宿在 SharePoint 上，它会得到一个 Url，就像下面这样：https://apps-87e90ada14c175.contosoapps.com/myapp/pages/default.aspx。Url 的元素分为以下部分：

  • “apps” – 这是我在上面提到的您在管理中心输入的应用程序前缀值。
  • “87e90ada14c175” – 这是基于其中安装了应用程序的网站集和 Web 的唯一值
  • “contosoapps.com” – 这是您在管理中心输入的应用程序域。
  • “myapp” – 这是已安装应用程序的名称。Url 的其余部分 Pages/default.aspx 是其中安装了应用程序的 SPWeb 中包含的内容。

当您查看 Url 以及其形成过程时，希望您能理解为什么要使用通配符 DNS 条目。因为对于所安装的每个单独的应用程序实例，即便同一个应用程序安装在多个网站集中，Url 的第一部分也会有所不同，原因是无法持续为每个单独的实例更新您的 DNS。所以，也就是说，对于我在这里描述的方案中的 DNS，要用一个通配符 DNS 条目代表 *.contosoapps.com。现在，它所指向的 IP 地址就是我们打算多说几句的东西。

与通配符 DNS 条目相关的是通配符 SSL 条目。正因如此，我们十分清楚这一点：如果您在使用应用程序，您应在使用 SSL。应用程序模型涉及层层传递 OAuth 访问令牌，访问令牌描述当前用户是谁，是什么应用程序。就像您要为某个用户传递 SAML 令牌，您想加密这些令牌经过的通道，以防任何形式的重放攻击，即防止向可能正在那里监听您的网络流量的人授予访问内容的权限。使用 SSL 可防止发生这些情况，因为您已经知道，对于每个安装的实例，这些应用程序的 Url 将会不同，这也意味着为了方便管理，您需要有通配符 SSL 证书。另外，在我们的方案中，我们会为 *.contosoapps.com 获取一个通配符 SSL 证书。

好，至此为止，我们已经谈了所需的服务应用程序、应用程序域和应用程序前缀所需的配置、Url 如何形成以及需要的 DNS 和 SSL 条目。 现在，为了把每件事联结起来，我们需要谈谈应用程序请求如何路由。一般来讲，需要一个单独的 SharePoint Web 应用程序专门来做路由应用程序请求的事。让我们来看看这是为什么。假设您有三个 Web 应用程序，其定义如下；全都使用 SSL，因此我们为每个应用程序使用唯一的 IP 地址：

  • team.contoso.com – 192.168.1.10
  • my.contoso.com – 192.168.1.11
  • portal.contoso.com – 192.168.1.12

现在，如上所述，只能有一个应用程序域在服务器场，而且不应是子域。这将带给上面的应用程序两个非常现实的问题：

  • 如果我们在每个 Web 应用程序中安装应用程序，那么我们如何将正确的应用程序请求路由到正确的 Web 应用程序？我们只有一个应用程序域，但有三个 Web 应用程序。
  • 如果我们尝试将一个应用程序请求路由到现有 Web 应用程序之一，则 SSL 会断开。为什么？因为自从我们对我们的所有 Web 应用程序（因为我们在使用应用程序）使用 SSL 后，它们全都拥有像 *.contoso.com 这样的 SSL 证书。所以，我们无论如何不能将应用程序请求路由到它们，因为您无法获得同时在 *.contoso.com 和 *.contosoapps.com 上都有效的 SSL 通配符，而我们的应用程序正准备使用它呢。

那么，解决方案就是创建第四个 Web 应用程序。您可以不加主机标头名称来创建它，并给它分配共享的 IP 192.168.1.13。于是，在 DNS 中，您的 *.contosoapps.com 的通配符条目将指向 192.168.1.13。最终的结果就是您的应用程序 Web 应用程序“监听”该 IP 地址，负责路由的 SharePoint http 模块将拾取对应用程序的请求。然后，它将使用应用程序管理服务应用程序来确定是哪个 Web 应用程序在实际承载该应用程序，并重新将请求路由到它。请求随后经过该 Web 应用程序、网站集以及应用程序本身所在的 SPWeb ，这样一来，它们的所有安全性和身份验证设置都将得到正确的应用。

现在，我们的服务器场配置看起来像如下这样：

  •  应用程序配置
    • 应用程序域 – contosoapps.com
    • 应用程序前缀 – apps
  • Web 应用程序

    • team.contoso.com

      • IP 地址：192.168.1.10
      • SSL 证书：*.contoso.com

    • my.contoso.com

      • IP 地址：192.168.1.11
      • SSL 证书：*.contoso.com

    • portal.contoso.com

      • IP 地址：192.168.1.12
      • SSL 证书：*.contoso.com

    • 无主机标头，或者可以使用像 contosoapps 等这种形式。这其实都没关系，因为我们不会基于主机标头进行路由，我们会基于 IP 地址路由。不过，如果您正在使用主机头，并且所有 Web 应用程序都使用相同的 IP 地址，则此侦听器 Web 应用程序一定不能有任何主机标头值！ 否则，IIS 不会拾取任何 Web 应用程序的应用程序请求。

      • IP 地址：192.168.1.13
      • SSL 证书：*.contosoapps.com
  • DNS
    • team.contoso.com – 192.168.1.10
    • my.contoso.com – 192.168.1.11
    • portal.contoso.com – 192.168.1.12
    • *.contosoapps.com – 192.168.1.13

至此，我们已探讨了应用程序的基础架构配置的各个方面，而您在规划推出 SharePoint 2013 新的应用程序时，还需要牢记其他一些注意事项：

  • SharePoint 应用程序在使用 SAML 的 Web 应用程序上无法工作。如果您使用 SAML 身份验证，则您将无法在那些 Web 应用程序上使用 SharePoint 应用程序。这个问题有望在未来的 Service Pack 或某些其他类型的修补程序中得到解决，但目前此问题仍属 SharePoint 2013 RTM 的功能限制。
  • SharePoint 应用程序不支持多个区域（即 AAM）；所有请求均在默认区域外加以处理。如果您使用 AAM 来支持多个区域，则您很可能无法使用 SharePoint 应用程序。所有应用程序均在默认区域外加以处理，因此理论上讲，如果您将默认区域公开，让所有人皆可进入，并且您在每个区域上使用完全相同的身份验证机制（可能存在一定限制，不过可能过于锁碎，此处暂不细说），则应用程序或许可以正常运行。但再次提醒您，如果您使用区域，那通常是因为您 a) 不希望对所有人开放终结点 b) 不想使用不同的身份验证方法。再强调一次，这种情况将来可能会发生变化，但目前 SharePoint 2013 RTM 只提供这样的使用条件。

 

另外一个重点，也是最后一个注意事项，看起来就像是一大堆的配置作业，而事实上就是如此。不过，应该记住，如果您正在使用 Office 365，那么所有这些都会为您处理到位，不用慌、不必乱，只需轻松安装并使用应用程序。在衡量选择时，应对这个优点多加考量。

您现在已经了解，SharePoint 应用程序是 SharePoint 2013 的一大环节，但使用这些应用程序时需事先进行规划和设计，以确保基础架构已就绪可支持应用程序。

 

这是一篇本地化的博客文章。请访问 Planning the Infrastructure Required for the new App Model in SharePoint 2013 以查看原文