SharePoint Online 门户内容聚合指南
每个门户设计都包含一套显示组件，可以动态定位内容，以便在门户页上显示。 这些控件的操作基础是内容聚合概念，我们在本文中将其定义为在运行时动态定位所需内容的过程。 选择使用哪种技术执行内容聚合可能会对门户及其页面的性能产生重大影响。
注意
尽管本指南主要针对的是 SharePoint Online，但大多数内容也同样适用于本地 SharePoint 环境中托管的门户。
不应执行的操作
以下列表包含在需要获得良好的内容聚合体验时不应执行的关键事项。
禁止事项：
- 随时随地使用“实时”内容聚合技术。
- 在大量门户页面（例如主页）上放置十几个或更多设计不当的内容聚合控件。
- 使用组策略对象 (GPO) 强制所有浏览器默认加载有问题的门户页面。
- 不对内容聚合结果强制实施行限制。
- 不缓存任何内容聚合结果。
- 面向传统列表 (SOAP) Web 服务。 对于其他问题，向其传递一些设计不当的 CAML 查询。
已定义的内容聚合
请务必制定本文上下文的内容聚合的明确定义。
内容聚合是指当某内容在门户内除当前页面之外的一个或多个位置中存在时，动态定位和检索该内容以在当前页面上显示的概念。
内容聚合不涉及在当前页面中创作的内容。
内容聚合主要用于门户的前端用户视图（而不是后端管理视图）。
可在其中使用内容聚合的示例：
- 门户主页包含一个最新新闻控件，它呈现可指向门户内最新发布的文章的链接列表。
- 门户页面包含一个全局导航控件，用于呈现在自定义 SharePoint 列表中托管的导航链接。
实时内容聚合要求
在实时内容聚合中，对内容聚合源所做的更改立即显示在定位该源的内容聚合控件中。
以下是可能出现实时内容聚合的几个示例：
- 内容作者发布文章，预计其链接立即显示在门户主页的“最新新闻”控件中。
- 门户管理员将一个链接添加到全局导航列表，并预期它立即显示在“全局导航”控件中。
尽管紧急信息确实需要绝对的实时分发，但分发门户不应该是分发此类信息的初始选择。 许多其他系统（例如移动电话、无线电话、卫星、电视、报警器、警报、扬声器等）更适合于这项任务。 门户更适合分发后续信息、上下文和细节；根据推测，该分布不需要实时发生。
考虑到这种情况，请考虑最佳做法：没有门户内容重要到必须消耗实时内容聚合的成本。
遗憾地是，几乎每个门户内容管理团队都默认将其最普通的内容视为紧急内容，并且有必要进行实时内容聚合。
其中，门户架构师面临的挑战是：你是否屈服于阻碍门户性能这些压力和风险，或者你是否反而会说服他们，并提供性能良好的门户？ 我们鼓励你说服他们。
在任何发布系统中，绝对的“实时”内容聚合在技术上是不可能实现的。 即使遵守发布门户的默认行为，内容聚合/渲染管道的各个不同点也会发生延迟和缓存；其中一部分是可见并可配置的（例如，自定义客户端缓存、服务器端输出缓存、服务器端对象缓存），另外一部分则是隐藏且不可变的（例如，数据库查询计划、内部应用程序缓存等）。
通常只有内容作者注意到内容聚合延迟。 由于最终用户对内容发布过程缺乏洞察力，导致他/她对实时内容聚合没有期望。
接受实时内容聚合无法成功发生之后，剩下的就是协商以下内容：
- 你愿意等待多久来查看内容？
- 为更快地看到内容，你愿意“支付”多少钱？
内容聚合延迟在性能良好的门户解决方案中是不可避免的。 如果对可接受的延迟妥协，门户用户将会感谢你。
注意
即使无法实时进行内容聚合，但在某些情况下，举例来说，你可以使用超时时间为 5 分钟的自定义警报功能，以及超时时间为 1 小时的新闻聚合功能。 这不是实时内容聚合，但大多数最终用户会认为它是实时聚合。
内容聚合技术
以下各节介绍了可用于 SharePoint Online 的两种内容聚合技术。
重要
相对于基于 CAML 的内容聚合，我们建议采用基于搜索的内容聚合。
基于 CAML 的内容聚合
基于 CAML 的内容聚合术基于对协作应用程序标记语言 (CAML) 查询的使用。
可以构建 CAML 查询并将其用于执行 SharePoint 内的内容聚合操作。 这些查询是针对 SharePoint 内容数据库执行的。 CAML 查询已融入服务器端控件的实现中，例如按查询显示内容的现成 Web 部件。 CAML 查询也可以直接用于自定义客户端 JavaScript 控件可用的各种内容发现 API。
CAML 的主要优点在于：它允许最大程度地实现“实时”内容聚合。
CAML 的主要缺点是：要设计出运行良好的 CAML 查询，它需要知识和技能；一个看似无关紧要的变化可能导致 CAML 查询执行欠佳和/或一系列无休止的缓存失误，上述结果的不良影响平常并不明显，但在门户负载过大时就会显现出来。
通过禁止部署自定义代码，SharePoint Online 已经删除了历史上最严重的 SharePoint 性能杀手类别：使用设计不佳的 CAML 查询的自定义服务器端控件和 Web 部件。 但是，仍然可能通过按查询显示内容的现成 Web 部件以及通过自定义客户端 JavaScript 控件误用 CAML。
请注意以下几点：
每个客户端 CAML 请求导致直接数据库查询：
- 客户端 CAML 结果不会缓存在服务器上。
- 客户端 CAML 请求命中用于执行的数据库服务器（始终出现缓存失误）。
每个服务器端 CAML 请求都有趋向于直接数据库查询的风险：
- 基于类似的用户权限集，服务器端 CAML 结果缓存在服务器上。
- 从不缓存包含个性化字段的查询。
- 当出现缓存失误时，服务器端 CAML 请求命中用于执行的数据库服务器。
- 缓存失误在具有大量 Web 前端的场中几乎是肯定存在的。
重要
我们建议你尽可能避免基于 CAML 的内容聚合。
有关使用基于 CAML 的内容聚合的准则
- 避免在大容量页面上使用。
- 将其使用范围限制到特定类别的内容（例如警报）。
- 尽可能定义最简单、最高效的 CAML 查询并验证其性能。
- 在目标列表上实现索引列。
- 加入针对查询的行限制。
- 确保自定义客户端 JavaScript 控件提供阅读更多链接，从而可将用户重定向到低容量的“查看全部”页面。
- 确保自定义客户端 JavaScript 控件利用客户端数据访问层框架缓存内容响应。 “没有结果”是有效响应，也应该缓存。
- 强制执行客户端缓存到期的时间不少于 5 分钟。
有关客户端数据访问层的详细信息，请参阅 SharePoint Online 门户性能指南
基于搜索的内容聚合
基于搜索的内容聚合技术建立在使用 SharePoint 搜索关键字查询语言 (KQL) 查询的基础上。
可以构建搜索 KQL 查询，并使用它们在 SharePoint 中执行内容聚合操作。 这些查询是针对 SharePoint 搜索索引执行的。 搜索 KQL 查询融入服务器端控件的实现中，例如按搜索显示内容的现成 Web 部件。 KQL 查询也可以直接用于自定义客户端 JavaScript 控件可用的搜索 API。
基于搜索的内容聚合的主要优势在于：它利用 SharePoint 搜索服务，该服务旨在于负载过大时大规模提供卓越性能。
基于搜索的内容聚合的主要缺点是：它依赖于搜索索引，这意味着在搜索索引中显示内容更改之前会稍有延迟。
请注意以下几点：
必须对门户内容进行爬网并将其添加到搜索索引，以便用于基于搜索的数据聚合。
SharePoint 不断对门户内容进行爬网以提供最新的搜索索引。 但是，在索引中显示内容更改之前会稍有延迟。
搜索架构必须配置为允许通过搜索发现所需的内容属性。
重要
建议使用基于搜索的内容聚合。
有关使用基于搜索的内容聚合的准则
确保内容管理团队了解必须先对内容进行爬网，然后才能聚合。
- 建立关于内容聚合延迟的期望。
配置必要的搜索架构。
- 选择适当的范围（租户、网站集或 Web）。
- 触发爬网和托管属性的自动生成。
- 需要排序/优化时，利用现成的占位符托管属性（例如，RefinableInt01）。
设计适当的结果来源和查询。
- 根据需要定位单个列表、Web 或站点。
- 根据需要定位单个内容类型。
- 根据需要定位特定托管属性（例如，网站栏）。
选择所需的显示控件：
- 现成的控件：
- 使用按搜索显示内容的 Web 部件。
- 返回所需的最少行和列。
- 开发必要的显示模板。
- 如果需要，启用异步客户端呈现。
- 自定义控件：
- 使用利用 REST Search API 的自定义客户端 JavaScript 显示控件。
- 返回所需的最少行和列。
- 利用客户端数据访问层框架来缓存响应。
- 现成的控件：
有关客户端数据访问层的详细信息，请参阅 SharePoint Online 门户性能指南