设计示例：企业部署 (SharePoint Server 2010)
适用于： SharePoint Foundation 2010, SharePoint Server 2010
上一次修改主题： 2017-01-18
本文介绍逻辑体系结构组件的实际实施以实现可使用的设计。本文用于与以下设计示例一起使用：
设计示例：使用经典身份验证的企业门户
设计示例：使用基于声明的身份验证的企业门户
若要下载这些模型中的任一个，请参阅 SharePoint Server 2010 设计示例：使用经典身份验证或使用基于声明的身份验证的企业门户（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196872&clcid=0x804)（该链接可能指向英文页面）。
本文内容：
关于设计示例
总体设计目标
服务器场
用户、区域和身份验证
服务
创作和发布替代方法
管理网站
应用程序池
Web 应用程序
网站集
内容数据库
区域和 URL
区域策略
设计示例阐明了 Microsoft SharePoint Server 2010 的常规企业部署。设计示例几乎应用了所有逻辑体系结构组件并阐明了如何将这些组件纳入总体设计中。两个示例阐明了相同的服务和网站，但包含了不同的身份验证方法，如下所示：
经典身份验证：此设计示例表示网站从 Microsoft Office SharePoint Server 2007 到 Microsoft SharePoint Server 2010 的升级途径。此示例纳入了经典身份验证，其中将会使用 Windows 身份验证方法来访问网站。还将使用每种身份验证方法的不同区域。在对 SharePoint 网站使用 Windows 身份验证时，可以将防火墙或网关产品配置为使用表单身份验证来收集转发给 SharePoint Server 2010 的 Windows 凭据。合作伙伴员工帐户将添加到企业目录中。
声明身份验证：此设计示例纳入了新的声明身份验证模型。在单个区域中实施了多个验证提供程序和验证类型。声明身份验证支持基于表单的身份验证、基于 SAML 令牌的身份验证和 Windows 身份验证。此设计示例使用基于 SAML 令牌的身份验证添加合作伙伴公司以直接针对合作伙伴目录进行验证。有几种适用于合作伙伴员工帐户的提供程序选项。
使用最能表示您的身份验证要求的设计示例。
本文介绍示例的设计目标并解释如何使用示例中所示的逻辑体系结构组件来实现这些目标。
关于设计示例
设计示例阐明了虚构的名为 Fabrikam, Inc. 的公司的企业部署。部署包括两个服务器场。一个服务器场是公司 Intranet 和合作伙伴网站的宿主，另一个服务器场是公司网站 (www.fabrikam.com) 的宿主。本节的其余部分介绍这些首要网站。
Intranet
企业 Intranet 包括以下网站：
发布的 Intranet 内容（例如 HRweb）
协作工作组网站
我的网站
这些合起来是员工将每天使用的内容和协作网站。这些应用程序中的每一个都分别表示一种不同类型的内容。每种类型的内容：
强调 SharePoint Server 2010 的不同功能。
是具有不同数据特征的数据的宿主。
受不同的应用配置文件约束。
需要不同的权限管理策略。
因此，其中每个应用程序的设计选择都适用于优化每个应用程序的性能和安全性。
服务应用程序的设计将这三个应用程序结合在一起来提供：
跨应用程序导航
企业范围的搜索
共享配置文件数据和企业元数据
下图说明了构成企业 Intranet 的三个应用程序。
.gif "Intranet 网站")
此图示中的 URL 来自经典身份验证设计示例。
合作伙伴 Web 应用程序
合作伙伴 Web 应用程序是可从外部使用的用于与合作伙伴公司和各个合作伙伴进行安全协作的网站的宿主。此应用程序用于供员工轻松创建可进行安全协作的网站。不允许合作伙伴访问以服务器场为宿主的其他类型的内容。区域和服务应用程序的设计实现了此目标。
在设计示例中，合作伙伴 Web 应用程序的宿主与 Intranet 内容的宿主是相同的服务器场。
公司 Internet 网站
公司 Internet 网站是公司的 Internet 展示。通过配置具有只读权限的匿名访问，使内容可供客户使用。对此应用程序的设计选择起促进作用的关键因素包括：
**内容隔离：**客户无法访问以服务器场为宿主的任何其他类型的内容。
**目标管理：**为通过执行管理和创作任务来管理网站的员工提供已验证的访问。
**安全内容创作和发布：**单独的网站集以合作伙伴 Web 应用程序中的服务器场 A 为宿主进行创作。这样，可以与内部和远程员工以及与专门从事网站开发或内容创作的编辑合作伙伴进行安全协作和内容开发。内容发布配置为自动将内容从第一个服务器场中的创作网站集发布到第二个服务器场中的生产网站集。下图说明了发布过程。
.gif "已发布的网站")
总体设计目标
设计示例提供了 SharePoint Server 2010 功能在几种常用类型的应用程序中的实际实施。本文将讨论各个应用程序的设计实施。设计示例的关键设计目标包括：
使用最少数量的服务器场作为公司通常需要的最常用类型的网站（即 Intranet、Extranet 和 Internet 网站）的宿主。
创建框架来设计可增长的环境。各个应用程序的设计决策不会阻止添加其他应用程序。例如，初始部署可能只包括协作工作组网站或只包括构成 Intranet 的三个应用程序（工作组网站、“我的网站”和发布的 Intranet 内容）。通过使用类似的逻辑体系结构设计，可以向解决方案中添加应用程序而不会影响初始应用程序的设计。换句话说，设计不会纳入限制环境使用的设计选择。
为多个用户组提供访问权限而不会损害不同类型的网站中的内容的安全性。来自具有不同验证提供程序的不同网络区域（内部的和外部的）的用户可以参与协作。另外，用户只能访问适合他们访问的内容。通过遵循类似的逻辑体系结构设计，您可创造为位于多个位置和具有不同目标的用户提供访问权限的机会。例如，您的初始设计可能仅适用于内部员工访问。但通过类似的设计，您可创造使远程员工、合作伙伴员工、合作伙伴公司和客户也可访问的机会。
确保设计可用于 Extranet 环境。做出谨慎的设计选择来确保服务器场可安全部署在外围网络中。
本文的其余部分将讨论设计示例中出现的各个逻辑组件（从上到下）并讨论应用于设计示例的设计选择。此方法的目的是演示可基于应用程序配置逻辑体系结构组件的不同方法。
服务器场
设计示例使用了两个服务器场。本节介绍影响企业环境中所需服务器场数量的许可要求，并指出设计示例中所示的服务器场的拓扑。
许可要求
若要成为 Intranet 内容和 Internet 网站的宿主，最少需要两台服务器。这是满足许可要求所必需的。
以下两种服务器许可证可用于 SharePoint Server 2010：
**Microsoft SharePoint Server 2010 服务器许可证：**这是适用于协作 Intranet 内容的许可证。此许可证需要使用客户端访问许可证 (CAL)。如果创建用于进行合作伙伴协作的网站，则必须确保为合作伙伴员工购买了必需数量的 CAL。
**Microsoft SharePoint Server 2010 for Internet sites：**此许可证仅用于面向 Internet 的网站。此许可证不需要 CAL。如果创建用于进行合作伙伴协作的网站，您无需购买其他 CAL。不过，无法创建专门用于供您的员工使用的网站。
备注
这些许可证不能组合在同一服务器计算机上或同一服务器场中。
就许可选项而言，最重要的设计选择是决定哪个服务器场是合作伙伴 Web 应用程序的宿主。在设计示例中，第一个服务器场是 Intranet 内容的宿主，第二个服务器场是公司 Internet 网站的宿主。根据许可条款，任一服务器场都可作为合作伙伴 Web 应用程序的宿主。
在两个服务器场之间选择时，确定哪个服务器场应作为合作伙伴 Web 应用程序的宿主的一般设计指南包括：
**协作性质：**如果合作伙伴 Extranet 网站的主要目的是安全地将信息传送给许多合作伙伴，则 Internet 服务器场是最经济的选择。另一方面，如果主要目的是与少数合作伙伴员工协同工作，则 Intranet 服务器场可能是较好的选择。选择可以针对预期角色优化服务器场的选项。
**合作伙伴员工数量：**如果您与许多合作伙伴员工进行协作并且最小化成本很重要，则可以使用 Internet 网站许可证安全地使协作和匿名内容以面向 Internet 的服务器场为宿主。
在设计示例中，合作伙伴 Web 应用程序用于与合作伙伴公司进行密集协作，包括开发和暂存公司 Internet 网站。将合作伙伴 Web 应用程序置于第一个服务器场中允许组织针对预期用途（协作与只读内容）优化两个服务器场中的每一个。不过，任一服务器场都可作为合作伙伴 Web 应用程序的宿主。
设计示例包括 Microsoft Office Web Apps。Office Web Apps 需要 Microsoft Office 2010 客户端许可证。换句话说，如果您要使 Office Web Apps 可供合作伙伴使用，则您还必须为他们购买 Office 2010 客户端许可证。
服务器场的拓扑
设计示例中的每个服务器场由使用以下拓扑的五台服务器构成：
两台前端 Web 服务器
一台应用程序服务器
两台群集或镜像数据库服务器
设计示例通过显示以下内容来阐明 SharePoint Server 2010 的逻辑体系结构：
跨前端 Web 服务器镜像所有网站。
管理中心网站安装在应用程序服务器上以防止用户直接访问。
实际上，服务器计算机的数量和服务器场的拓扑对逻辑体系结构并不重要，只是用来根据需要增加容量和提高性能。可以独立于服务器场拓扑来设计逻辑体系结构。性能和容量规划过程将帮助您调整服务器场大小以实现性能和容量目标。有关详细信息，请参阅性能和容量管理 (SharePoint Server 2010)。
超出两个服务器场进行扩展
您的业务可能需要所描述的两个服务器场以外的服务器场。专用服务器场的候选网站包括以下网站：
我的网站：许多具有大量员工或学生的组织选择使“我的网站”以专用服务器场为宿主。
创作和暂存网站：如果发布的内容复杂或庞大，则通过使用 Microsoft SharePoint Server 2010 for Internet sites 许可证使这些网站以专用的包含一台服务器的服务器场为宿主，可以更好地优化创作和暂存。例如，发布包括已标记的元数据的内容增加了创作服务器场和发布的服务器场之间的服务设计示例的复杂性，包括跨服务器场共享服务以及做出有关如何可以跨多用途服务器场中的其他类型的 Web 应用程序共享服务的决策。
合作伙伴网站：安全性和隔离要求可以保证专用服务器场适用于合作伙伴协作。这在仅供内部使用的内容和与外部合作伙伴协作开发的内容之间制造了物理隔离。
用户、区域和身份验证
在 SharePoint Server 2010 中创建 Web 应用程序时，必须选择基于声明的身份验证或经典模式身份验证。身份验证模式确定 SharePoint Server 2010 在内部如何使用帐户。下表总结了这两种方法。
身份验证类型 |
描述 |
建议 |
经典模式身份验证 |
SharePoint Server 2010 将用户帐户视为传统的 Windows Active Directory 帐户。支持以下身份验证协议：Kerberos、NTLM、基本、摘要式和匿名。 不支持基于表单的身份验证。 只能对区域配置一种身份验证方法。 |
建议使用经典模式从 Microsoft Office SharePoint Server 2007 升级环境，其中不需要基于表单的身份验证。 升级并选择经典模式身份验证时，无需运行用户迁移。 |
基于声明的身份验证 |
SharePoint Server 2010 将用户帐户视为声明标识。Windows 帐户将自动转换为声明标识。此模式另外支持基于表单的身份验证和针对信任的标识提供程序的身份验证。 可以对单个区域配置多种身份验证类型。 |
建议对新的 SharePoint Server 2010 部署使用基于声明的身份验证。它对于升级需要基于表单的身份验证的 Office SharePoint Server 2007 解决方案来说是必需的。 |
本文中讨论的两个设计示例表示这两种选项。以下各节将详细讨论如何将身份验证纳入两个设计示例中。
经典模式身份验证设计示例
使用经典模式身份验证的设计示例包含了以前版本中包含的一个区域一种身份验证类型的传统方法。因此，此示例提供了从 Office SharePoint Server 2007 到 SharePoint Server 2010 的升级途径。
一条说明是经典模式不支持基于表单的身份验证。使用经典模式身份验证时，所有验证帐户必须驻留在 Active Directory 域服务 (AD DS) 中。建议远程访问网站的用户对防火墙或网关产品使用基于表单的身份验证来收集转发到 SharePoint 场的 Windows 凭据。
经典模式示例阐明了四种不同种类的用户，每种分配到不同的区域。在每个 Web 应用程序中最多可以创建五个区域，同时使用以下可用的区域名称之一：默认、Intranet、Internet、自定义或 Extranet。
下表显示了经典模式设计示例规定的区域、用户和身份验证类型。
.gif "显示区域、用户和身份验证的表。")
搜索爬网帐户至少需要访问一个使用 NTLM 身份验证的区域。如果没有将用户的任何区域配置为使用 NTLM，请将自定义区域配置为使用 NTLM 身份验证。
基于声明的身份验证设计示例
建议将基于声明的身份验证用于 SharePoint Server 2010 的所有新部署，并且是升级需要基于表单的身份验证的 Office SharePoint Server 2007 解决方案所必需的。除了提供标准 Windows 身份验证方法之外，基于声明的身份验证还允许您针对其他目录（例如 Windows Live ID、Active Directory 联合身份验证服务 2.0 或支持 SAML 令牌和 WS 联合身份验证协议的第三方身份提供程序）进行验证。
在基于声明的身份验证设计示例中，对协作服务器场使用基于声明的身份验证。基于声明的身份验证允许在同一区域中使用多种类型的身份验证。设计示例对所有身份验证类型使用默认区域。下表显示了协作服务器场示例规定的区域、用户和身份验证类型。
.gif "显示区域、用户和身份验证的表。")
在设计示例中，发布的 Intranet 内容网站、工作组网站和“我的网站”只可供员工访问，而不管他们在网络内部还是外部。设计示例只实施了一个可同时在内部和外部使用的 URL（使用 SSL）。使用了 Active Directory 帐户。如果需要，LDAP 可与基于表单的身份验证或 SAML 一起使用，这需要其他配置。
在设计示例中，合作伙伴 Web 应用程序表示合作伙伴员工和合作伙伴公司可访问的 Extranet 网站。在此方案中使用基于声明的身份验证需要使用一种或多种外部安全令牌服务 (STS) 配置信任。这可使用以下任一方法来提供：
SharePoint 场可配置为信任外部 STS，例如与 Windows Live 相关的 STS（用于验证各个合作伙伴）或驻留在合作伙伴公司中的 STS（用于直接针对合作伙伴目录进行验证）。
企业环境中的 STS 可配置为信任外部 STS。此关系必须由两个组织中的管理员明确建立。在此方案中，SharePoint 场配置为仅信任驻留在自己的企业环境中的 STS。此内部 STS 验证其从外部 STS 收到的令牌，然后颁发允许合作伙伴用户访问 SharePoint 场的令牌。这是建议的方法。
实施基于声明的环境以验证合作伙伴的替代方法是使用基于表单的身份验证并使用单独的存储（例如数据库）来管理这些帐户。
有关实施基于声明的身份验证环境的详细信息，请参阅以下白皮书：Windows 的基于声明的标识：Active Directory 联合身份验证服务 2.0、Windows CardSpace 2.0 和 Windows Identity Foundation 简介（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196776&clcid=0x804)（该链接可能指向英文页面）。
在基于声明的身份验证设计示例中，发布的服务器场设置为使用经典模式身份验证。替代方法是对发布的服务器场也使用基于声明的身份验证并为匿名用户实施单独的区域。设计的重要元素是对匿名用户使用单独的区域以在只读环境和读写环境之间创建隔离，而不管实施的是哪种身份验证模式。下表显示了为发布的服务器场阐明的区域、用户和身份验证类型。
.gif "显示区域、用户和身份验证的表。")
此外，搜索爬网帐户至少需要访问一个使用 NTLM 身份验证的区域。如果需要，可以将 NTLM 身份验证添加到声明身份验证区域。在经典模式中，如果没有将用户的任何区域配置为使用 NTLM，请将自定义区域配置为使用 NTLM 身份验证。
区域
在设计区域时，有几个关键决策关系到部署的成败。这些决策包括对以下区域的设计和配置决策：
默认区域
用于外部访问的区域
下面几节将介绍纳入设计示例中的决策。
默认区域的配置要求
最需要充分考虑的区域是默认区域。SharePoint Server 2010 对默认区域的配置方式具有以下要求：
当用户请求无法与区域关联时，就会应用默认区域的身份验证和策略。因此，默认区域必须是最安全的区域。
可以从默认区域发送含有链接的管理电子邮件。其中包括发给接近配额限制的网站所有者的电子邮件。因此，凡是收到这些类型的电子邮件和通知的用户都必须能够通过默认区域访问链接。这一点对于网站所有者来说尤为重要。
以主机命名的网站集只有通过默认区域才可用。打算访问以主机命名的网站集的用户都必须能够通过默认区域进行访问。
为 Extranet 环境配置区域
在 Extranet 环境中，区域设计因以下两个原因而非常重要：
可以从多个不同网络发出用户请求。在设计示例中，用户从内部网络、Internet 和合作伙伴公司发出请求。
用户使用多个 Web 应用程序中的内容。在设计示例中，Intranet 包括三个不同的 Web 应用程序。另外，内部和远程员工可以跨以下所有 Web 应用程序提供和管理内容：Intranet、合作伙伴 Web 和公司 Internet 网站。
在 Extranet 环境中要确保遵循以下设计原则：
配置跨多个 Web 应用程序的区域，以使各区域间互为镜像。身份验证配置和目标用户应相同。但是，与区域关联的策略在 Web 应用程序之间可以不同。例如，确保 Intranet 区域在所有 Web 应用程序中都用于相同的员工。换句话说，不要既在一个 Web 应用程序中为内部员工配置 Intranet 区域，又在另一个 Web 应用程序中为远程员工配置 Intranet 区域。
为每个区域和每个资源准确配置相应备用访问映射。在您创建区域时，将自动创建备用访问映射。不过，可以将 SharePoint Server 2010 配置为对外部资源（例如文件共享）中的内容进行爬网。必须通过使用备用访问映射为每个区域手动创建这些外部资源的链接。
如果跨 Web 应用程序的区域没有互为镜像，并且指向外部资源的链接不适当，则风险包括：
服务器名称、域名系统 (DNS) 名称和 IP 地址可能在内部网络之外公开。
用户可能无法访问网站及其他资源。
服务
所阐明的服务体系结构显示了跨以下三种不同类型的网站部署服务的最复杂的选项：Intranet、合作伙伴 Web 和公司 Internet 网站。为合作伙伴网站部署了专用的分区服务。为供创作网站集和发布的 Internet 网站独占使用部署了 Managed Metadata Service 应用程序的单独实例。
较简单的替代方法是跨网站根据需要部署一组服务应用程序并共享各服务。此体系结构依赖安全修整来仅显示用户有权访问的内容。下图说明了这种较简单的方法。
.gif "服务体系结构")
部署服务应用程序的主要设计决策是如何广泛地扩展组织分类。通过跨所有 Web 应用程序共享托管元数据、用户配置文件和搜索并依赖安全修整来管理对内容的访问，可以简化服务体系结构。在本文中所描述的简化的体系结构中，跨所有网站共享 Managed Metadata Service 的一个实例。不过，使用此配置，所有用户都有权访问企业分类。解决方案架构师必须决定是否实施 Managed Metadata Service 的多个实例。他们还将需要决定如何广泛共享用户配置文件数据。
合作伙伴网站
对于合作伙伴网站（服务器场 1 中的自定义组），设计示例规定的最少服务是搜索和托管元数据。如果将 Office Web Apps 添加到合作伙伴网站使用的服务组中，请确保您有此网站的所有用户（包括合作伙伴）的相应许可证。设计示例中未包括 User Profile Service 应用程序来阻止合作伙伴用户浏览组织中的人员数据。
在简化的体系结构中，合作伙伴有权访问整个企业分类并可以浏览组织中的人员数据。不过，搜索将结果限制为合作伙伴有权访问的网站和内容。
如果您的合作伙伴网站需要隔离各项目的内容，则部署专用的分区服务应用程序是一个好的选择，如设计示例中所示。这会增加服务体系结构的复杂性，但可确保合作伙伴无权访问与 Intranet 内容关联的元数据或合作伙伴网站中的其他项目。
公司 Internet 网站
在简化的设计体系结构中，企业 Managed Metadata Service 应用程序还与发布的 Internet 网站共享。在设计示例中，为供创作网站集和发布的服务器场独占使用在协作服务器场上部署了 Managed Metadata Service 应用程序的专用实例。
如果发布的服务器场是匿名的并且是只读的，则公开与发布的内容不相关的托管元数据没有任何风险。匿名用户只能访问发布的内容并且无法提交分级或创建其他类型的元数据。
在整个组织中共享 Managed Metadata Service 应用程序（如本文中的简化的体系结构中所示）允许作者使用企业分类。而为创作和发布部署该服务的专用实例（设计示例中所示）可确保隔离托管元数据。
Search Service 应用程序的专用实例部署到作为公司 Internet 网站的宿主的服务器场。这是发布的面向 Internet 的网站的建议配置。
创作和发布替代方法
对于公司 Internet 网站，设计示例阐明了发布过程，其中包括使用内容部署功能将内容从创作网站集移动到发布服务器场。此方法的较简单的替代方法是直接在发布服务器场中进行创作。这通常称为在生产中创作。
在生产环境中创作可通过将服务整合到一个服务器场中并消除内容部署需要来大大简化解决方案。设计示例包括可供作者用来安全工作且不会影响匿名用户的附加区域。确保阻止与作者所用区域关联的端口上的传入匿名访问。如果您的网站上的创作活动少于每小时 500 次写入，则在生产环境中创作时不太可能会影响发布的网站的性能。
SharePoint Server 2010 包括可在此方案中用来确保在准备好内容之前不会向匿名用户公开此内容的发布功能。有关详细信息，请参阅以下文章：
计划发布的网页的开始和结束日期（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196777&clcid=0x804)（该链接可能指向英文页面）
批准或拒绝待定的提交（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196778&clcid=0x804)（该链接可能指向英文页面）
设置发布权限（该链接可能指向英文页面） (https://go.microsoft.com/fwlink/?linkid=196779&clcid=0x804)（该链接可能指向英文页面）
管理网站
在设计示例中，每个服务器场的管理中心网站均以应用程序服务器为宿主。这可保护网站免遭用户直接接触。如果性能瓶颈或安全性损害影响了前端 Web 服务器的可用性，管理中心网站仍将可用。
设计示例中或本文中没有提到管理网站的负载平衡 URL。建议包括：
如果管理 URL 中使用了端口号，请使用非标准端口。默认情况下，URL 中包括端口号。虽然面向客户的 URL 中通常不使用端口号，但对管理网站使用端口号可通过将对这些网站的访问限制为非标准端口来提高安全性。
为管理网站创建单独的 DNS 条目。
除了这些建议以外，您还可以选择跨多个应用程序服务器对管理中心网站进行负载平衡以实现冗余。
应用程序池
通常实施单独的 Internet Information Services (IIS) 应用程序池来实现内容之间的进程隔离。应用程序池提供了一种使多个网站可以在同一台服务器计算机上运行、但同时仍拥有自己的工作进程和标识的方法。这减少了攻击者利用一个网站向服务器中注入代码来攻击其他网站的机会。
从实际的角度来说，为以下每个方案考虑使用专用应用程序池：
将验证的内容与匿名内容分隔开。
隔离存储外部业务应用程序的密码并与之交互的应用程序（虽然可以使用 Secure Store Service 实现此目的）。
隔离用户可以在其中非常自由地创建和管理网站以及就内容进行协作的应用程序。
设计示例采用以下方式使用应用程序池：
每个管理网站以专用应用程序池为宿主。这是 SharePoint 2010 产品的要求。
Intranet 内容划分到两个不同的应用程序池中。协作内容（“我的网站”和工作组网站）以一个应用程序池为宿主。发布的 Intranet 内容以单独的应用程序池为宿主。此配置为更有可能在其中使用业务数据连接的发布的 Intranet 内容提供进程隔离。
合作伙伴 Web 应用程序以专用应用程序池为宿主。
公司 Internet 网站以另一个服务器场中的专用应用程序池为宿主。如果此服务器场也是合作伙伴协作内容的宿主，则这两种类型的内容（Internet 和合作伙伴）将以两个不同的应用程序池为宿主。
Web 应用程序
Web 应用程序是由 SharePoint 2010 产品创建和使用的 IIS 网站。每个 Web 应用程序都由 IIS 中的一个不同的网站表示。
一般来说，专用 Web 应用程序的用途是：
**将匿名内容与验证的内容分隔开。**在设计示例中，公司 Internet 网站以专用 Web 应用程序和应用程序池为宿主。
**隔离用户。**在设计示例中，合作伙伴网站以专用 Web 应用程序和应用程序池为宿主以确保合作伙伴无权访问 Intranet 内容。
**强制实施权限。**专用 Web 应用程序通过管理中心的“Web 应用程序的策略”页提供按策略强制实施权限的机会。例如，可以在公司 Internet 网站上创建一个策略，明确拒绝对一个或多个用户组的写入访问。不管 Web 应用程序中各个网站或文档上配置的权限如何，均强制实施 Web 应用程序的策略。
**优化性能。**如果将应用程序放在其中还存在其他具有类似数据特征的应用程序的 Web 应用程序中，则应用程序会获得更好的性能。例如，“我的网站”的数据特征包括大量小型网站。而工作组网站通常包含少量大型网站。通过将这两种不同类型的网站分别放置在单独的 Web 应用程序中，生成的数据库就会由具有相似特征的数据组成，从而优化了数据库性能。在设计示例中，“我的网站”和工作组网站没有独特的数据隔离要求，它们共享同一应用程序池。不过，“我的网站”和工作组网站放在单独的 Web 应用程序中以优化性能。
优化可管理性。因为创建单独的 Web 应用程序会产生单独的网站和数据库，所以可以实施不同的网站限制（回收站、有效期限和大小），以及协商不同服务级别的协议。例如，如果“我的网站”内容不是贵组织中最重要的内容类型，则您可以留出更多时间来还原该内容。这允许在还原“我的网站”内容之前还原更重要的内容。在设计示例中，“我的网站”放在单独的 Web 应用程序中，与其他应用程序相比，这使管理员能够更积极地管理增长。
网站集
网站集将逻辑体系结构和信息体系结构结合起来。设计示例中的网站集的设计目标是满足 URL 设计的要求和创建内容的逻辑分区。
为满足 URL 设计的要求，每个 Web 应用程序包括一个根级别网站集。使用管理路径来包含首要网站集的第二层。有关 URL 要求和使用管理路径的详细信息，请参阅下文的“区域和 URL”。网站集的第二层以外，每个网站均是一个子网站。
下图说明了工作组网站的网站层次结构。
.gif "团队网站")
考虑到根级别网站集的要求，设计决策围绕网站集的第二层进行。设计示例包含基于应用程序的性质的选项。
发布的 Intranet 内容
对发布的 Intranet 内容 Web 应用程序的假设是公司内的多个分区将是发布的内容的宿主。在设计示例中，每个分区的内容以单独的网站集为宿主。这具有以下优点：
每个分区可以独立管理其内容的权限。
每个分区的内容可以存储在专用数据库中。
使用多个网站集的缺点包括：
无法跨网站集共享母版页、页面布局、模板、Web 部件和导航。
需要更多工作来跨网站集协调自定义项和导航。
根据 Intranet 应用程序的信息体系结构和设计，发布的内容可以作为无缝应用程序显示给用户。或者，每个网站集可以显示为单独的网站。
我的网站
“我的网站”具有不同的特征，并且对部署“我的网站”的建议很简单。在设计示例中，“我的网站”应用程序纳入了 URL 为 http://my 的首要网站。创建的第一个首要网站集使用“我的网站宿主”模板。纳入了管理路径（使用通配符包含），这允许无限数量的用户创建的网站。管理路径下的所有网站是继承“我的网站宿主”模板的独立网站集。采用 http://my personal/用户名 形式将用户名追加到 URL。下图说明了“我的网站”。
.gif "我的网站")
工作组网站
您可以使用以下两种方法中的任一种在工作组网站应用程序中设计网站集：
允许工作组通过自助式网站创建来创建网站集。此方法的优点是工作组可以根据需要轻松创建网站，而无需管理员帮助。不过，此方法也有许多缺点，其中包括：
失去实施考虑周到的分类的机会。
应用程序可能变得难以管理。
轻松放弃网站。
无法跨可能以其他方式共享网站集的项目或工作组共享模板和导航。
根据贵组织的运营方式，为贵组织创建有限数量的网站集。在此方法中，网站集由 SharePoint 管理员创建。在创建网站集后，工作组可以根据其需要在网站集内创建网站。此方法提供了实施考虑周到的分类的机会，该分类为工作组网站的管理和增长方式提供结构。还有更多机会来在共享网站集的项目和工作组之间共享模板和导航。
设计示例包含了第二种方法，这为工作组网站生成了与发布的 Intranet 内容的网站集层次结构相似的网站集层次结构。信息架构师的挑战是创建网站集的对组织有意义的第二层。下表显示了对不同类型的组织的建议。
| 组织的类型 | 建议的网站集分类 |
|---|---|
产品开发 |
|
研究 |
|
高等教育机构 |
|
国家立法部门 |
|
企业律师事务所 |
|
制造业 |
|
合作伙伴 Web 应用程序
合作伙伴 Web 用于与外部合作伙伴就范围有限或持续时间有限的项目进行协作。按照设计，合作伙伴 Web 应用程序中的网站互不相关。合作伙伴 Web 应用程序的要求包括确保：
项目所有者可以轻松创建用于进行合作伙伴协作的网站。
合作伙伴及其他参与者只能访问他们所从事的项目。
权限由网站所有者管理。
一个项目中的搜索结果没有公开其他项目中的内容。
管理员可以轻松地识别不再使用的网站并删除这些网站。
为满足这些要求，设计示例为每个项目纳入了一个网站集。这样做有以下好处：
各个网站集在项目之间提供了相应级别的隔离。
可实施自助式网站创建。
因为合作伙伴 Web 应用程序也是用于为公司 Internet 网站开发内容的网站集的宿主，所以创建了单独的网站集来进行创作和暂存。
公司 Internet 网站
公司 Internet 网站纳入了一个根级别网站集。此网站集下面的所有网站都是子网站。此结构简化了网站中的网页的 URL。下图说明了公司 Internet 网站的体系结构。
.gif "公司 Internet 网站")
内容数据库
可以使用以下两种方法将内容数据库纳入到设计中（设计示例同时包含这两种方法）：
根据适当的大小警告阈值确定内容数据库的目标大小。在达到大小警告阈值时创建新数据库。利用此方法，可以仅根据大小目标向可用的一个或多个数据库中自动添加网站集。这是最常用的方法。
将网站集与特定的内容数据库关联。利用此方法可以将一个或多个网站集放置到可以独立于其他数据库进行管理的专用数据库中。
如果选择将网站集与特定的内容数据库关联，则可以使用以下方法实现这一点：
使用 Windows PowerShell 在特定数据库中创建网站集。
通过应用以下数据库容量设置，使数据库专门用于一个网站集：
生成警告事件之前允许的网站数量 = 1
此数据库中允许创建的最大网站数量 = 1
通过执行下列步骤，向专用数据库添加一组网站集：
在 Web 应用程序中，创建数据库并将数据库状态设置为“就绪”。
将所有其他数据库的状态设置为“脱机”。内容数据库脱机时，无法创建新网站集。但是，仍可访问脱机数据库中的现有网站集，以进行读取和写入操作。
创建网站集。这些网站集将自动添加到数据库中。
将所有其他数据库的状态设置回“就绪”。
发布的 Intranet 内容
对于发布的 Intranet 内容，设计示例包含单个数据库以便于管理。如果需要，根据目标大小目标添加数据库。
我的网站
对于“我的网站”，设计示例通过管理数据库使其达到最大目标大小来实现高效扩展。配置了以下设置以实现此目标：
网站最大存储空间为：在管理中心的“配额模板”页上配置的此设置限制个人网站的大小。
第二阶段回收站：在“Web 应用程序常规设置”页上配置的此设置确定为第二阶段回收站分配多少附加空间。
此数据库中允许创建的最多网站数：在创建数据库时配置此设置。通过您为前两个值指定的数字计算允许的网站总大小。然后，根据每个数据库的大小目标，确定数据库中可容纳多少个网站。
设计示例根据目标数据库大小 200 GB 和目标“我的网站”大小 1 GB 提供以下示例大小设置：
每个网站的网站大小限制 = 1 GB
数据库的目标大小 = 175 GB
为第二阶段回收站保留 = 15%
最大网站数 = 180
网站级别警告 = 150
在达到网站级别警告时，创建新数据库。创建新数据库后，新的“我的网站”将交替地添加到新数据库和现有数据库中，直到达到其中一个数据库的最大网站数。
工作组网站
对于工作组网站，设计示例再次通过管理数据库使其达到最大目标大小来实现高效扩展。预计大多数组织的工作组网站比“我的网站”大得多。设计示例根据网站集的 30 GB 的限制提供数据库设置。选择适合贵组织中的工作组网站的限制。
针对其工作组具有大存储需要的组织的另一种方法是使每个首要工作组网站集专用一个数据库。
合作伙伴 Web
类似于“我的网站”，合作伙伴 Web 也是通过管理数据库使其达到最大目标大小来实现高效扩展。但在设计示例中，合作伙伴 Web 还是公司 Internet 网站的创作网站集的宿主。因此，数据库设计包含以下两种方法：
创作网站集以专用数据库为宿主。
配置数据库和大小设置来管理所有其他网站和数据库。
因为合作伙伴 Web 以专用 Web 应用程序为宿主，所以可以创建更适合所创建的网站类型的大小限制。设计示例提供了以下示例大小设置：
数据库的目标大小 = 200 GB
每个网站的存储配额 = 5 GB
最大网站数 = 40
创作网站集以专用数据库为宿主
公司 Internet 网站
通过在公司 Internet 网站的设计中使用单个网站集，对此 Web 应用程序使用单个数据库。
区域和 URL
设计示例阐明如何跨企业部署中的多个应用程序协调 URL。
设计目标
以下目标影响 URL 的设计决策：
URL 约定没有限制可通过其访问内容的区域。
可跨设计示例中的所有应用程序使用标准 HTTP 和 HTTPS 端口（80 和 443）。
URL 中没有包括端口号。实际上，在生产环境中通常不使用端口号。
设计原则
为实现这些设计目标，应用以下设计原则：
不使用以主机命名的网站集。请注意，以主机命名的网站集与 IIS 主机头不同。以主机命名的网站集不使用备用访问映射功能。通过多个域 URL 访问相同内容需要备用访问映射功能。因此，使用以主机命名的网站时，只能通过默认区域使用这些网站。
每个应用程序包含单个根网站集。这是使用备用访问映射的要求。如果 Web 应用程序中需要多个根网站集，而您希望只使用默认区域进行用户访问，则以主机命名的网站集是一个很好的选项。
对于包括多个高级网站集的应用程序（其中每个网站集表示一个顶级工作组或项目，例如工作组网站），设计示例包含了管理路径。管理路径提供了对这些类型的网站 URL 的更大控制。
设计权衡
满足设计目标导致一些权衡，其中包括：
URL 较长。
不使用以主机命名的网站集。
设计负载平衡的 URL
在创建 Web 应用程序时，必须选择一个负载平衡的 URL 来分配给该应用程序。另外，必须为 Web 应用程序中所创建的每个区域创建一个负载平衡的 URL。负载平衡的 URL 包括协议、方案、主机名和端口（如果使用）。负载平衡的 URL 必须在所有 Web 应用程序和区域中是唯一的。因此，每个应用程序和每个应用程序中的每个区域需要设计示例中唯一的 URL。
Intranet
构成 Intranet 的三个 Web 应用程序中的每一个都需要唯一的 URL。在设计示例中，Intranet 内容的目标受众是内部员工和远程员工。在声明身份验证设计示例中，员工对这些应用程序中的每一个使用相同的 URL，而不管他们是在现场还是远程的。虽然此方法为 SharePoint 设计添加了安全层（所有流量都是 SSL），但此方法需要将内部流量连同远程流量一起通过防火墙或网关产品进行路由，或者设置拆分 DNS 环境来解决内部网络中的内部请求。
对于经典身份验证设计示例，URL 对于内部和远程员工有所不同。下表显示了供内部和远程员工访问经典身份验证设计示例中的每个应用程序的 URL。
| 应用程序 | 内部员工 URL | 远程员工 URL |
|---|---|---|
发布的 Intranet 内容 |
http://fabrikam |
https://intranet.fabrikam.com |
工作组网站 |
http://teams |
https://teams.fabrikam.com |
我的网站 |
http://my |
https://my.fabrikam.com |
合作伙伴网站
在设计示例中，合作伙伴网站供内部员工、远程员工和合作伙伴员工访问。在声明身份验证设计示例中，这些用户中的每一个都输入相同的 URL，而不管使用的是何种身份验证方法。在经典身份验证设计示例中，每种不同类型的用户输入不同的 URL。虽然远程员工和合作伙伴员工都使用 SSL (HTTPS) 从外部访问合作伙伴网站，但每组需要不同的 URL 来应用使用单独区域（即不同的身份验证方法和不同的区域策略）的好处。下表显示了内部员工、远程员工和合作伙伴用来访问合作伙伴网站的 URL，如经典身份验证设计示例中所示。
| 区域 | URL |
|---|---|
内部员工 URL |
http://partnerweb |
远程员工 URL |
https://remotepartnerweb.fabrikam.com |
合作伙伴 URL |
https://partnerweb.fabrikam.com |
公司 Internet 网站
公司 Internet 网站是公共网站，可供任何用户通过默认 URL http://www.fabrikam.com 来访问。应用 Internet 区域策略（即匿名访问和拒绝写入）。
不过，为支持在公共网站上管理和创作任务，设计示例包含了内部和远程员工的 URL。可以使用这些区域的策略来确保适当访问目标安全组以便创作任务和用于维护任务。经典身份验证和声明身份验证设计示例对此服务器场使用相同的方法。下表显示了每个区域的 URL。
| 区域 | URL |
|---|---|
内部员工 URL |
http://fabrikamsite |
远程员工 URL |
https://fabrikamsite.fabrikam.com |
客户 URL |
http://www.fabrikam.com |
对 URL 路径使用显式包含和通配符包含
通过定义管理路径，可以指定 Web 应用程序的 URL 命名空间中的哪些路径用于网站集。可以指定在根网站下的一个截然不同的路径中存在一个或多个网站集。如果没有管理路径，则在根网站集下创建的所有网站都属于根网站集的一部分。
可以创建以下两种类型的管理路径：
**显式包含：**具有所分配的显式 URL 的网站集。显式包含仅应用于一个网站集。可以在根网站集下创建许多显式包含。例如，http://fabrikam/hr 就是用此方法创建的网站集的 URL。这会影响所添加的每个显式路径的性能，因此建议将使用显式包含创建的网站集的数量限制为大约 20 个。
**通配符包含：**添加到 URL 中的路径。此路径表示在路径名后直接指定的所有网站都是唯一网站集。此选项通常用于支持自助式创建的网站集，例如“我的网站”。例如，http://my/personal/user1 就是用此方法创建的网站集的 URL。
设计示例使用了这两种类型，如以下各节中所述。
显式包含：发布的 Intranet 内容
在设计示例中，发布的 Intranet Web 应用程序使用了显式包含。
发布的 Intranet 内容
在发布的 Intranet 内容 Web 应用程序中，显式包含用于每个子网站，例如人力资源、设施和采购。如果需要，这些网站集中的每一个都可以与不同的内容数据库关联。此示例中显式包含的使用假定 Web 应用程序中没有创建任何其他类型的网站，包括通配符包含。
对使用显式包含创建的网站的推荐限制是大约 20 个。如果贵组织需要更多网站集，请考虑使用通配符包含或以主机命名的网站集。
在经典身份验证设计示例中，使用显式包含生成了下表中所示的 URL。
| 内部员工（Intranet 区域） | 远程员工（默认区域） |
|---|---|
http://fabrikam |
https://intranet.fabrikam.com |
http://fabrikam/hr |
https://intranet.fabrikam.com/hr |
http://fabrikam/facilities |
https://intranet.fabrikam.com/facilities |
http://fabrikam/purchasing |
https://intranet.fabrikam.com/purchasing |
在此示例中，根网站集 http://fabrikam 表示 Intranet 的默认主页。此网站适合作为用户内容的宿主。
通配符包含：工作组网站、“我的网站”和合作伙伴 Web
工作组网站、“我的网站”和合作伙伴 Web 应用程序使用了通配符包含。通配符包含适用于允许用户创建自己的网站集的应用程序和包含大量网站集的 Web 应用程序。通配符包含指示通配符后面的下一项是网站集的根网站。
工作组网站
在工作组网站应用程序中，通配符包含用于每个工作组网站集。好的管理实践建议您将首要工作组网站的数量保持在可管理的数量之内。另外，工作组网站的分类对业务的运营方式来说应该是合理的。
在经典身份验证设计示例中，使用通配符包含可生成下表中所示的 URL。
| 内部员工（Intranet 区域） | 远程员工（默认区域） |
|---|---|
http://teams/sites/Team1 |
https://teams.fabrikam.com/sites/Team1 |
http://teams/sites/Team2 |
https://teams.fabrikam.com/sites/Team2 |
http://teams/sites/Team3 |
https://teams.fabrikam.com/sites/Team3 |
在此示例中，根网站集 http://team 未必是用户内容的宿主。
我的网站
“我的网站”提供了自助式网站创建。在用户浏览 Intranet 时，首先单击“我的网站”，将自动为该用户创建“我的网站”。在设计示例中，“我的网站”包括名为 /personal (http://my/personal) 的通配符包含。“我的网站”功能将自动将用户名追加到 URL。
在经典身份验证设计示例中，这会生成下表中所示格式的 URL。
| 内部（Intranet 区域） | 远程员工（默认区域） |
|---|---|
http://my/personal/user1 |
https://my.fabrikam.com/personal/user1 |
http://my/personal/user2 |
https://my.fabrikam.com/personal/user2 |
http://my/personal/user3 |
https://my.fabrikam.com/personal/user3 |
合作伙伴 Web 应用程序
合作伙伴 Web 应用程序旨在允许员工轻松创建安全网站以与外部合作伙伴进行协作。为支持此目标，允许自助式网站创建。
在经典身份验证设计示例中，合作伙伴 Web 应用程序包括名为 /sites (http://partnerweb/sites) 的通配符包含。这会生成下表中所示格式的 URL。
| 内部员工（Intranet 区域） | 远程员工（默认区域） |
|---|---|
http://partnerweb/sites/project1 |
https://remotepartnerweb.fabrikam.com/sites/project1 |
http://partnerweb/sites/project2 |
https://remotepartnerweb.fabrikam.com/sites/project2 |
http://partnerweb/sites/project3 |
https://remotepartnerweb.fabrikam.com/sites/project3 |
合作伙伴参与者可以使用下表中列出的 URL 访问合作伙伴网站。
| 合作伙伴（Extranet 区域） |
|---|
https://partnerweb.fabrikam.com/sites/project1 |
https://partnerweb.fabrikam.com/sites/project2 |
https://partnerweb/fabrikam.com/sites/project3 |
合作伙伴 Web 应用程序的例外（如设计示例中所示）是专用于为公司 Internet 网站创作内容的网站集。对于此网站集，使用显式包含。这提供了一个在同一 Web 应用程序中同时使用显式包含和通配符包含的示例。
区域策略
可以为 Web 应用程序创建策略来在 Web 应用程序级别强制实施权限。可以为 Web 应用程序定义通用策略，或者只为特定区域定义策略。策略对 Web 应用程序或区域内的所有内容强制实施权限。策略权限优先于为网站和内容配置的所有其他安全设置。可以根据用户或用户组配置策略，但不能根据 SharePoint 组配置策略。如果添加或更改区域策略，搜索必须对网站进行重新爬网才能选取新权限。
在对单个区域启用了多种类型的身份验证的协作服务器场的声明身份验证设计示例中没有使用策略。在经典身份验证设计示例中和规定了 Windows 身份验证的声明身份验证设计示例的发布的服务器场中实施了策略。在发布的服务器场中，使用策略在匿名用户和有权管理网站的用户之间添加了一个额外的安全层。
设计示例提供了用于实现以下目的的多个策略的示例：
拒绝对发布的内容进行写入访问。
确保作者和测试者对发布的内容具有相应访问权限。