SharePoint Server 设计示例：企业门户和 Extranet 网站

 

**上一次修改主题：**2017-08-21

**摘要：**介绍了最常见的 SharePoint 2013 和 SharePoint Server 2016 设计示例的逻辑体系结构设计选项。

本文讨论一些可用作 SharePoint 网站的起点体系结构的设计示例。本文中介绍的设计示例演示公司或组织中部署的最常见类型的 SharePoint 网站的标准体系结构。

本文内容：

• 关于设计示例

• 设计示例中包括的网站

• 总体设计目标

• 服务器场

• 用户、区域和身份验证

• 服务

• 管理网站

• 应用程序池

• Web 应用程序

• 网站集

• 内容数据库

• 区域和 URL

• 区域策略

关于设计示例

本文介绍以下设计示例：

• 包含基于路径的网站的企业门户

• 包含主机命名网站的企业门户

• 包含身份验证专用区的 Extranet

设计示例阐明了名为 Fabrikam Inc. 的虚拟公司的网站。设计示例几乎应用了所有逻辑体系结构组件并阐明了如何将这些组件纳入总体设计中。本文介绍示例的设计目标并解释示例中所示的逻辑体系结构组件如何实现这些目标。

企业门户设计示例 - 两个版本

SharePoint Server 中以主机命名的网站集提供了单个 Web 应用程序中网站的 URL 管理和可伸缩性。企业门户设计示例的两个版本显示了基于传统基于路径的网站集或以主机命名的网站集使用的实现。这两种设计示例均对单个区域使用基于声明的身份验证。下文中将更加详细地讨论这些示例。

我们建议使用基于以主机命名的网站集的设计，除非要求表明对基于路径的网站集使用备用访问映射是必需的（请参阅SharePoint Server 中以主机命名的网站集体系结构和部署了解详细信息）。建议此设计是因为这与 Office 365 环境使用的体系结构相同。因此，这是经过最为严格测试的配置。包括应用程序模型和请求管理在内的新功能针对此配置进行优化，这是未来最为可靠的配置。

采用专用身份验证区域的以太网

采用专用身份验证区域的以太网设计示例只包括合作伙伴网站。它为合作伙伴协作（其中专用区域用于每种身份验证方法）提供了备用配置。每种设计示例使用 Web 应用程序的声明模式身份验证。企业门户设计示例与以太网设计示例之间的差异是区域的配置方式。采用专用身份验证区域的以太网设计示例使用多个区域，且为每个区域配置一种身份验证方法。企业门户设计示例使用一个区域，且为不同种类的用户配置多种身份验证方法。

采用专用身份验证区域的以太网设计示例还介绍了针对远程员工访问的新建议 — 使用 Windows Server 2012直接访问。此建议的备选方案是创建虚拟专用网 (VPN)。如果需要，您还可以在防火墙或网关产品上使用基于表单的身份验证以收集和转发凭据。

设计示例中如何实施网站集

尽管企业门户设计示例的早期版本使用基于路径的网站集，但是建议未来向以主机命名的网站集发展，除非要求表明使用备用访问映射 (AAM) 的传统基于路径的网站是必需的。在设计示例中通过以下方式反映了这一点：

• 使用基于路径的网站集的企业门户 — 本示例以传统方法（将网站组织到专用 Web 应用程序且每个 Web 应用程序一个首要网站集）阐明了基于路径的网站集。如果您希望多个 Web 应用程序通过单个应用程序池来增强安全性，请使用此方法。

• 使用以主机命名的网站集的企业门户 — 本示例阐明了以主机命名的网站集的使用（所有网站均在服务器场上的单个 Web 应用程序中部署）。此方法可扩展性高且使您能够更灵活地管理 URL。

• 采用专用身份验证区域的以太网 — 本示例通过将以主机命名的网站用于每个项目网站（而非组织首要网站集下的项目网站）阐明了许多具有虚拟 URL 的顶级项目网站。以此方式使用以主机命名的网站集的一个优点是在域 URL 之间创建进一步隔离，这可能是合作伙伴协作解决方案中所需的。但是，此方法的权衡是管理更多主机名（包括管理 SSL 证书）的附加成本。此外，如果使用了 SAML 身份验证，则需要其他配置（请参阅下文中的“对以主机命名的网站使用 SAML 身份验证”）。

SharePoint Server 的基于声明的身份验证

身份验证在 SharePoint Server 中的工作方式可能会影响与这些设计示例所代表的实施选项相关的设计决策。下面是一些示例：

• 在 SharePoint Server 中，基于声明的身份验证是默认模式，且是通过管理中心提供的唯一选项。经典模式身份验证可以通过使用 PowerShell 来实现。

• 在 SharePoint Server 中，您不一定非要在负载平衡器上配置服务器关联性以使用 SAML 声明身份验证。SharePoint Server 完全支持无关联负载平衡。

在 SharePoint Server 中，搜索爬网帐户需要使用集成 Windows 身份验证（NTLM 或 Kerberos）访问默认区域中的内容。因为声明身份验证允许一个区域中存在多种类型的身份验证，所以此要求不应影响其他身份验证要求。

设计示例功能摘要

下表总结了本文中讨论的三个设计示例。

表：设计示例摘要

设计示例	包括	关键设计元素
使用基于路径的网站的企业门户	组织中部署的最常见类型的网站。	基于路径的网站集 基于声明的身份验证 单个区域中实施的多个验证提供程序和验证类型
使用以主机命名的网站的企业门户	组织中部署的最常见类型的网站。	以主机命名的网站集 基于声明的身份验证 单个区域中实施的多个验证提供程序和验证类型
采用专用身份验证区域的以太网	仅合作伙伴网站。为合作伙伴协作提供了备用配置。	以主机命名的网站集 基于声明的身份验证 每种身份验证方法的不同区域

设计示例中包括的网站

本节介绍设计示例中包括的首要网站。

Intranet 网站

企业门户包括可供 Intranet 使用的下列网站：

• 发布的 Intranet 内容（例如 HRweb）

• 协作工作组网站

• My Sites

这些合起来是员工将每天使用的内容和协作网站。这些应用程序中的每一个都分别表示一种不同类型的内容。每种类型的内容都具有以下属性：

• 强调 SharePoint Server 的不同功能。

• 是具有不同数据特征的数据的宿主。

• 受不同的应用配置文件约束。

• 需要不同的权限管理策略。

因此，其中每个应用程序的设计选择都适用于优化每个应用程序的性能和安全性。

服务应用程序的设计将这三个应用程序结合在一起来提供下列功能：

• 企业范围的搜索

• 共享配置文件数据和企业元数据

下图（来自使用基于路径的网站集的企业门户设计示例）显示了构成企业 Intranet 的三种类型的网站。

构成企业 Intranet 的网站类型

合作伙伴 Web 应用程序

合作伙伴 Web 应用程序承载外部可用的网站以便与合作伙伴公司和各个合作伙伴进行安全协作。此应用程序用于供员工轻松创建可进行安全协作的网站。合作伙伴无法访问服务器场承载的其他类型的内容。区域和服务应用程序的设计实现了此目标。此外，各个网站所有者可管理其网站的权限，从而只邀请所需参与者进行协作。

在以太网设计示例中，这是唯一类型的代表网站。

总体设计目标

设计示例提供了 SharePoint Server 功能在几种常用类型的网站中的实际实施。本文将讨论各个应用程序的设计实施。下面是设计示例的关键设计目标：

• 创建框架来设计可增长的环境。

  各种类型的网站的设计决策不会阻止添加其他类型的站点。例如，初始部署可能只包括协作工作组网站或只包括构成 Intranet 的三种类型的站点（工作组网站、“我的网站”和发布的 Intranet 内容）。如果使用类似的逻辑体系结构设计，可以向解决方案中添加站点而不会影响初始解决方案的设计。换句话说，设计不会纳入限制环境使用的设计选择。

• 为多个用户组提供访问权限而不会损害不同类型的网站中的内容的安全性。

  来自使用不同验证提供程序的不同网络区域（内部的和外部的）的用户可以参与协作。另外，用户只能访问适合他们访问的内容。如果遵循类似的逻辑体系结构设计，您可为位于多个位置和具有不同目标的用户提供访问权限。例如，您的初始设计可能仅适用于内部员工访问。但是，如果使用类似的设计，您还可以使远程员工、合作伙伴员工、合作伙伴公司和客户能够进行访问。

• 确保设计可用于 Extranet 环境。

  做出谨慎的设计选择来确保解决方案可安全部署在外围网络中。

本文的其余部分将讨论设计示例中出现的各个逻辑组件（从上到下）并讨论应用于设计示例的设计选择。此方法的目的是演示可基于应用程序配置逻辑体系结构组件的不同方法。

服务器场

本节介绍设计示例中所示的服务器场的拓扑并讨论超出单个服务器场进行扩展。

服务器场的拓扑

设计示例中的每个服务器场由使用以下容错拓扑的六台服务器构成：

• 两个前端 Web 服务器

• 两个应用程序服务器

• 两个数据库服务器，安装并配置了 SQL Server 以支持 SQL Server 群集、镜像或 AlwaysOn。AlwaysOn 需要 SQL Server 2012。

前端服务器和应用程序服务器的概念与 SharePoint Server 2016 中的概念不同。有关详细信息，请参阅 SharePoint Server 2016 中的 MinRole 服务器角色概述

设计示例展示了 SharePoint Server 的逻辑体系结构，具体展示了以下内容：

• 跨前端 Web 服务器镜像所有网站。

• 管理中心网站安装在应用程序服务器上以防止用户直接访问。

实际上，服务器计算机的数量和服务器场的拓扑只对逻辑体系结构用来增加容量和提高性能很重要。可以独立于服务器场拓扑来设计逻辑体系结构。性能和容量规划过程可帮助您调整服务器场大小以实现性能和容量目标。有关详细信息，请参阅规划规划在 SharePoint Server 2013 的性能。

用户、区域和身份验证

声明是 SharePoint Server 中的默认模式身份验证，且每个设计示例都包含基于声明的身份验证。可以使用 Windows PowerShell 实现经典模式身份验证；不过，SharePoint Server 的某些功能在经典模式中不可用。若要详细了解包含经典模式身份验证的设计示例，请参阅设计示例：企业部署 (SharePoint Server 2010)

下表列出了企业门户设计示例和以太网设计示例所代表的两种方法的差异。

表：对比设计示例中区域配置的方法

	使用以主机命名的网站的企业门户和使用基于路径的网站的企业门户	采用专用身份验证区域的以太网
身份验证模式	Claims	Claims
区域配置	为不同种类的用户配置了多种身份验证方法的一个区域。	为每个区域配置了一种身份验证方法的多个区域。
URL	所有种类的用户为每个网站使用同一 URL。无论位于企业网络内部还是远程工作，员工均使用同一 URL。	每种用户使用不同 URL 访问网站。员工使用不同 URL，具体取决于他们是位于企业网络内部还是远程工作。
内部请求	企业网络内部发出的请求通过网关或代理服务器传送到网络外部然后再传回。这些请求使用安全套接字层 (SSL) 协议进行保护。 或者，拆分 DNS 也可用于将请求直接传送到服务器的内部接口。	企业网络内部发出的请求保持在网络内部。
用户体验	系统会提示所有用户选择用于登录的帐户类型。	身份验证方法是预先确定的。不需要用户使用登录页选择帐户类型。

以下各节将详细讨论如何使用两种不同的方法纳入身份验证。

采用专用区域的以太网设计示例

以太网设计示例阐明了三种不同种类的用户，每种分配到不同的区域。在每个 Web 应用程序中，最多可以创建五个使用以下可用区域名称之一的区域：默认、Intranet、Internet、自定义或 Extranet。搜索爬网帐户需要使用集成 Windows 身份验证（NTLM 或 Kerberos 协议）访问默认区域，设计示例中对此进行了说明。下表显示了如何在以太网设计示例中设置区域。

表：以太网设计示例指定的区域、用户和身份验证类型

区域	用户	身份验证
Intranet	内部和远程员工 搜索爬网帐户	NTLM 或 Kerberos 协议 使用直接访问或 VPN 进行连接的远程员工。
默认	单个合作伙伴	选项： 使用基于表单的身份验证的 LDAP 目录 具有内部林和集成 Windows 身份验证单向信任的面向外部的 Active Directory 域服务 (AD DS) 林 使用 SAML 身份验证的受信任标识提供程序
Extranet	合作伙伴公司	使用 SAML 身份验证的受信任的合作伙伴标识提供程序

企业门户设计示例

基于声明的身份验证允许在同一区域中使用多种类型的身份验证。两种版本的企业门户设计示例对所有身份验证类型使用默认区域。

下表显示了设计示例规定的区域、用户和身份验证类型。

表：企业门户设计示例的区域、用户和身份验证

区域	用户	提供程序和身份验证类型
默认	内部和远程员工	Active Directory 域服务 (AD DS) 或使用基于表单的身份验证或 SAML 身份验证的 LDAP 存储。
默认	单个合作伙伴	使用 SAML 身份验证的信任的标识提供程序，或使用基于表单的身份验证的 SQL Server 数据库
默认	合作伙伴公司	使用 SAML 身份验证的受信任的合作伙伴标识提供程序
默认	搜索爬网帐户	使用 Windows NTLM 身份验证的 AD DS

在设计示例中，发布的 Intranet 内容网站、工作组网站和“我的网站”只可供员工访问，而不管他们在网络内部还是外部。设计示例只对这些网站中的每个网站实施了一个可同时在内部和外部使用的 URL（使用 SSL）。使用了 AD DS 帐户。如果需要，基于表单的身份验证或 SAML 可以使用 LDAP，这需要其他配置。

在设计示例中，合作伙伴 Web 应用程序表示合作伙伴员工和合作伙伴公司可访问的 Extranet 网站。此方案中基于声明的身份验证需要使用一种或多种外部标识提供程序配置信任。您可使用以下任一方法：

• 您可以将 SharePoint 场配置为信任外部标识提供程序，例如位于合作伙伴公司中的提供程序（以直接针对合作伙伴目录进行验证）。

• 您可以在企业环境中将标识提供程序配置为信任外部标识提供程序。两个组织中的管理员必须明确建立此关系。在此方案中，SharePoint 场信任自己的企业环境中的标识提供程序。当标识提供程序发送令牌时，该场会使用建立信任关系时指定的令牌签名证书以确认令牌的有效性。建议使用此方法。

基于表单的身份验证是实施基于声明的环境以验证合作伙伴的替代方法。您可使用单独的存储（例如数据库）来管理这些帐户。

区域

在设计区域时，有几个关键决策关系到部署的成败。这些决策包括对以下区域的设计和配置决策：

• 默认区域

• 用于外部访问的区域

下面几节将介绍纳入设计示例中的决策。

默认区域的配置要求

最需要充分考虑的区域是默认区域。SharePoint Server 对默认区域的配置方式有以下要求：

• 当用户请求无法与区域关联时，就会应用默认区域的身份验证和策略。因此，默认区域必须是最安全的区域。

• 管理电子邮件包括默认区域中的链接。其中包括发给接近配额限制的网站所有者的邮件。因此，凡是收到这些类型的邮件和通知的用户都必须能够通过默认区域访问链接。这一点对于网站所有者来说尤为重要。

在 SharePoint Server 中，以主机命名的网站集可从任何区域进行访问。

为 Extranet 环境配置区域

在 Extranet 环境中，区域设计因以下两个原因而非常重要：

• 多个不同网络可以发出用户请求。在设计示例中，用户从内部网络、Internet 和合作伙伴公司发出请求。

• 用户使用多个 Web 应用程序中的内容。在设计示例中，Intranet 包括三个 Web 应用程序。另外，内部和远程员工可以在合作伙伴 Web 应用程序中提供和管理内容。

如果 Extranet 环境包括多个区域，请确保遵循以下设计原则：

• 配置跨多个 Web 应用程序的区域，以使各区域间互为镜像。身份验证配置和目标用户应相同。但是，与区域关联的策略在 Web 应用程序之间可以不同。例如，确保 Intranet 区域在所有 Web 应用程序中都用于相同员工。换句话说，不要既在一个 Web 应用程序中为内部员工配置 Intranet 区域，又在另一个 Web 应用程序中为远程员工配置 Intranet 区域。

• 如果使用基于路径的网站集，请为每个区域和每个资源准确配置相应备用访问映射。在您创建区域时，将自动创建备用访问映射。不过，可以将 SharePoint Server 配置为对外部资源（例如文件共享）中的内容进行爬网。必须使用备用访问映射为每个区域手动创建指向这些外部资源的链接。

• 如果使用以主机命名的网站集，请确保使用 PowerShell 将 URL 映射到适当区域

如果跨 Web 应用程序的区域没有互为镜像，并且指向外部资源的链接不适当，则会产生以下风险：

• 服务器名称、域名系统 (DNS) 名称和 IP 地址可能在内部网络之外公开。

• 用户可能无法访问网站及其他资源。

对以主机命名的网站使用 SAML 身份验证

如果设计包括对以主机命名的网站使用 SAML 身份验证，则每个虚拟 URL 都需要以下内容：

• SPTrustedIdentityTokenIssuer 上的新域

• 标识提供程序中的相应信赖方。

服务

服务体系结构因设计示例不同会有所不同。使用以主机命名的网站的企业门户设计示例包括最简单的服务体系结构。这是因为它仅使用一个 Web 应用程序，该应用程序只能适应一种服务应用程序组（又称为代理组）。

使用基于路径的网站的企业门户示例为合作伙伴网站使用分区服务以隔离项目之间的数据。此设计示例包含两个服务组，一个是 Intranet 网站的，一个是合作伙伴协作网站的。为合作伙伴网站部署了 Managed Metadata 和 Search 的不同实例，且对这些服务进行了分区。分区服务需要 Subscription Settings Service，后者只能使用 PowerShell 进行部署。

使用基于路径的网站的企业门户的服务体系结构

部署分区服务会增加体系结构的复杂性且会使以后将网站迁移到 Office 365 更加困难。对于合作伙伴网站更为简单的方法是部署 Managed Metadata Service 和 Search Service 的专用但未分区实例（如果它们需要是独立的）。许多组织依赖于 Search 的安全修整功能，而不是部署 Search Service 的专用实例。

Extranet 设计示例只包括一个代理组，但它同样为 Managed Metadata 和 Search Service 应用程序使用分区服务。

部署服务应用程序的主要设计决策是如何广泛地扩展组织分类。要简化服务体系结构，可跨所有 Web 应用程序共享托管元数据、用户配置文件和搜索并依赖安全修整来管理对内容的访问。在使用基于路径的网站的企业门户设计示例中，跨所有网站共享 Managed Metadata Service 的一个实例。不过，所有用户均可使用此配置访问企业分类。解决方案架构师必须决定是否实施 Managed Metadata Service 的多个实例。他们还将需要决定如何广泛共享用户配置文件数据。

在使用基于路径的网站集的企业门户示例中，合作伙伴 Web 配置为通过使用自定义服务组来使用专用 Search 和 Managed Metadata Service 应用程序。其他服务应用程序添加到自定义组且与默认组共享。设计示例未包括 User Profile Service 应用程序以阻止合作伙伴用户浏览组织中的人员数据。

在以主机命名的网站集的企业门户（一个服务组）的简化体系结构中，合作伙伴可以访问整个企业分类并可以浏览组织中的人员数据。不过，搜索将结果限制为合作伙伴可以访问的网站和内容。

如果您的合作伙伴网站需要隔离各项目的内容，则部署专用服务应用程序是一个好的选择，如本文中所示。这会增加服务体系结构的复杂性，但可确保合作伙伴无法访问与 Intranet 内容关联的元数据或合作伙伴网站中的其他项目。以太网设计示例同样使用分区服务。

管理网站

在设计示例中，应用程序服务器承载每个服务器场的 SharePoint 管理中心网站。这可保护网站免遭用户直接接触。如果性能瓶颈或安全性损害影响了前端 Web 服务器的可用性，SharePoint 管理中心网站仍将可用。

设计示例和本文没有提到管理网站的负载平衡 URL。建议包括以下内容：

• 如果管理 URL 使用了端口号，请使用非标准端口。默认情况下，URL 包括端口号。虽然面向客户的 URL 通常不包括端口号，但对管理网站使用端口号可通过将对这些网站的访问限制为非标准端口来提高安全性。

• 为管理网站创建单独的 DNS 条目。

除了这些建议以外，您还可以选择跨多个应用程序服务器对 SharePoint 管理中心网站进行负载平衡以实现冗余。

应用程序池

通常实施单独的 Internet Information Services (IIS) 应用程序池来实现内容之间的进程隔离。应用程序池提供了一种使多个网站可以在同一台服务器计算机上运行、但同时仍拥有自己的工作进程和标识的方法。这有助于防止向一个网站中注入代码的攻击者影响其他服务器或其他网站上的网站。

如果单个应用程序池和 Web 应用程序与以主机命名的网站集一起使用，则会在域 URL 之间提供隔离，但仅在脚本级别。

如果选择实施多个应用程序池，请为以下每个方案考虑专用应用程序池：

• 将验证的内容与匿名内容分隔开。如果同一服务器场承载公司 Internet 网站，请将此网站置于专用 Web 应用程序和应用程序池中。

• 隔离存储后端数据系统的密码并与之交互的网站（虽然可以使用 Secure Store Service 实现此目的）。

使用以主机命名的网站的企业门户设计示例和采用专用身份验证区域的以太网设计示例均为所有内容实现了一个应用程序池和 Web 应用程序。服务应用程序和 SharePoint 管理中心网站需要不同的应用程序池。

使用基于路径的网站的企业门户设计示例通过以下方式使用不同的应用程序池实现了内容之间的进程隔离：

• 管理网站是在专用应用程序池中进行托管。这是 SharePoint Server 的要求。

• 所有服务应用程序都会部署到一个应用程序池。除非出于无法抗拒的理由将服务应用程序部署到其他应用程序池，否则建议采用上述配置。对所有服务应用程序使用一个应用程序池将优化性能并减少要管理的应用程序池数。

• Intranet 内容划分到两个不同的应用程序池中。一个应用程序池承载协作内容（“我的网站”和工作组网站）。单独的应用程序池承载发布的 Intranet 内容。此配置为更有可能在其中使用业务数据连接的发布的 Intranet 内容提供进程隔离。

• 专用应用程序池承载合作伙伴 Web 应用程序。

Web 应用程序

Web 应用程序是一个由 SharePoint Server 创建并使用的 IIS 网站。每个 Web 应用程序都由 IIS 中的一个不同网站表示。

如果您选择实现多个 Web 应用程序，请考虑以下用例：

• 将匿名内容与验证的内容分隔开

  如果同一服务器场承载公司 Internet 网站，请将此网站置于专用 Web 应用程序和应用程序池中。

• 隔离用户

  在设计示例中，专用 Web 应用程序和应用程序池承载合作伙伴网站以确保合作伙伴无权访问 Intranet 内容。

• 强制实施权限

  专用 Web 应用程序提供了在 Web 应用程序中的区域上实施策略以强制实施权限的机会。例如，可以为公司 Internet 网站创建策略，明确拒绝对一个或多个用户组的写入访问。不管 Web 应用程序中各个网站或文档上配置的权限如何，均强制实施策略。

• 优化性能

  如果将应用程序放在其中还存在其他具有类似数据特征的应用程序的 Web 应用程序中，则应用程序会获得更好的性能。例如，“我的网站”的数据特征包括大量小型网站。而工作组网站通常包含少量大型网站。通过将这两种不同类型的网站分别放置在单独的 Web 应用程序中，生成的数据库就会由具有相似特征的数据组成，从而优化了数据库性能。在设计示例中，“我的网站”和工作组网站没有独特的数据隔离要求，它们共享同一应用程序池。不过，“我的网站”和工作组网站放在单独的 Web 应用程序中以优化性能。

• 优化可管理性

  因为创建单独的 Web 应用程序会产生单独的网站和数据库，所以可以实施不同的网站限制（回收站、有效期限和大小），以及协商不同服务级别的协议。例如，如果“我的网站”内容不是贵组织中最重要的内容类型，则您可以留出更多时间来还原该内容。这允许在还原“我的网站”内容之前还原更重要的内容。在设计示例中，“我的网站”位于单独的 Web 应用程序中，与其他应用程序相比，这使管理员能够更积极地管理增长。

如果使用单个 Web 应用程序实现以主机命名的网站集，则每个首要网站都是单独的域，使您能够实现其中一些目标，例如通过实现不同的网站限制优化可管理性。

网站集

建议用于部署网站的配置使用以主机命名的网站集，并且所有网站都位于单个 Web 应用程序内。因为该配置与 Office 365 使用的体系结构相同，所以建议使用它来部署网站。因此，这是经过最严格测试的配置。包括应用程序模型和请求管理在内的新功能都针对该配置进行了优化，它是未来最可靠的配置。

虽然我们建议对大多数体系结构使用以主机命名的网站集，但如果适用于以下任意条件，您应使用传统的基于路径的网站集和备用访问映射：

• 您需要使用属于 SharePoint Server 2016 默认安装的自助式网站创建功能。

  这不适用于自定义自助式网站创建解决方案。

• Web 应用程序需要唯一通配符包含或显式包含。

  可在服务器场级别为以主机命名的网站集创建包含，且它们可用于所有以主机命名的网站。 服务器场中的所有以主机命名的网站集共享相同的包含，但不需要使用它们。相比之下，您为基于路径的网站集创建的包含仅适用于单个 Web 应用程序。

• 需要 SSL 终止，但无法配置您的 SSL 终止设备以生成必要的自定义 HTTP 标头。

  如果 SSL 终止不是必需的，您仍可以通过这些设备对以主机命名的网站集使用 SSL 桥接。

• 您计划使用不同的应用程序池来获得它们提供的额外安全性，或者使用多个代理组。

有关以主机命名的网站集的详细信息（包括与基于路径的网站集的对比），请参阅SharePoint Server 中以主机命名的网站集体系结构和部署。

网站集的设计目标

网站集将逻辑体系结构和信息体系结构结合起来。网站集的设计目标是满足 URL 设计的要求和创建内容的逻辑分区。对于每个网站集，管理路径包含首要网站集的第二层。有关 URL 要求和使用管理路径的详细信息，请参阅下文的区域和 URL。网站集的第二层以外，每个网站均是一个子网站。

下图说明了工作组网站的网站层次结构。

工作组网站的网站层次结构

对于基于路径的网站集和以主机命名的网站集，信息体系结构以网站集的第二层为中心。以下部分介绍设计示例如何根据网站特性纳入选择。

发布的 Intranet 内容

对发布的 Intranet 内容 Web 应用程序的假设是公司内的多个分区将是发布的内容的宿主。在设计示例中，单独的网站集承载每个分区的内容。这具有以下优点：

• 每个分区可以独立管理内容以及管理权限。

• 每个分区可在专用数据库中存储其内容。

多个网站集的缺点包括以下内容：

• 无法跨网站集共享母版页、页面布局、模板、Web 部件和导航。

• 跨网站集协调自定义项和导航需要更多工作。

根据 Intranet 网站的信息体系结构和设计，发布的内容可以作为无缝体验显示给用户。或者，每个网站集可以显示为单独的网站。

My Sites

“我的网站”具有不同的特征，并且对“我的网站”的部署建议很简单。在设计示例中，“我的网站”网站集纳入了 URL 为 http://my 的首要网站。创建的第一个首要网站集使用“我的网站宿主”模板。纳入了管理路径（使用通配符包含），这允许无限数量的用户创建的网站。管理路径下的所有网站是使用“个人网站”模板的独立网站集。采用 http://my personal/用户名 形式将用户名追加到 URL。下图说明了“我的网站”。

“我的网站”的网站层次结构

工作组网站

您可以使用以下两种方法中的任一种在工作组网站应用程序中设计网站集：

• 允许工作组通过自助式网站创建来创建网站集。此方法的优点是工作组可以根据需要轻松创建网站，而无需管理员帮助。此方法的缺点包括以下这些：

  • 失去实施考虑周到的分类的机会。

  • 无法跨可能以其他方式共享网站集的项目或工作组共享模板和导航。

• 根据贵组织的运营方式，为贵组织创建有限数量的网站集。在此方法中，SharePoint 管理员创建网站集。在创建网站集后，工作组可以在网站集内创建网站。此方法提供了实施考虑周到的分类的机会，该分类为工作组网站的管理和增长方式提供结构。还有更多机会来在共享网站集的项目和工作组之间共享模板和导航。不过，此方法也包括一些缺点。

设计示例包含了第二种方法，这为工作组网站和发布的 Intranet 内容生成了相似的网站集层次结构。信息架构师的挑战是创建网站集的对组织有意义的第二层。下表显示了对不同类型的组织的建议。

表：建议的网站集分类

组织的类型	建议的网站集分类
产品开发	为正在开发的每个产品创建一个网站集。允许参与的工作组在网站集内创建网站。 对于每个长期开发项目，为每个参与该产品的大型工作组创建一个网站集。例如，为以下每个工作组创建一个网站集：设计者、工程师和内容开发人员。
研究	为每个长期研究项目创建一个网站集。 为每个研究项目类别创建一个网站集。
高等教育机构	为每个学院部门创建一个网站集。
国家立法部门	为每个政党创建一个网站集。党籍相同的政府官员可以共享模板和导航。 为每个委员会创建一个网站集。或者，为所有委员会创建一个网站集。
企业律师事务所	为每个企业客户创建一个网站集。
制造业	为每个产品线创建一个网站集。

合作伙伴 Web 应用程序

合作伙伴 Web 用于与外部合作伙伴就范围有限或持续时间有限的项目进行协作。按照设计，合作伙伴 Web 应用程序中的网站互不相关。合作伙伴 Web 应用程序的要求包括确保：

• 项目所有者可以轻松创建用于进行合作伙伴协作的网站。

• 合作伙伴及其他参与者只能访问他们所从事的项目。

• 网站所有者管理权限。

• 一个项目中的搜索结果没有公开其他项目中的内容。

• 管理员可以轻松地识别不再使用的网站并删除这些网站。

为满足这些要求，设计示例为每个项目纳入了一个网站集。两个企业门户设计示例均利用管理路径创建根网站集下的网站集的第二层。或者，以太网设计示例通过使用以主机命名的网站集使每个合作伙伴网站成为首要网站集。无论哪种方式，各个网站集在项目之间提供了相应级别的隔离。

如果您计划使用属于 SharePoint Server 默认安装的自助式网站创建功能（而不是为贵组织开发的自定义解决方案），请使用基于路径的网站集。以主机命名的网站集尚不能使用此功能。

内容数据库

可以使用以下两种方法将内容数据库纳入到设计中（设计示例同时包含这两种方法）：

• 根据适当的大小警告阈值确定内容数据库的目标大小。在数据库达到大小警告阈值时创建新数据库。利用此方法，可以仅根据大小目标向可用的一个或多个数据库中自动添加网站集。这是最常用的方法。

• 将网站集与特定的内容数据库关联。利用此方法可以将一个或多个网站集放置到管理员可以独立于其他数据库进行管理的专用数据库中。

如果选择将网站集与特定的内容数据库关联，则可以使用以下方法实现这一点：

• 使用 PowerShell 在特定数据库中创建网站集。

• 通过应用以下数据库容量设置，使数据库专门用于一个网站集：

  • 生成警告事件之前允许的网站数量 = 1

  • 此数据库中允许创建的最大网站数量 = 1

• 通过完成下列步骤，向专用数据库添加一组网站集：

  1. 在 Web 应用程序中，创建数据库并将数据库状态设置为“就绪”。

  2. 将所有其他数据库的状态设置为“脱机”。内容数据库脱机时，无法创建新网站集。但是，仍可访问脱机数据库中的现有网站集，以进行读取和写入操作。

  3. 创建网站集。这些网站集将自动添加到数据库中。

  4. 将所有其他数据库的状态设置回“就绪”。

发布的 Intranet 内容

对于发布的 Intranet 内容，公司门户设计示例包含单个数据库以便于管理。如果需要，根据目标大小目标添加数据库。

My Sites

对于“我的网站”，公司门户设计示例通过管理数据库使其达到最大目标大小来实现高效扩展。配置了以下设置以实现此目标：

• 网站最大存储空间为：此设置（在管理中心中的“配额模板”页上配置）限制个人网站的大小。

• 第二阶段回收站：在“Web 应用程序常规设置”页上配置的此设置确定为第二阶段回收站分配多少附加空间。

• 此数据库中允许创建的最多网站数：在创建数据库时配置此设置。通过您为前两个值指定的数字计算允许的网站总大小。然后，根据每个数据库的大小目标，确定数据库中可容纳多少个网站。

设计示例根据目标数据库大小 175 GB 和目标“我的网站”大小 1 GB 提供以下示例大小设置：

• 每个网站的网站大小限制 = 1 GB

• 数据库的目标大小 = 175 GB

• 为第二阶段回收站保留 = 15%

• 最大网站数 = 180

• 网站级别警告 = 150

在达到网站级别警告时，创建新数据库。创建新数据库后，新的“我的网站”将添加到具有最少的网站集的内容数据库。

工作组网站

预计大多数组织的工作组网站比“我的网站”大得多。工作组网站在管理路径下创建，每个工作组网站集允许一个内容数据库。设计示例根据网站集的 30 GB 的限制提供数据库设置。选择适合贵组织中的工作组网站的限制。

合作伙伴 Web

类似于“我的网站”，合作伙伴 Web 也是通过管理数据库使其达到最大目标大小来实现高效扩展。

设计示例提供了以下示例大小设置：

• 数据库的目标大小 = 200 GB

• 每个网站的存储配额 = 5 GB

• 最大网站数 = 40

• 创作网站集以专用数据库为宿主

区域和 URL

设计示例阐明如何跨企业部署中的多个网站协调 URL。以下目标影响 URL 的设计决策：

• URL 约定没有限制用户可通过其访问内容的区域。

• 可跨设计示例中的所有应用程序使用标准 HTTP 和 HTTPS 端口（80 和 443）。

• URL 中没有包括端口号。实际上，在生产环境中通常不使用端口号。

设计负载平衡的 URL

在创建 Web 应用程序时，必须选择一个负载平衡的 URL 来分配给该应用程序。所选 URL 将应用于默认区域。另外，必须为 Web 应用程序中所创建的每个区域创建一个负载平衡的 URL。负载平衡的 URL 包括协议、方案、主机名和端口（如果使用）。负载平衡的 URL 必须在所有 Web 应用程序和区域中是唯一的。因此，每个应用程序和每个应用程序中的每个区域需要设计示例中唯一的 URL。

Intranet

构成 Intranet 的三个网站集中的每一个都需要唯一的 URL。在企业门户设计示例中，Intranet 内容的目标受众是内部员工和远程员工。员工对这些网站中的每一个使用相同的 URL，而不管他们是在现场还是远程的。此方法为 SharePoint 设计添加了安全层（所有流量都是 SSL）。但是，此方法需要您为其他配置选择备用方案：

• 将内部流量连同远程流量一起通过防火墙或网关产品进行路由。

• 设置拆分 DNS 环境来解决内部网络中的内部请求。

合作伙伴网站

在设计示例中，内部员工、远程员工和合作伙伴员工访问合作伙伴网站。在企业门户设计示例中，所有用户都输入同一 URL，而不管使用的是何种身份验证方法。在以太网设计示例中，每种不同类型的用户输入不同的 URL。虽然各合作伙伴和合作伙伴公司都使用 SSL (HTTPS) 从外部访问合作伙伴网站，但每组需要不同的 URL 来应用单独区域（即不同的身份验证方法和不同的区域策略）的好处。

由于以太网设计示例为远程员工访问使用直接访问或 VPN，因此远程员工和内部员工均可使用相同 URL。如果远程员工的访问通过反向代理设备进行配置，远程员工将需要使用 SSL 的独立 URL，并需要其他区域。最后，以太网设计示例包含以主机命名的网站集而非单个首要网站集。因此，每个项目网站具有不同的 URL。

下表显示了内部员工、远程员工和合作伙伴用来访问合作伙伴网站的示例 URL，如以太网设计示例中所示。

表：Extranet 设计示例中的示例 URL

区域	示例 URL
内部和远程员工	http://project1
单个合作伙伴	https://project2.fabrikam.com
合作伙伴公司	https://TrustedPartnerProject1.fabrikam.com

对 URL 路径使用显式包含和通配符包含

通过定义管理路径，可以指定 Web 应用程序的 URL 命名空间中的哪些路径用于网站集。可以指定在根网站下的一个截然不同的路径中存在一个或多个网站集。如果没有管理路径，则在根网站集下的所有网站都属于根网站集的一部分。

可以创建以下两种类型的管理路径：

• **显式包含：**具有所分配的显式 URL 的网站集。显式包含仅应用于一个网站集。可以在根网站集下创建许多显式包含。例如，http://intranet/hr 就是用此方法创建的网站集的 URL。这会影响所添加的每个显式路径的性能，因此建议将使用显式包含创建的网站集的数量限制为大约 20 个。

• **通配符包含：**添加到 URL 中的路径。此路径表示在路径名后直接指定的所有网站都是唯一网站集。此选项通常用于支持自助式创建的网站集，例如“我的网站”。例如，http://my/personal/user1 就是用此方法创建的网站集的 URL。

实现了以主机命名的网站集的托管路径时，如果解决方案中包括多个 Web 应用程序，则这些托管路径在服务器场级别创建且路径应用于所有 Web 应用程序。实现了基于路径的网站的托管路径时，这些托管路径仅应用于在其中创建它们的 Web 应用程序。

设计示例包含这两种类型的托管路径（显式包含和通配符包含，如以下各节中所述。）

显式包含：发布的 Intranet 内容

在设计示例中，发布的 Intranet 网站集包含每个子网站（例如人力资源、设施和采购）的显式包含。如果需要，这些网站集中的每一个都可以与不同的内容数据库关联。除非使用了以主机命名的网站集，否则，此示例中显式包含的使用假定 Web 应用程序中没有创建任何其他类型的网站，包括通配符包含。

使用显式包含生成了以下 URL：

• https://intranet.fabrikam.com

• https://intranet.fabrikam.com/hr

• https://intranet.fabrikam.com/facilities

• https://intranet.fabrikam.com/purchasing

在此示例中，根网站集 http://intranet.fabrikam.com 表示 Intranet 的默认主页。此网站适合作为用户内容的宿主。

通配符包含：工作组网站、“我的网站”和合作伙伴 Web

工作组网站、“我的网站”和合作伙伴 Web 应用程序使用了通配符包含。通配符包含适用于允许用户创建自己的网站集的应用程序和包含大量网站集的 Web 应用程序。通配符包含指示通配符后面的下一项是网站集的根网站。

工作组网站

在工作组网站应用程序中，通配符包含用于每个工作组网站集。好的管理实践建议您将首要工作组网站的数量保持在可管理的数量之内。另外，工作组网站的分类对业务的运营方式来说应该是合理的。

使用通配符包含生成了以下 URL：

• https://teams.fabrikam.com/sites/Team1

• https://teams.fabrikam.com/sites/Team2

• https://teams.fabrikam.com/sites/Team3

在此示例中，根网站集 https://teams.fabrikam.com 未必是用户内容的宿主。

My Sites

“我的网站”提供了自助式网站创建。在浏览 Intranet 的用户首次单击“我的网站”时，将自动为该用户创建“我的网站”。在设计示例中，“我的网站”包括名为 /personal (http://my/personal) 的通配符包含。“我的网站”功能将自动将用户名追加到 URL。

这会生成以下格式的 URL：

• https://my.fabrikam.com/personal/User1

• https://my.fabrikam.com/personal/User2

• https://my.fabrikam.com/personal/User3

合作伙伴 Web

如果使用了基于路径的网站集，则可实现自助式网站创建功能以允许员工创建安全网站以与外部合作伙伴进行协作。如果使用了以主机命名的网站集，则可实现自定义自助式网站创建功能或者管理员可以根据请求创建合作伙伴项目网站。

在企业门户设计示例中，合作伙伴 Web 应用程序包括名为 /sites (http://partnerweb/sites) 的通配符包含。这会生成以下格式的 URL：

• https://partnerweb.fabrikam.com/sites/Project1

• https://partnerweb.fabrikam.com/sites/Project2

• https://partnerweb.fabrikam.com/sites/Project3

将 URL 与 AAM 和 DNS 进行协调

如果实现了基于路径的网站集，请为服务器场中的每个网站 URL 配置备用访问映射 (AAM)。这将确保 Web 请求映射到正确的网站，尤其是在使用负载平衡或反向代理技术的环境中。

可配置单一名称 URL（如 http://teams）以进行 Intranet 访问。客户端通过以下方法解析这些 URL：附加客户端计算机的 DNS 后缀（如 fabrikam.com），然后发出对具有该后缀的名称的 DNS 查找。例如，当 fabrikam.com 域中的客户端计算机请求 http://teams 时，该计算机会向 DNS 发送对 http://teams.fabrikam.com 的请求。

DNS 必须配置为对每个完全限定的域名 (FQDN) 使用一条 A 记录（或者对于 IPv6，则为 AAAA 记录）。该记录指向承载某个网站的 Web 服务器的负载平衡 IP 地址。在典型的生产部署中，服务器配置为使用静态分配的 IP 地址以及 DNS 中静态分配的 A 或 AAAA 记录。

在收到负载平衡的 IP 地址后，客户端浏览器将连接到服务器场中的前端 Web 服务器，然后发送具有原始单一名称 URL (http://teams) 的 HTTP 请求。根据备用访问映射中配置的设置，IIS 和 SharePoint Server 将此识别为 Intranet 区域的请求。如果用户改为请求 https://teams.fabrikam.com，则过程类似，但 IIS 和 SharePoint Server 将收到此 FQDN，从而会识别对默认区域的请求。

在包含多个域的环境中，在未包含网站的域中输入 DNS 的 CNAME 记录。例如，如果 Fabrikam 网络环境包含另一个名为 europe.fabrikam.com 的域，则在 Europe 域中输入这些网站的 CNAME 记录。对于工作组网站 Intranet 网站 (http://teams)，会将 CNAME 记录指定的工作组添加到指向 teams.fabrikam.com 的 europe.fabrikam.com 域。之后，在将客户端计算机的 DNS 后缀追加到 DNS 查找请求时，对 Europe 域中的 http://teams 的请求将发出对 teams.europe.fabrikam.com 的 DNS 查找，并将由 CNAME 记录定向到 teams.fabrikam.com。

区域策略

可以为一个或多个区域配置策略以强制为 Web 应用程序中的所有内容实施权限。在声明模式中，只能为指定区域（通常并非为 Web 应用程序）定义策略。策略可对用户在区域中访问的所有内容强制实施权限。策略权限将覆盖为网站和内容配置的其他所有安全设置。您可以基于用户或用户组而不是 SharePoint 组配置策略。如果添加或更改区域策略，搜索必须再次对网站进行爬网以应用新权限。

设计示例并未使用策略，因为对单个区域启用了多种类型的身份验证或者所有网站将包含在一个 Web 应用程序中（或者这两个原因）。