第1章 — Dispatcher概念、模式和反模式

最近更新： 2025年5月5日
  • 适用对象：
  • Experience Manager 6.4
  • Experience Manager 6.5

创建对象：

  • 初学者
  • 开发人员

概述

本章简要介绍Dispatcher的历史和机制，并讨论这会如何影响AEM开发人员如何设计其组件。

为什么开发人员应关注基础架构

Dispatcher是大多数（如果不是全部）AEM安装的重要组成部分。 您可以找到许多讨论如何配置Dispatcher以及提示和技巧的在线文章。

但是，这些零星的信息总是从非常技术性的层面开始 — 假设您已经知道要做什么，因此只提供有关如何实现所需内容的详细信息。 我们从未找到任何概念性文章来描述​ 什么是 ​以及为什么是，以及您使用调度程序可以执行哪些操作，但不能执行哪些操作。

反模式：Dispatcher作为后想

这种基本信息的缺乏导致了许多反模式。我们在许多AEM项目中看到了：

  1. 由于Dispatcher安装在Apache Web Server中，因此配置它是项目中“Unix gods”的作业。 “凡人Java开发者”不必担心这个问题。

  2. Java开发人员需要确保他的代码可正常工作……调度程序稍后会神奇地使其变快。 调度程序始终是事后才考虑的问题。 然而，这种做法并不奏效。 开发人员在设计代码时必须考虑调度程序。 他需要知道它的基本概念才能做到这点。

“先让它工作，然后让它快”并不总是正确的

您可能听过编程建议​ “首先使其正常工作 — 然后使其快速运行。”。这并非完全错误。 但是，如果没有正确的上下文，它往往被误解并且无法正确应用。

该建议应避免开发人员过早优化代码，此类代码可能永远不会运行，或者运行非常少，以至于优化的影响力不足以证明有理由进行优化。 此外，优化会导致代码更加复杂，从而引入错误。 因此，如果您是开发人员，请不要在微优化每行代码上花费太多时间。 只需确保您选择了正确的数据结构、算法和库，并等待探查器的热点分析，以查看更彻底的优化在哪些情况下可以提高整体性能。

架构决策和工件

然而，在“架构”决策方面，“先让它运作，然后让它快起来”的建议是完全错误的。 什么是体系结构决策？ 简言之，它们是昂贵、困难和/或事后不可能改变的决定。 请记住，这种“昂贵”有时等同于“不可能”。 例如，当项目预算不足时，不可能实施成本高昂的更改。 对的基础结构变化是这一类别中第一个出现在多数人脑海中的变化。 不过，还有另外一种“建筑”工艺品，它们可能会变得非常讨厌改变：

  1. 位于应用程序“中心”的代码段，许多其他代码段都依赖该代码段。 更改这些组件时，需要一次性更改并重新测试所有依赖项。

  2. 伪像，涉及一些与时间相关的异步场景，在这种场景中，输入 — 以及系统的行为可能非常随机地变化。 变化可能会产生无法预料的影响，而且可能很难测试。

  3. 在系统的所有部分和部件中反复使用和重复使用的软件模式。 如果软件模式被证明是次优的，则所有使用该模式的工件都需要重新编码。

还记得吗？ 在本页上，我们说过Dispatcher是AEM应用程序的重要组成部分。 对Web应用程序的访问非常随机，用户来往于不可预测的时间。 最终 — 所有内容将（或应该）缓存在Dispatcher中。 因此，如果您仔细研究，您可能已经意识到，缓存可以视为“架构”构件，因此应该被团队的所有成员、开发人员和管理员所理解。

我们并不是说开发人员应该实际配置Dispatcher。 他们需要了解概念（尤其是边界），以确保Dispatcher也能利用他们的代码。

Dispatcher不会奇迹般地提高代码速度。 开发人员需要在创建组件时考虑Dispatcher。 因此，他需要知道它是如何运作的。

Dispatcher缓存 — 基本原则

Dispatcher用作缓存Http — 负载平衡器

Dispatcher是什么？为什么它最初被称为“Dispatcher”？

Dispatcher是

  • 首先是缓存

  • 反向代理

  • 用于Apache httpd webserver的模块，用于为Apache的多功能性添加AEM相关功能，并与所有其他Apache模块（例如SSL甚至SSI包含，我们将在后面看到）一起平稳运行

在Web的早期，一个网站可能会有几百个访客。 一个Dispatcher的设置可以“分派”请求，也可以平衡多个AEM发布服务器的请求负载，这样通常就足够了 — 因此，该名称为“Dispatcher”。 但是，这种设置已经不再经常使用。

我们将在本文后面看到设置Dispatcher和Publish系统的各种方式。 首先，我们来了解一些http缓存基础知识。

Dispatcher缓存的基本功能

Dispatcher缓存的基本功能

此处解释了Dispatcher的基础知识。 Dispatcher是一个简单的缓存反向代理，能够接收和创建HTTP请求。 正常的请求/响应周期如下所示：

  1. 用户请求页面
  2. Dispatcher会检查它是否已具有该页面的渲染版本。 假设这是对此页面的第一个请求，并且Dispatcher找不到本地缓存副本。
  3. Dispatcher从Publish系统请求页面
  4. 在Publish系统上，页面通过JSP或HTL模板渲染
  5. 页面将返回到Dispatcher
  6. Dispatcher将缓存页面
  7. Dispatcher会将页面返回到浏览器
  8. 如果再次请求同一页面，则可以直接从Dispatcher缓存中提供该页面，而无需在Publish实例上重新渲染该页面。 这节省了在Publish实例上等待用户和CPU周期的时间。

我们在最后一节中谈到“页面”。 但同样的方案也适用于其他资源，如图像、CSS文件、PDF下载等。

数据缓存方式

Dispatcher模块利用托管Apache Server提供的工具。 HTML页、下载和图片等资源作为简单文件存储在Apache文件系统中。 就是这么简单。

文件名由所请求资源的URL派生。 如果您请求文件/foo/bar.html，该文件例如存储在/var/cache/docroot/foo/bar.html下。

原则上，如果所有文件都进行了缓存，因而静态存储在Dispatcher中，则可以拉取Publish系统的插件，而Dispatcher将充当一个简单的Web服务器。 但这只是为了说明原则。 现实生活要复杂得多。 您不能缓存所有内容，而且缓存永远不会完全“满”，因为由于渲染过程的动态性，资源数量可能是无限的。 静态文件系统的模型有助于粗略了解Dispatcher的功能。 并且它有助于解释Dispatcher的限制。

AEM URL结构和文件系统映射

要更详细地了解Dispatcher，让我们重新访问一个简单示例URL的结构。 让我们看下面的示例，

http://domain.com/path/to/resource/pagename.selectors.html/path/suffix.ext?parameter=value&otherparameter=value#fragment

  • http表示协议

  • domain.com是域名

  • path/to/resource是资源存储在CRX中的路径，随后存储在Apache Server的文件系统中

从这里，AEM文件系统与Apache文件系统之间有些不同。

在AEM中，

  • pagename是资源标签

  • selectors表示Sling中使用的多个选择器以确定资源的呈现方式。 URL可以具有任意数量的选择器。 它们以句点分隔。 例如，选择器部分可能类似于“french.mobile.fancy”。 选择器只能包含字母、数字和破折号。

  • html作为最后一个“选择器”称为扩展。 在AEM/Sling中，它还会部分确定渲染脚本。

  • path/suffix.ext是一个类似路径的表达式，可以作为URL的后缀。 可以在AEM脚本中使用它来进一步控制资源的呈现方式。 稍后我们将提供有关此部分的完整部分。 目前，了解您可以将其用作附加参数应该已经足够。 后缀必须具有扩展名。

  • ?parameter=value&otherparameter=value是URL的查询节。 它用于将任意参数传递给AEM。 无法缓存包含参数的URL，因此应限制仅使用绝对必需的参数。

  • #fragment，URL的片段部分未传递到AEM，它仅在浏览器中使用；在JavaScript框架中作为“路由参数”使用，或者跳转到页面上的特定部分。

在Apache中（引用以下图表），

  • pagename.selectors.html在缓存的文件系统中用作文件名。

如果URL具有后缀path/suffix.ext，则

  • pagename.selectors.html已创建为文件夹

  • path pagename.selectors.html文件夹中的文件夹

  • suffix.ext是path文件夹中的文件。 注意：如果后缀没有扩展名，则不会缓存文件。

从Dispatcher获取URL后 文件系统布局

从Dispatcher获取URL后​ 文件系统布局

基本限制

URL、资源和文件名之间的映射非常简单。

不过，你可能注意到一些陷阱，

  1. URL可能会变得很长。 在本地文件系统上添加/docroot的“路径”部分很容易超出某些文件系统的限制。 在Windows上的NTFS中运行Dispatcher是一项挑战。 不过，使用Linux是安全的。

  2. URL可以包含特殊字符和变音。 这通常不是Dispatcher的问题。 但请记住，URL会在应用程序的多个位置进行解释。 我们经常会看到某个应用程序表现出奇怪的行为 — 只是为了找出一段很少使用的（自定义）代码未经过彻底测试而出现的特殊字符。 如果你可以的话，你应该避开他们。 如果做不到，请计划全面测试。

  3. 在CRX中，资源包含子资源。 例如，一个页面将具有多个子页面。 这在文件系统中无法匹配，因为文件系统具有文件或文件夹。

不缓存不带扩展名的URL

URL必须始终具有扩展名。 不过，您可以在AEM中处理不带扩展名的URL。 这些URL将不会缓存在Dispatcher中。

示例

http://domain.com/home.html是​ 可缓存

http://domain.com/home是​ 不可缓存

当URL包含后缀时，将应用相同的规则。 后缀需要具有扩展才能缓存。

示例

http://domain.com/home.html/path/suffix.html是​ 可缓存

http://domain.com/home.html/path/suffix是​ 不可缓存

您可能会问，如果资源部分没有扩展名，但后缀有扩展名，会出现什么情况？ 在这种情况下，URL完全没有后缀。 查看下一个示例：

示例

http://domain.com/home/path/suffix.ext

/home/path/suffix是资源的路径……因此URL中没有后缀。

结论

始终将扩展添加到路径和后缀。 了解SEO的人有时会辩称，这会在搜索结果中将你排在后面。 但是，未缓存的网页速度会非常慢，排名会进一步下降。

冲突的后缀URL

假定您有两个有效的URL

http://domain.com/home.html

和

http://domain.com/home.html/suffix.html

它们在AEM中绝对有效。 在本地开发计算机上，您不会看到任何问题(没有Dispatcher)。 在UAT或负载测试中，您很可能也不会遇到任何问题。 我们面临的问题是如此微妙，以至于通过了大多数测试。 当您处于高峰期并且处理时间有限、可能没有服务器访问权限或资源无法修复它时，它将给您带来沉重打击。 我们在那里……

那么……有什么问题吗？

文件系统中的home.html可以是文件或文件夹。 但并非两者都与AEM中的情况相同。

如果您先请求home.html，则将其创建为文件。

对home.html/suffix.html的后续请求返回有效结果，但由于文件home.html在文件系统中“阻止”该位置，因此无法再次创建home.html作为文件夹，因此不会缓存home.html/suffix.html。

文件系统中的文件阻止位置阻止缓存子资源

文件系统中的文件阻止位置阻止缓存子资源

如果反过来，首先请求home.html/suffix.html，然后先将suffix.html缓存在文件夹/home.html下。 但是，当您随后请求home.html作为资源时，此文件夹会被删除并替换为文件home.html。

当父级作为资源获取时删除路径结构

当父级作为资源获取时删除路径结构

因此，缓存的结果完全是随机的，取决于传入请求的顺序。 让事情变得更加棘手的是，您通常有多个调度程序。 此外，在不同的Dispatcher中，性能、缓存命中率和行为可能会有所不同。 如果您想了解网站无响应的原因，您需要确保查看的是包含不幸缓存顺序的正确Dispatcher。 如果你正在查看的Dispatcher幸运地拥有更有利的请求模式，那么你将迷失在寻找问题的过程中。