一文看懂静态资源服务沉浮及其在携程的演进( 三 ) _静态资源服务

虽然 Akamai 系统传输的内容很快就从“Web 对象”——也就是图片和文本—— ，拓展到了动态内容和流媒体，但是时至今日，静态资源仍然是体现 CDN 优势的最佳标本，而大多数商业化 CDN 也依然因循边缘缓存（Edge Caching）的思路来处理针对静态资源的请求。

文章插图

图片引自 Globally Distributed Content Delivery
通常，网站租用 CDN 服务后，供应商会为其分配一个自己名下的专用子域名，由网站管理员自行将该专用子域名设置为网站域名的别名（CNAME）。这意味着由 CDN 供应商指定的——通常是其自有的——域名解析服务（ DNS）将接管针对网站域名的解析请求，选择距离较近的边缘服务器，将其 IP 地址返回给发起解析请求的一方，也就是终端用户所使用的本地 DNS 服务器，再由其反馈给终端用户。经过这样一番操作之后，用户浏览器上发出的访问请求，就将被发送到相应的边缘服务器（Edge Server）并由其进行响应。这是通过 CDN 实现就近访问的基本原理。
这种技术客观上达到了在广域网络上由多个服务分担流量的效果，因此术语也称之为全球服务负载均衡（Global ServerLoad Balance），简称 GSLB 。
边缘服务器如果发现可用的缓存，则直接以缓存的内容响应，称为“命中”（hit）缓存，或“卸载”（offload）流量；否则，请求将在 CDN 内部上行（upstream），直到命中合适的缓存或抵达内容网站自有的服务器，由其进行响应，称为“回源”（back-to-origin）。源服务器（Origin ，也称源站）处理完回源请求后，其响应将循原路返回，途中， CDN 各级节点将按照约定的方式对其进行缓存，以备下次使用。这是 CDN 执行响应的基本流程。
在这个机制下，作为内容提供商的源站通常处在一个被动的位置。有时，我们也需要主动通知边缘服务器，提前创建或者删除缓存，这两种操作，分别称为“预取”（prefecth）及“清理”（purge）。

文章插图

边缘缓存的技术路线，决定了这是一个规模致胜、易守难攻的领域。现在，除了传统的专业厂商之外，从国外的 AWS、Azure ，到国内的阿里云、腾讯云，几乎所有重量级的公有云服务供应商都提供 CDN 服务，这是它们在自身庞大的规模基础上顺势而为的选择；而众多的电讯运营商也纷纷凭借其基础设施的便利，亲自上阵，提供地区性乃至洲际的 CDN 服务，统称为 Telco CDN 。这些新兴厂商的涌现，的确给志在八方的互联网企业提供了更多的选择。除了绝对的规模之外，地理分布的广泛性是决定 CDN 服务质量的另一要素，而这正是传统厂商长期深耕之处。已在全球拥有1,500+网络节点的 Akamai 依然是行业的佼佼者，也是携程在全球化进程中的技术合作伙伴。
在上一节的末尾曾提到反向代理。对于代理（Proxy），我们都不陌生。浏览器的学名是用户代理（当然严格来说 Agent 和 Proxy 是有一定区别的），家用无线路由器也是代理，大家喜闻乐见的 Shadowsocks 则是一种基于 Socket 的代理，它们所代表的都是客户端。那么反向代理，顾名思义，就是代表服务端的代理。Nginx 充当负载均衡设备时，扮演的就是反向代理的角色。
现在我们知道， CDN 也是一种反向代理。对于静态资源服务来说，它的地位无可取代。
三、破“窗”之役有了 CDN 的加持，静态资源站点就不再是一般的网站，叫做“源站”（Origin）。这一节，说的是源站的事儿。
曾经，携程的静态资源服务是按1+n模式部署的，即一个负载均衡设备（Load Balancer），挂载若干台服务器。负载均衡设备可能是NetScaler ，也可能是 F5 ，而服务器是 Windows 操作系统的，上面运行着 IIS ，所有进入的 HTTP 请求被直接映射到服务器的本地文件系统。