Jason Smith 曾作为 Sun 硬件和软件工程师在 WorldCom 工作，通过构建和配置企业级解决方案，帮助将点号放入 .com 中。之后，他前往 AAAS（美国科学促进会，《科学》杂志的出版商），负责教育理事会的技术需求。
Jason 构建或架构了从企业级到小型企业级的各种解决方案，并发现 Drupal 是一个灵活、可扩展、快速开发的框架，适用于各种级别的项目。作为开源运动的长期受益者，Jason 现在是 天气公司 的高级软件架构师，他热衷于支持开源项目，并坚信要回馈支持他的社区。
我猜想，更活跃的搜索，例如在桑迪飓风期间搜索纽约，会比在桑迪飓风期间搜索爱达荷州的一个安静小镇产生更高的工作负载。这造成了什么问题？您是如何处理工作负载平衡的？
我们在构建网站时充分利用了中间缓存和边缘缓存。缓存的使用以一种微妙的方式改变了流量管理的整个动态。由于页面可以缓存相当长的时间，无论我们收到多少内容请求，最终到达源站的请求都很少。
缓存并不能完全解决我们的问题，它只是转移了我们的关注点。没有单个资源的请求频率会超过我们的 TTL（生存时间）所描述的，但是如果在一个时间段内请求了一百万个资源，那么每个资源都会到达源站。您可以增加 TTL，但您最终会达到内容和营销团队设定的上限。
我们有数百万个地点需要支持天气预报页面，但页面之间的差异仅在于特定于地点的实际预报数据。因此，部分策略是提高页面的可缓存性（增加 TTL），另一部分是利用客户端资源来构建特定于用户/地点的页面，而不是调用源站。
您是如何利用不同的缓存层来扩展 Drupal 的？
高 TTL 的一个挑战是，在需要快速发布内容时。在某些情况下，刷新 Akamai 缓存（按 URL）可能需要长达一个小时，这会让编辑团队感到非常焦虑。显然，高 TTL 不可能是唯一的解决方案。
Varnish 缓存可以更快地清除，因为它们（通常）更靠近您，数量更少，并且您可以更好地控制它们。您在管理缓存生命周期方面获得的灵活性，会在分布式缓存方面有所损失。因此，我们找到了一种双赢的方法。
诀窍是使用多层缓存，在我们的例子中是同时使用 Akamai 和 Varnish。在这种设置中，我们可以将 Akamai 缓存 TTL 设置得相对较低（约 1-5 分钟），并将 Varnish TTL 设置得更高。由于 Varnish 缓存清除简单且在我们控制之下，因此我们获得了分布式 CDN 的所有优势，并且能够更接近源站地管理缓存陈旧性。
您是如何管理内容生成和工作流程的？（例如，从作者到在生产环境中发布内容）
天气频道编辑团队坚决要求尽可能减少内容开发的障碍。为此，只有两种“工作流程”状态：已发布和未发布。编辑计划和工作流程被视为一项独立于内容输入和发布的任务进行管理。内容更改的预览以及在开发环境中暂存内容一直是一个挑战，但它不会阻碍完成工作的能力。
开发开始后是否遇到任何意外的障碍？您是如何克服它们的？
总会有意想不到的障碍，但我们对此做了一定程度的计划。在我们的案例中，最大的障碍与媒体管理有关。最初，我们计划将其视为由不同平台解决的问题。但后来，平衡时间表和所需的集成级别变得越来越困难，因此基础 Drupal 平台承担了大量的媒体管理责任。
当您考虑企业组织的需求时，媒体管理是一项巨大的工作：您必须管理内容共享、去重、过期、翻译、短期/长期存储、CDN 和 DRM（以及执行），以及许多其他具有挑战性和棘手的问题。
持续集成：您是如何发布新功能的？
我们在持续集成方面取得了一些令人印象深刻的进展，但在 Drupal 中，我们遇到了许多活跃的并行开发团队的需求所带来的相同障碍。由于模块、页面和行为排列的数量庞大，我们的测试/回归套件非常庞大且笨重。我们还面临着各个插件/模块不够独立的问题，无法独立部署（或回滚），或者隔离性不够，无法避免需要进行完整的回归测试。目前我的重点在项目的其他方面，但 QA（质量保证）团队非常有能力，并且正在探索多种方案来缩小差距。
演讲者访谈
本文是 DrupalCon 2015 演讲者访谈系列 的一部分。DrupalCon 2015 汇集了来自全球各地数千名使用、开发、设计和支持 Drupal 平台的人员。大会于 2015 年 5 月 11 日至 15 日在加利福尼亚州洛杉矶举行。.
评论已关闭。