第2章 — 基础架构

设置缓存基础结构

在本系列的第1章中，我们介绍了Publish系统和Dispatcher的基本拓扑。 一组发布和Dispatcher服务器可以在许多变体中进行配置，具体取决于预期的负载、数据中心的拓扑以及所需的故障转移属性。

我们将绘制最常见的拓扑图，并描述其优点和不足之处。 当然，这份清单永远不可能完整。 唯一的限制是你的想象力。

“旧版”设置

在早期阶段，潜在访客数量很少，硬件昂贵，而且Web服务器不像现在这样被视为业务关键型服务器。 常见的设置是将一个Dispatcher用作负载平衡器，并在两个或更多发布系统之前缓存。 Dispatcher核心的Apache Server非常稳定，在大多数设置下，足以满足大量请求。

“旧版”Dispatcher设置 — 按当前的标准来看不太常见

这是Dispatcher从中收到其名称的位置：它基本上是在调度请求。 这种设置已不再很常见，因为它无法满足当今对性能和稳定性的更高要求。

多足安装

如今，稍有不同的拓扑结构更为常见。 多分支拓扑的每个发布服务器有一个Dispatcher。 专用（硬件）负载平衡器位于AEM基础架构的前面，用于向这两个（或更多）分支调度请求：

现代“标准”Dispatcher设置 — 易于处理和维护

以下是这种设置的原因，

“扩展”设置

Apache Server价格低廉且易于配置，何不进一步将扩展范围扩展到这一级别。 为何每个发布服务器前面没有两个或更多Dispatcher？

“扩展”设置 — 有一些应用领域，但也有一些限制和注意事项

你绝对可以这样做！ 对于这种设置，有许多有效的应用方案。 但是，您还应考虑一些限制和复杂性。

失效

每个发布系统都连接到多个Dispatcher，每个发布系统都必须在内容发生更改时失效。

维护

不用说，Dispatcher和Publish系统的初始配置要复杂一些。 但请记住，推出“滚动”版本的工作量也要高一些。 AEM系统在运行时可以而且必须更新。 但是，明智的做法是在他们积极为请求提供服务时不要这样做。 通常，您只想更新发布系统的一部分，而其他系统仍主动提供流量，然后在测试后，切换到其他部分。 如果您很幸运，并且在部署过程中可以访问负载平衡器，则可以在此处禁用到维护中服务器的路由。 如果您位于没有直接访问权限的共享负载平衡器上，则宁愿关闭要更新的发布的调度程序。 那里越多，你就越需要关门。 如果数量很大并且您计划频繁更新，建议采取一些自动化操作。 如果你没有自动化工具，扩大规模无论如何都是个坏主意。

在过去的项目中，我们使用了一种不同的技巧，在不直接访问负载平衡器本身的情况下从负载平衡中删除发布系统。

负载平衡器通常会“ping”，即用于查看服务器是否已启动并正在运行的特定页面。 一个简单的选择通常是ping主页。 但是，如果要使用ping命令指示负载平衡器不要平衡流量，则应当选择其他方法。 您可以创建一个专用模板或servlet，将其配置为使用"up"或"down"进行响应（在正文中或作为http响应代码）。 当然，不得将该页面的响应缓存在Dispatcher中 — 因此始终从发布系统中全新获取该响应。 现在，如果您配置负载平衡器以检查此模板或servlet，则可以轻松让发布“假定”它停止运行。 它不是负载平衡的一部分，可以更新。

全球分布

“全球分发”是一种“扩展”设置，其中您在每个发布系统前有多个Dispatcher — 现在分布在世界各地，以更接近客户并提供更好的性能。 当然，在这种情况下，您没有中心负载平衡器，而是具有基于DNS和地理IP的负载平衡方案。

水平缩放

即使在本地数据中心中，在每个发布系统前面有多个Dispatcher的“横向扩展”拓扑也有一些优势。 如果由于高流量（以及良好的缓存命中率）而导致Apache Server出现性能瓶颈，并且您无法再扩展硬件（通过添加CPU、RAM和更快的磁盘），则可以通过添加Dispatcher来提高性能。 这称为“水平缩放”。 但是，这有限制，尤其是当您经常使流量失效时。 我们将在下一节中描述这种影响。

横向扩展拓扑的限制

添加代理服务器通常会提高性能。 但是，在某些情况下，添加服务器实际上会降低性能。 如何进行？ 假设您有一个新闻门户，在那里您每分钟都会介绍新文章和页面。 Dispatcher通过“自动失效”而失效：每当发布页面时，同一站点上的缓存中的所有页面都会失效。 这是一个有用的功能 — 我们在本系列的第1章中介绍了此功能 — 但它也意味着，当您的网站上有频繁的更改时，您经常会使缓存失效。 如果您每个发布实例只有一个Dispatcher，则第一个访客请求页面时，会触发对该页面的重新缓存。 第二个访客已获取缓存版本。

如果您有两个Dispatcher，则第二个访客有50%的可能性不会缓存页面，然后再次呈现该页面时，他会遇到更大的延迟。 每个Publish拥有更多的Dispatcher会让情况变得更糟。 具体情况是，发布服务器会收到更多负载，因为它必须分别重新渲染每个Dispatcher的页面。

在缓存刷新频繁的横向扩展方案中性能降低。

缓解过度扩展问题

您可以考虑为所有Dispatcher使用中央共享存储，或者同步Apache服务器的文件系统以缓解这些问题。 我们只能提供有限的第一手经验，但应做好准备，这增加了系统的复杂性，并可能会引入全新的错误类别。

我们对NFS进行了一些实验，但NFS由于内容锁定而带来了巨大的性能问题。 这实际上降低了总体性能。

结论 — 不建议在多个调度程序之间共享公共文件系统。

如果您遇到性能问题，请同等地扩展Publish和Dispatcher以避免发布器实例上的峰值负载。 发布/Dispatcher比率没有黄金规则，它高度取决于请求的分布以及发布和缓存失效的频率。

如果您还担心访客体验的延迟，请考虑使用内容交付网络、缓存重新获取、抢先缓存预热、设置宽限时间（如本系列的第1章所述）或参阅第3部分的一些高级想法。

“交叉连接”设置

我们偶尔会看到另一种设置，即“交叉连接”设置：发布实例没有专用的Dispatcher，但所有Dispatcher都已连接到所有Publish系统。

交叉连接拓扑：冗余增加，复杂性增加。

乍一看，这为相对较小的预算提供了更多的冗余。 当其中一个Apache服务器关闭时，您仍然可以使用两个发布系统来执行渲染工作。 此外，如果其中一个Publish系统崩溃，您还有两个Dispatcher提供缓存的加载。

但这是有代价的。

首先，取一条腿进行维修相当麻烦。 实际上，这就是这个方案的目的；为了更有弹性，尽可能保持正常运行。 我们已经看到了复杂的维护计划如何处理这种情况。 首先重新配置Dispatcher 2，删除交叉连接。 重新启动Dispatcher 2。 正在关闭Dispatcher 1，更新发布1， …等等。 如果能扩展到两条腿以上，您应该仔细考虑。 你会得出这样的结论：它实际上增加了复杂性，增加了成本，并且是造成人为错误的强大根源。 最好将此自动化。 所以，最好检查一下，如果您确实有人力资源将此自动化任务纳入您的项目计划中。 虽然这样做可能会节省一些硬件成本，但您可能会在IT员工上花费双倍的成本。

其次，您可能在AEM上运行了一些需要登录的用户应用程序。 您可以使用粘性会话，确保始终从同一AEM实例提供一位用户，以便您可以维护该实例上的会话状态。 进行这种交叉连接设置时，您必须确保粘性会话在负载平衡器和Dispatcher上正常运行。 并非不可能，但您需要了解这一点，并添加一些额外的配置和测试时间，这同样可能会使您通过节省硬件而节省成本。

结论

我们不建议您将此交叉连接方案用作默认选项。 但是，如果您决定使用它，则需要仔细评估风险和隐藏成本，并计划将配置自动化作为项目的一部分包括在内。

后续步骤