加快云中的 web 内容交付

使用 Akamai 平台提高速度和可靠性

基于浏览器的软件即服务 (SaaS) 应用程序让公司可以快速轻松地连接世界各地的用户。但是,是否能够一致、可靠且高性能地交付这些应用程序是决定成败的关键因素。本系列讨论在 IBM Cloud 中构建多租用者应用程序的最佳实践。在本系列的第三篇文章中,作者要讨论 web 应用程序性能。他们介绍一个通过集成 SaaS 平台和 Akamai 全球边缘交付平台实现可靠的 web 内容交付的解决方案。

Christina Lau, 杰出工程师, IBM

作者照片Christina Lau 是一名杰出的工程师,领导着 WebSphere 的 BPM Architecture and Advanced Technology Team,重点关注新兴技术。您可以访问她在 BPM Experience 上的博客。


developerWorks 投稿作者

Valentina Birsan, 资深开发人员, IBM

http://www.ibm.com/developerworks/i/p-vbirsan.jpgValentina Birsan 是 WebSphere 的资深开发人员,当前主要关注云项目。Valentina 以前是 Rational Application Developer 的技术负责人。Valentina 是 Eclipse TPTP 开放源码项目最初的成员之一,担任 TPTP Architecture Group 的主席。她曾是 Cosmos Service Modeling Eclipse 开放源码项目的首席架构师和 SML 开放标准的成员。



2011 年 6 月 07 日

web 应用程序性能问题的根源可以划分为两类:

  • 应用程序本身的性能差。应用程序开发人员通过性能调优和纠正代码通常可以解决这类问题。
  • 由于 Internet 的问题,导致应用程序的性能差。由于 Internet 基础设施是不可预测的,这类问题常常超出了任何单一公司的控制范围。

无论应用程序性能差是由于内部原因还是外部原因造成的,缓慢的响应速度都会影响用户,导致应用程序的用户量和用户满意度降低。

图 1. Internet 是由许多网络组成的复杂多路径网络
由许多网络组成的复杂多路径网络的示意图

图 1 说明 Internet 并不是单一网络,而是通过对等点连接起来的超过 12,000 个网络。从数据中心到用户的路径可能要经过多个网络和对等点。在很多时候,路径可能很拥挤,可能出现事故、自然灾难或业务冲突,这些都会导致传输延迟。

Internet 对等(peering)

对等是指在管理上独立的 Internet 网络自愿地相互连接,从而交换每个网络的客户之间的通信流。对等的简单定义是无结算 - — 这意味着双方都不需要为交换通信流向对方付费,每个网络从自己的客户那里取得收入。

改进性能低下的 web 应用程序的方法之一是,通过增加服务器、带宽甚至数据中心来分担负载,从而扩展容量。但是,这种方法并不是经济有效的,也不能完全解决不可预测的 Internet 性能问题。另外,使用更多的基础设施意味着在通信量低时可能供应过度,而在通信量非常高时仍然可能会遇到瓶颈。

本文介绍一种使用 Akamai 的 EdgePlatform 的最佳实践。Akamai 的 EdgePlatform 是一个包含超过 70,000 台服务器的大型网络,服务器部署在 70 个国家和超过 1000 个网络中,用于实时地监视 Internet,收集关于通信流、拥挤和故障点的信息,从而消除长的路由并避开故障点,确保快速、可靠地交付 web 内容。

最佳实践:用 Akamai Web Application Accelerator 交付动态的 web 内容

为了帮助解决 Internet 上的拥挤和弱点问题,Akamai 开发了 Akamai EdgePlatform,它提供的产品用于在各种场景中克服 Internet 在交付 web 站点、内容和应用程序方面的缺点。具体地说,我们要使用 Akamai Web Application Accelerator,它可以通过以下措施加快动态 web 内容的交付:

  • 避免 Internet 通信流拥挤:由于 Internet 通信流不稳定,起源服务器与 Akamai 边缘服务器之间的直接路由可能很拥挤。通过使用 SureRoute for Performance,可以找到更好的替代路由,从而克服这个问题。
  • 优化 TCP 配置:Akamai 能够优化 TCP 连接窗口、调整 TCP 超时并尽可能使用持久连接,从而尽可能提高 Akamai 边缘服务器与起源服务器之间的吞吐量。
  • 缓存内容:大多数静态内容都可以缓存,比如图像、视频和 zip 文件。通过把这些对象缓存在更接近最终用户的边缘服务器上,Akamai 可以减少从起源服务器获取静态内容所需的往返次数。
  • 预抓取内容:Akamai 提供智能化的预抓取功能,这让它可以以尽可能快的响应速度向最终用户交付 HTML 页面中嵌入的所有内容。当最终用户的浏览器请求嵌入的内容时,内容已经在附近的边缘服务器的内存中了,因为 Akamai 已经略早于实际浏览器请求请求了这些内容。
  • 加快传输内容的速度:Akamai 可以使用 gzip 压缩边缘服务器上的内容,然后再把内容发送给客户机。这会减少传输内容花费的时间。大于 10KB 的对象可以受益于 Last Mile Acceleration。

Web Application Accelerator 的设计由两个主要任务组成:

  1. 通过配置系统,让它能够识别边缘服务器。
  2. 设计可应用于您的 SaaS 应用程序的缓存规则和策略。

任务 1:通过配置识别边缘服务器

第一个任务是配置您的系统,让它能够识别 Akamai 边缘服务器。图 2 给出总体架构。

图 2. 通过配置系统让它能够识别边缘服务器
通过配置系统让它能够识别边缘服务器

当用户请求一个对象时,请求先被转到 Akamai 边缘服务器。如果在边缘服务器上有此内容,就从缓存取出内容并返回给用户。如果没有此内容,Akamai 会向起源服务器(即我们的数据中心)请求内容,然后把内容缓存在 Akamai 边缘服务器网络中并返回给用户。

为了完成这个任务,主题问题专家可以与 Akamai 专家一起设置系统,主题问题专家了解您的系统拓扑,比如 Akamai 要访问的服务器的 IP 地址和主机名、应用程序的 URL、它是否安全、域名等等。


任务 2:设计缓存规则

第二个任务是设计可应用于您的 SaaS 应用程序的缓存规则和策略。为了完成这个任务,需要了解网站的内容:目录结构、内容的类型以及生成内容的方式。本节讨论一些缓存主题。

基于文件扩展名和路径的缓存规则

最简单的缓存规则基于标准的文件扩展名。在默认情况下,会自动地缓存具有以下扩展名的文件:

aif aiff au avi bin bmp cab carb cct cdf class css doc dcr dtd
exeflv gcf gff gif grv hdml hqx ico ini jpeg jpg js mov mp3 nc pct
pdfpng ppc pws swa swf txt vbs w32 wav wbmp wml wmlc wmls
wmlsc xsd zip

这假设这些文本、图像、电子表格、音频文件都可以缓存,因为它们是静态的;把它们放在边缘服务器缓存中可以提高性能。默认的缓存时间是一天。尤其是对于大量使用 JavaScript 的富 Internet 应用程序,Akamai 可以缓存大量对象,这会显著提高总体性能。

可以根据应用程序的需求在这个列表中轻松地添加或删除文件扩展名。例如,某个文件路径中的 HTML 或 XML 文件(比如 /doc/*.html)可能也是静态的,因此也可以缓存。

还可以根据请求参数或其他应用程序元数据定义缓存动态内容的缓存规则。通常,只使用资源的 URL 作为缓存键可能不够。需要加上一些额外的 cookie,形成复合的缓存键。可以使用 cookie 识别特定的租用者或租用者的用户。这让边缘服务器能够维护针对特定用户/租用者的内容拷贝,可以从缓存交付正确的拷贝。这是一个比较高级的特性,需要仔细地设计和测试。

测试缓存规则的工具和技术

为了确保定义的缓存规则符合预期,可以使用 Fiddler 等 HTTP 调试工具作为透明的代理,这样就可以看到自己发出的每个请求并通过检查响应看出缓存是否正常。

一般的方法是,请求一个可缓存的对象,然后使用 Fiddler 的 Session Inspector 查看请求中的头。还需要在 Fiddler 中添加一个规则,让它能够识别请求中 Akamai 特有的 Pragma 头(比如 X-Check-Cacheable、X-Cache)。

第一次请求可缓存的对象

例如,我们的缓存规则之一指出会缓存 JavaScript。因此,我们可以请求 test.js 文件。因为这是第一次发出这个请求,应该会在 Response Headers 面板中看到以下属性:

X-Check-Cacheable: YES
X-Cache: TCP_MISS from a96-17-171-7 (AkamaiGHost/6.3.0-7086845)

第一个属性证实确实会缓存扩展名为 .js 的 JavaScript 文件。第二个属性表明,尽管 test.js 文件是可缓存的,但是在 Akamai 缓存中没有找到它,所以要从我们的数据中心交付它。

第二次请求可缓存的对象

现在,再次请求相同的 test.js 文件。因为这是第二次请求相同的对象,应该会在 Response Headers 面板中看到以下属性:

X-Cache: TCP_HIT from a96-17-171-7 (AkamaiGHost/6.3.0-7086845)

TCP_HIT 值表明 Akamai 边缘服务器从缓存中返回此文件,并不需要通过访问我们的数据中心获取相同的文件。

什么是缓存中毒?

边缘服务器缓存中毒 是指向缓存提供了数据,但是数据不表示缓存的资源。因为边缘服务器缓存的资源要在下一次请求时返回,一定要确保缓存的数据表示资源的正确内容。

下面的场景可能会用无效的数据 “毒害” 边缘服务器缓存。

假设最终用户还没有经过身份验证,但是他请求一个受保护的资源,比如 foo.gif。再假设缓存中还没有 foo.gif。Akamai 边缘服务器向我们的数据中心发送请求。

我们在后端应用服务器前面安置了一台 WebSeal 服务器。当还没有经过身份验证(或者身份验证会话已经过期)的用户请求受保护的资源时,最初的请求不会到达后端服务器。WebSeal 服务器返回一个 HTML 登录页面(让用户能够登录)和 HTTP 响应码 200,而不是返回请求的资源。

Akamai 现在收到登录页面。因为响应码是 200,Akamai 会认为请求成功了,所以把这个响应保存在缓存中。Akamai 缓存现在包含错误的对象,已经中毒了。当用户下一次请求 foo.gif 时,会从 Akamai 缓存返回登录页面。

防止 Akamai 缓存中毒的最佳实践

防止缓存中毒有两种方法:

  • 在响应头中正确地标识服务器。
  • 确保应用程序返回正确的状态码。

在响应头中正确地标识服务器。定义一种并不缓存从执行请求转发的 WebSeal 反向代理服务器直接提供的任何数据的配置,这样就可以避免以上情况。

Akamai 软件可以通过查看响应头中的 Server 属性检查服务器的类型。例如,如果响应来自 WebSeal 反向代理服务器,服务器头的值是 Server: WebSEAL/6.1.0.0。如果响应来自后端应用服务器之一,比如 WebSphere sMash,服务器头的值是 Server: IBM WebSphere sMash/1.1.1

确保应用程序返回正确的状态码。应用程序不发送正确的状态码看似没什么害处,但是在启用边缘服务器时这会成为真正的问题。只有在请求确实成功了而且返回的数据就是期望的数据的情况下,才应该发送回 HTTP 响应码 200,必须确保这一点。如果响应码是 200,边缘服务器会自动地缓存所有可缓存的内容。

一般来说,应该实现 HTTP 状态码并为自己的 web 解决方案创建针对特定应用程序的错误页面。

清除缓存

有时候,有必要提前刷新 Akamai 边缘服务器缓存的内容,而不是等到边缘服务器配置中指定的过期时间。例如,可能需要快速修复 JavaScript 中的错误或者更新现有的图像,或者希望把整个应用程序更新为新版本。

Akamai 提供一个灵活的 Content Control 实用程序,可以使用它执行这个任务。只需进入 Akamai Edge Control portal,使用这个面板指定希望刷新的 URL。刷新内容之后,Akamai 会通过电子邮件通知您。还可以使用它们的 SOAP API 通过程序刷新内容。


结束语

本文讨论了我们在集成 Akamai 与在 IBM Cloud 中运行的应用程序时学到的经验。通过启用 Akamai 缓存,我们把性能提高了超过 50%。

尽管本文主要讨论通过缓存带来的性能改进,但是我们还利用 Akamai 提供的其他功能为 SaaS 应用程序实现了故障转移和负载分布。这是一个独特的特性,因为云提供商可能不支持用于负载平衡的专门硬件。故障转移和负载分布集成提高了我们的 SaaS 应用程序的总体可用性和性能。我们将在以后的文章中讨论这个主题。


致谢

我们的团队与 Akamai 团队的合作很愉快。他们不仅经验丰富,而且善于与人合作。作者要感谢 Akamai 的 Patrick Boucher 以及 IBM 的 Tom Mikalsen 和 Bhadri Madapusi 对本文提供的帮助。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing
ArticleID=678556
ArticleTitle=加快云中的 web 内容交付
publish-date=06072011