门户背后的核心 Web 应用程序是用 JavaScript 编写的。它是在 Microsoft Azure 中运行的 Node.js 应用程序。该应用程序通过向 Delivery API 发出 API 请求从 Kontent.ai 获取内容。这样，内容创建者就可以管理 Web 应用程序显示的大部分内容。
内容创作者在 Kontent.ai 中写作，他们的内容经过几道工序后，我们的客户就可以阅读它。
在早期阶段，我们的首要任务是上市时间。我们确保可以轻松添加新内容，使其易于查找，并且任何人都可以轻松阅读。性能紧随其后。后来我们意识到有些事情并不像我们想象的那样可预测。比如页面加载时间，用户体验的死对头。
如果获取需要时间，则缓存
回想起来，这听起来很明显，但我们开始时没有使用任何缓存。为什么要费心呢？交付 API会为您缓存成功的响应。您只想获取内容。问题是，即使是 API 端的缓存响应也可能无法立即实现。当您一次反复获取多个响应时，情况并非如此。
网络开销成本
该 Web 应用需要发出大约六个 API 请求才能构建单个页面。例如，它需要获取导航、页脚、UI 消息、站点范围重定向和文章内容的项目。根据请求的复杂程度，API 的首次响应可能需要 100 毫秒（对于简单的单项查询）到 1000 毫秒（对于复杂的多项查询）的时间。
首次请求与重复请求的总体响应时间对比
重复这些 API 请求大约需要 50 毫秒。但是，Web 应用本身可能需要等待更长时间。每个请求总会有轻微的网络开销。这些数字加起来会很大。即使有六个快速 API 请求，您最终也可能需要等待大约 0.5 秒。
这看起来似乎不多，但请记住，在浏览器中显示内容 也需要时间。这有时被称为渲染时间或交互时间。总的来说，增加的延迟会导致可以忍受但低于标准的体验。
优化还是不优化？
开发人员该怎么做？我们面临两个选择。
重写现有逻辑，以便 Web 应用程序需要更少的 API 请求来构建页面。
在保持现有逻辑不变的情况下，总体上减少 API 请求。
人们说过早优化是万恶之源。为了避免这种恶果，我们选择改进现有系统，而不是将其拆开。
我们决定通过缓存每个请求的 API 响应来减少 API 请求。如果 Web 应用需要某部分内容来构建页面，它只需查看自己的内存即可。无需网络请求。
缓存的好处和坏处
Web 应用程序会根据需要缓存 Delivery API 的响应。 山东省手机号码列表 如果内容创建者在 Kontent.ai 中做出更改，Web 应用程序会使其缓存中的某些响应失效并获取新内容。但 Web 应用程序如何知道要使哪些缓存响应失效？
缓存失效很有趣。它让你做出选择。例如：
像一些静态站点生成器一样重建整个站点。
重建站点的特定部分。
每隔几分钟定期重建。
仅当发生变化时才重建。
您的选择取决于您是想让自己轻松还是让内容创作者轻松。我们将内容创作者的创作体验放在首位。毕竟，我们正在为内容创作者构建整个系统。这些人希望在发布后不久就能看到他们的内容上线。
当网站发生变化时，我们会重建网站的特定部分。这意味着对 webhook 做出反应。长话短说，内容模型越结构化，验证缓存失效是否按预期工作就越有趣。
如果机器人让你瘫痪，那就躲在 CDN 后面
添加基本的缓存机制有助于提高整体性能。Web 应用程序缓存了 API 响应，因此每次只有一个唯一的 API 请求。但页面仍然会为每个请求重新构建。虽然页面构建发生在一瞬间，但每次都会给 Web 应用程序带来负担，而且无法扩展。
按照现代标准，即使是一次微小的拒绝服务 (DoS) 攻击也可能使我们的 Web 应用程序停止运行。我们说的是五分钟内有 10,000 个请求。没有什么大不了的。不过，这足以导致短暂的停机。
为了弥补这种保护不足，我们将 Web 应用程序隐藏在Fastly提供的内容交付网络 (CDN) 后面。每个请求在到达 Web 应用程序之前都要经过 CDN。虽然 CDN 增加了一层复杂性（更多内容见下文），但它也是一层保护，让您可以轻松扩展。
内容分发网络 (CDN) 是您的 Web 应用程序的第一道防线。
虽然 CDN 可能不是万能的灵丹妙药，但它可以确保您的 Web 应用只了解唯一请求。如果重复请求，CDN 会缓存第一次的响应并返回缓存的响应。Web 应用的工作量减少，访问者的速度更快。
如果缓存使用不足，请调查
有了 CDN，情况就稳定多了。为了以防万一，我们查看了前几周的 CDN 日志，发现响应时间并不稳定。原来 CDN 不允许某些页面进入其缓存。这意味着我们的缓存命中率波动且不可预测。是时候调查了。
让合适的人进来
解决问题的关键在于提出正确的问题。这里的问题是“什么样的响应可以进入 CDN 的缓存”？答案是什么？所有访问者看到的响应都一样。这是一个需要理解的关键概念。它促使我们查看来自 Web 应用程序的响应及其标头，并发现了一个错误。
当访问者阅读 Kontent.ai Learn 上的技术文章时，他们可以选择是否要查看 JavaScript、.NET 或我们涵盖的其他技术的内容和代码示例。访问者对技术的选择存储在浏览器 cookie 中。效果惊人。
这就是您在 Kontent.ai Learn 中选择首选编程语言的方法。亲自看看吧。
问题是，如果您（在不知情的情况下反复）在每次访问页面时设置 cookie。每当设置 cookie 时，来自 Web 应用程序的响应都会返回set-cookie标头。这会导致响应无法缓存。
如果响应设置了 cookie，则它们无法进入缓存。否则，CDN 会将该响应提供给所有人，而每个人都会获得相同的 cookie 集。这会在多个层面上造成问题。CDN 很聪明，不会允许这种情况发生。
谨慎使用缓存策略
另一件必须聪明的事情是缓存策略和失效。我们有四个级别的缓存可供使用。
交付 API——缓存成功的 API 请求。
Web 应用程序 – 缓存来自 Delivery API 的响应。
CDN——缓存来自 Web 应用程序的响应。
浏览器——缓存来自 CDN 的响应。
通过这四个，我们可以控制 Web 应用和 CDN 的行为。但没有必要在两个级别上执行不同的操作。我们决定将主缓存配置保留在 Web 应用中。这样更容易管理。
我们进行了一些尝试和错误，遵循了HTTP 缓存的最佳实践，并检查了更改是否产生了我们想要的差异。这是一次形成性的经历，它促使我们探索这个cache-control兔子洞有多深。例如，您是否知道可以为 CDN 和浏览器本身设置不同的缓存策略？只需了解该标头的指令即可。
通过这次练习，我们能够满足我们的核心要求：快速有效地向每个访问者提供最新的内容更改。
不同层缓存的简化视图。
我们确保 Web 应用程序中的内容在不同位置存储不同的时间：
在 Web 应用中，内容会一直保存，直到 Webhook 提示删除。时间一到，Web 应用还会确保内容从 CDN 中消失。
在 CDN 中，内容最多可保存一周。但只有热门内容才能保留这么长时间，因为 CDN 试图提高效率。如果 CDN 发现没有任何需求，它可能会从缓存中删除内容。
在浏览器中，内容会存储几分钟。然后浏览器应该再次与 CDN 进行检查。
下一步是什么？
完成性能测量和不可见细节优化后，我们开始向项目添加更多内容并扩展门户。我们添加了电子学习课程、REST API 的 API 文档、代码示例。所有这些都集中在一个叫做 Kontent.ai 的地方。到目前为止，这种内容整合意味着我们可以轻松找到所需内容，重复使用并快速进行更改。你也可以这样做。
