浏览型网站静态化架构设计.docx

浏览型网站静态化架构设计在天猫双11活动中，商品详情、店铺等浏览型系统，通常会承受超出日常数倍甚至数十倍的流量冲击。随着历年来双11流量的大幅增加，每年这些浏览型系统都要面临容量评估、硬件扩容、性能优化等各类技术挑战。因此，架构方面的重点在于，如何能够利用合理成本应对瞬间飙高的峰值请求，并确保活动完整周期中系统容量的可伸缩性、用户响应时间的稳定性，以及外部依赖系统出现问题时的高可用性。此外，作为最主要的页面流量承载体系，架构方面还需考虑防爬攻击、流控容灾等安全、稳定的需求，并综合衡量网络带宽、硬件成本、缓存效率等各方面要素，找准平衡点，从而达到以不变应万变的理想效果。架构演进为此，自2011年起，以天猫商品详情系统为代表，天猫浏览型系统在架构上的主要工作之一就是通过静态化技术实现了动静态信息分离、利用缓存技术存放静态化内容、利用少量动态数据异步加载填充。整个过程历经单机静态化、统一缓存接入，到2013年双11前彻底CDN化三个阶段（如图1所示），有效解决了缓存命中率、流量自然分布、系统扩容简化、用户端响应速度等关键问题。图1 ?CDN化的三个阶段目前，天猫浏览型系统最新使用的这套基于CDN的静态化架构，可以满足高可用持续伸缩的原始预期，并包含如下特性。动静分离：HTML静态化和热点分离。分布式缓存体系：利用CDN节点分布式缓存。多级缓存机制：CDN两级+应用一级。统一服务静态化集群。一致性维持：主动失效&自动失效缓存机制。动态内容填充：能支持多种时效性动态内容填充方式。控预警机制：流量、失效、命中率等关键参数实时监控报警。本文将针对这一优化历程，就主要技术挑战、架构改造策略、最终优化成果做一个总览式的介绍，并重点对CDN化过程中整体架构的演进、缓存失效机制、动态内容填充等具体要点进行论述。第一阶段：系统静态化早期天猫浏览型系统大多采用简单架构，实现一层很薄的前台应用。以天猫商品详情系统为例，针对商品、用户等访问量较大的数据中心接口模式改造为应用 Client端缓存前置，同时普遍使用页面高速缓存（PageCache）来降低后端系统压力。使得整体可支持应用水平扩展不受限制。这一阶段系统面临的 主要问题和挑战包括以下几点。应用服务器瓶颈，页面渲染带来的CPU开销巨大。单纯基于Java端的缓存已基本覆盖，整体性能提升空间有限。水平扩容只能支持容量线性提升，难以满足大促井喷式流量增长，扩容成本高。从问题看，基于原有动态浏览型系统模式而优化的瓶颈很难规避，例如以下几点。Java应用服务器端必要开销，包括：涉及页面内容的字符串查找、替换、拼接等；元数据获取的网络开销；Servlet本身的性能瓶颈。Web服务器端，包括：模块过滤，例如访问日志、Cookie打点、繁简转换；大HTML页面本身的GZIP压缩等。突发流量的抵御，例如攻击、秒杀、大促，等等。已用优化手段达到了边界，包括：可使用缓存的地方已经使用；服务端CPU能力已优化完毕（模板解析、压缩）。总体来看，必须从架构着手彻底解决。架构优化的方向上，考虑以下3个方面。改变缓存方式，直接缓存HTTP响应结果。改变缓存位置，直接基于Web服务器，屏蔽业务逻辑。基本原则，缓存空间足够大、无单点、易于维护。为此，2012年起正式启动了动态浏览型系统的改造项目，通过静态化手段解决上述问题。即基于业务把原动态系统中的内容做动静分离，对浏览者无关部分做缓 存，动态内容做CSI填充。具体考虑从三方面重点着手展开：动静信息分离、静态化缓存方式，以及缓存失效机制。图2为一期静态化整体架构。图2 ?一期静态化整体架构动静分离将原页面内容按业务进行区分，从浏览用户、信息发布者、时间、地域、私有（Cookie等）信息等维度分析，抽取出页面中相对公共不依赖以上因素，且变化频 度较低的内容作为基础，生成静态化内容。静态化后页面URL固定，不同URL表示不同内容，服务器返回的请求与URL相关，其他动态内容则通过异步接口调 用，通过CSI方式填充。以商品详情系统为例，静态化后商品基本信息如标题、商品详情、销售属性组合等信息均直接进入缓存，其他如优惠、库存、物流、服务 等动态信息则通过异步调用方式填充至静态化后的页面框架内。缓存方式整体可划分为应用服务器、Web服务器、CDN节点、客户端浏览器4层缓存体系（如图3所示），分别承载不同使命。图3 ?缓存整体划分缓存系统方面从开发成本、稳定性、I/O性能各方面综合考虑，选择了阿里内部广泛使用的分布式key/value系统Tair，存取静态化后的页面。相对 Nginx本地硬盘缓存方式来说，本地Tair读写性能更优，且服务器响应时间和负载波动影响小，使用及维护成本低。整套体系详解如下。应用层缓存：减小后端应用服务器压力，减少远程调用量。Web服务器缓存：减小后端应用服务器压力，抵挡瞬间