第2章 — 基础架构
设置缓存基础结构
在本系列的第1章中,我们介绍了Publish系统和Dispatcher的基本拓扑。 一组Publish和Dispatcher服务器可以通过多种方式配置,具体取决于预期的负载、数据中心的拓扑以及所需的故障转移属性。
我们将绘制最常见的拓扑图,并描述其优点和不足之处。 当然,这份清单永远不可能完整。 唯一的限制是你的想象力。
“旧版”设置
在早期阶段,潜在访客数量很少,硬件昂贵,而且Web服务器不像现在这样被视为业务关键型服务器。 常见的设置是将一个Dispatcher用作负载平衡器,并在两个或更多Publish系统之前进行缓存。 Dispatcher核心的Apache Server非常稳定,在大多数设置下,足以满足大量请求。
“旧版”Dispatcher设置 — 按当前的标准来看不太常见
这是Dispatcher从中收到其名称的位置:它基本上是在调度请求。 这种设置已不再很常见,因为它无法满足当今对性能和稳定性的更高要求。
多足安装
如今,稍有不同的拓扑结构更为常见。 多足拓扑在每台Publish服务器上有一个Dispatcher。 专用(硬件)负载平衡器位于AEM基础架构的前面,将请求调度到两个(或更多)分支:
现代“标准”Dispatcher设置 — 易于处理和维护
以下是这种设置的原因,
-
网站平均提供的流量比过去多得多。 因此,需要扩展“Apache基础架构”。
-
“旧版”设置未在Dispatcher级别提供冗余。 如果Apache Server出现故障,则无法访问整个网站。
-
Apache服务器价格低廉。 它们基于开放源代码,而且如果您拥有虚拟数据中心,则可以快速配置它们。
-
此设置提供了一种用于“滚动”或“交错”更新方案的简单方法。 只需在Dispatcher 1上安装新软件包时关闭Publish 1即可。 安装完成后,如果内部网络中的Publish 1已充分烟雾测试,那么应清理Dispatcher 1上的缓存,然后重新启动,同时关闭Dispatcher 2以维护Publish 2。
-
在此设置中,缓存失效变得非常轻松且具有确定性。 由于只有一个Publish系统连接到一个Dispatcher,因此只有一个Dispatcher可失效。 失效的顺序和时机微不足道。
“扩展”设置
Apache Server价格低廉且易于配置,何不进一步将扩展范围扩展到这一级别。 为何每个Publish服务器前面没有两个或更多Dispatcher?
“扩展”设置 — 有一些应用领域,但也有一些限制和注意事项
你绝对可以这样做! 对于这种设置,有许多有效的应用方案。 但是,您还应考虑一些限制和复杂性。
失效
每个Publish系统都连接到多个Dispatcher,每个系统都必须在内容发生更改时失效。
维护
毋庸置疑,Dispatcher和Publish系统的初始配置要复杂一些。 但请记住,推出“滚动”版本的工作量也要高一些。 AEM系统在运行时可以而且必须更新。 但是,明智的做法是在他们积极为请求提供服务时不要这样做。 通常,您只想更新部分Publish系统,而其他系统仍主动提供流量,然后在测试后,切换到其他部分。 如果您很幸运,并且在部署过程中可以访问负载平衡器,则可以在此处禁用到维护中服务器的路由。 如果您位于没有直接访问权限的共享负载平衡器上,则希望关闭要更新的Publish的调度程序。 那里越多,你就越需要关门。 如果数量很大并且您计划频繁更新,建议采取一些自动化操作。 如果你没有自动化工具,扩大规模无论如何都是个坏主意。
在过去的项目中,我们使用另一种技巧将Publish系统从负载平衡中删除,而无需直接访问负载平衡器本身。
负载平衡器通常会“ping”,即用于查看服务器是否已启动并正在运行的特定页面。 一个简单的选择通常是ping主页。 但是,如果要使用ping命令指示负载平衡器不要平衡流量,则应当选择其他方法。 您可以创建一个专用模板或servlet,将其配置为使用"up"
或"down"
进行响应(在正文中或作为http响应代码)。 该页面的响应当然不能缓存在Dispatcher中,因此始终是从Publish系统中最新获取的。 现在,如果您配置负载平衡器以检查此模板或servlet,则可以轻松地让Publish“假定”它停止运行。 它不是负载平衡的一部分,可以更新。
全球分布
“全球分发”是一个“扩展”设置,您在每个Publish系统前面有多个Dispatcher — 现在分布在世界各地,以更接近客户并提供更好的性能。 当然,在这种情况下,您没有中心负载平衡器,而是具有基于DNS和地理IP的负载平衡方案。
水平缩放
即使在本地数据中心中,在每个Publish系统前面有多个Dispatcher的“横向扩展”拓扑也有一些优势。 如果由于高流量(以及良好的缓存命中率)而导致Apache Server出现性能瓶颈,并且您无法再扩展硬件(通过添加CPU、RAM和更快的磁盘),则可以通过添加Dispatcher来提高性能。 这称为“水平缩放”。 但是,这有限制,尤其是当您经常使流量失效时。 我们将在下一节中描述这种影响。
横向扩展拓扑的限制
添加代理服务器通常会提高性能。 但是,在某些情况下,添加服务器实际上会降低性能。 如何进行? 假设您有一个新闻门户,在那里您每分钟都会介绍新文章和页面。 Dispatcher通过“自动失效”而失效:每当发布页面时,同一站点上的缓存中的所有页面都会失效。 这是一个有用的功能 — 我们在本系列的第1章中介绍了此功能 — 但它也意味着,当您的网站上有频繁的更改时,您经常会使缓存失效。 如果每个Publish实例只有一个Dispatcher,则第一个请求页面的访客会触发该页面的重新缓存。 第二个访客已获取缓存版本。
如果您有两个Dispatcher,则第二个访客有50%的可能性不会缓存页面,然后再次呈现该页面时,他会遇到更大的延迟。 每个Publish拥有更多调度程序会让情况变得更糟。 具体情况是,Publish服务器会收到更多负载,因为它必须分别重新渲染每个Dispatcher的页面。
在缓存刷新频繁的横向扩展方案中性能降低。
缓解过度扩展问题
您可以考虑为所有Dispatcher使用中央共享存储,或者同步Apache服务器的文件系统以缓解这些问题。 我们只能提供有限的第一手经验,但应做好准备,这增加了系统的复杂性,并可能会引入全新的错误类别。
我们对NFS进行了一些实验,但NFS由于内容锁定而带来了巨大的性能问题。 这实际上降低了总体性能。
结论 — 不建议在多个调度程序之间共享公共文件系统。
如果您遇到性能问题,请等量扩展Publish和Dispatcher以避免发布器实例上的峰值负载。 Publish/Dispatcher比率没有黄金规则,它高度取决于请求的分布以及发布和缓存失效的频率。
如果您还担心访客体验的延迟,请考虑使用内容交付网络、缓存重新获取、抢先缓存预热、设置宽限时间(如本系列的第1章所述)或参阅第3部分的一些高级想法。
“交叉连接”设置
我们偶尔会看到另一种设置,即“交叉连接”设置:Publish实例没有专用的Dispatcher,但所有Dispatcher都已连接到所有Publish系统。
交叉连接拓扑:冗余增加,复杂性增加。
乍一看,这为相对较小的预算提供了更多的冗余。 当其中一个Apache服务器关闭时,您仍然可以使用两个Publish系统来执行渲染工作。 此外,如果其中一个Publish系统崩溃,您还有两个Dispatcher提供缓存的负载。
但这是有代价的。
首先,取一条腿进行维修相当麻烦。 实际上,这就是这个方案的目的;为了更有弹性,尽可能保持正常运行。 我们已经看到了复杂的维护计划如何处理这种情况。 首先重新配置Dispatcher 2,删除交叉连接。 重新启动Dispatcher 2。 正在关闭Dispatcher 1,更新Publish 1, …等等。 如果能扩展到两条腿以上,您应该仔细考虑。 你会得出这样的结论:它实际上增加了复杂性,增加了成本,并且是造成人为错误的强大根源。 最好将此自动化。 所以,最好检查一下,如果您确实有人力资源将此自动化任务纳入您的项目计划中。 虽然这样做可能会节省一些硬件成本,但您可能会在IT员工上花费双倍的成本。
其次,您可能在AEM上运行了一些需要登录的用户应用程序。 您可以使用粘性会话,确保始终从同一AEM实例提供一个用户,以便您可以维护该实例上的会话状态。 进行这种交叉连接设置时,您必须确保粘性会话在负载平衡器和Dispatcher上正常运行。 并非不可能,但您需要了解这一点,并添加一些额外的配置和测试时间,这同样可能会使您通过节省硬件而节省成本。
结论
我们不建议您将此交叉连接方案用作默认选项。 但是,如果您决定使用它,则需要仔细评估风险和隐藏成本,并计划将配置自动化作为项目的一部分包括在内。