合肥论坛建站模板,安徽房和城乡建设部网站,网站搜索栏怎么做,哪个网站可以做会计试题在天猫双11活动中#xff0c;商品详情、店铺等浏览型系统#xff0c;通常会承受超出日常数倍甚至数十倍的流量冲击。随着历年来双11流量的大幅增加#xff0c;每年这些浏览型 系统都要面临容量评估、硬件扩容、性能优化等各类技术挑战。因此#xff0c;架构方面的重点在于商品详情、店铺等浏览型系统通常会承受超出日常数倍甚至数十倍的流量冲击。随着历年来双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服务器缓存减小后端应用服务器压力抵挡瞬间峰值和/或针对少量定点内容的攻击。CDN缓存合理地利用CDN内容缓存放置在离用户最近的地方加快响应的速度。浏览器缓存减少用户请求数量降低系统压力提升用户体验。 缓存失效 缓存失效主要包含“失效后台进行主动失效”和“缓存过期自动失效”两种机制。针对主动失效主要技术难点包括以下3个方面。 失效来源及监控范围基于业务决定需要监听哪些数据源哪部分内容变更通过变更消息接收执行缓存失效动作。每秒失效数据量级单位时间内大量数据源如商品、店铺装修失效处理。要失效的缓存范围支持批量例如基于域名和单个数据源缓存失效变更。 以商品详情系统为例失效来源主要为商品数据及店铺装修信息后台用户修改导致对应内容发生变更时通过消息机制通知失效后台。失效后台接收消息并保留待失效商品ID通过调用本地Tair接口失效缓存大致流程如图4所示。 图4 缓存失效流程 改造效果 依然以天猫商品详情系统为例采取静态化架构后2012年双11时在性能方面结合后期完成的店铺装修分离等优化工作系统单机实体机在 80%缓存 命中率的情况下安全QPS每秒查询率相较2011年同期单机性能提升7倍多系统资源则不到原来的50%。与此同时静态化还解决了单URL热点攻 击问题更重要的是使得原动态架构下依赖的后端Java系统可以转变为弱依赖一方面既通过静态化缓存层一定程度上保护了后端系统另一方面在极限情况 下当后端系统不可用时可以通过缓存维持一部分访问量。 第二阶段统一Web缓存 第一阶段以商品详情为主的静态化架构改造取得了良好的效果除天猫商品详情系统率先完成改造外店铺等浏览型业务系统也很快参照类似方案完成了架构 调整。在 过程中逐渐确立了静态化技术规范简化了接入步骤同时也发现在各自的系统中尽管同样基于浏览型业务场景但由于采用的缓存方案细节差异存在一些 涉及静态化缓存体系相关的共性问题包括以下几点。 单机缓存静态页面受部署模式影响缓存层无法水平扩展。单机模式下缓存受限于服务器能力及内存容量命中率受制约。CSI模式填充动态内容需要前端脚本配合开发成本较高。 因此自然而然想到有必要统一Web缓存层接入共享静态化集群以节省成本、提高稳定性和命中率。从运维角度看 统一接入层可以减少多个应用接入使用的成本接入的应用只需维护自身Java系统不用单独维护缓存只要关心如何使用统一的缓存框架也可更好地让更多流量型系统接入使用统一接入层易于维护并可统一加强全局监控、实现配置自动化使集中维护升级更加便利统一接入层可以共享内存最大化利用内存不同系统间的内存可以动态切换有效应对攻击等类似突发情况。 搭建统一接入层需要针对各浏览型系统做局部改动。而整体需要重点解决的技术问题从架构层次上看主要涉及以下几大部分。 缓存系统选择 第一阶段各浏览型系统采用了单机缓存模式基于成本、业务场景等各方面因素稍有不同。搭建统一接入层需要能够兼顾各浏览型系统的特殊要求同时还需 能支持共 同需要的ESI解析及ESI模式下GZIP压缩完成静态页面局部动态内容服务端填充性能方面能够满足双11/双12流量压力下的QPS每秒访问 率要求支持失效协议以及长连接可执行批量失效。综合以上分析并考虑未来静态化内容最终CDN化部署方式统一接入层Cache最终软件层面可支持 以上所有功能同时还包括快速失效和预热能力支持CSS和JavaScript的脚本合并长连接和批量失效支持基于HTTP头的可编程配置等。 统一失效机制 与 缓存软件变更对应各接入统一缓存的浏览型系统需针对新的缓存体系及协议改造原有失效机制使用公共协议标准来执行批量及单个对象的主动失效。同时建立 了统一的失效中心和缓存校验层所有接入应用的主动失效请求统一经由失效中心通过Purge方式执行缓存失效。底层失效源方面监控信息源数据变更。以 商品为例当商品编辑完毕包括商品标题描述等更新后详情页面需要失效基于实时监控和消息机制进行主动失效如图5所示。 图5 基于事实监控和消息机制主动失效 Web服务器改造 缓存层之前的Web服务层需要能支持一致性Hash分组并集成现有系统使用的Session框架可支持基于域名虚拟主机的动态配置。为此核心系统部门的同事自行开发了淘宝定制版本的Nginx服务器Tengine作为统一接入层之上的Web服务器层部署。 网络流量支持 统一接入缓存层后由于集中了各系统缓存信息且访问集中所以网络部署层次方面可使用万兆网卡配置解决硬件瓶颈同时评估集群需支撑的网络出口流量确保机房内部及外部出口无瓶颈在缓存不命中的情况下需能支撑请求回源服务器端形成的内部流量。 整体部署方案 图6是整体部署方案从中可以看出 统一接入层部署包括前端Nginx服务器缓存系统后端Java应用部署结构Web服务器层做一致性Hash分组统一缓存层支持ESI或CSI方式获取动态内容统一失效中心机制失效缓存。 图6 整体部署方案 改造效果 统一接入层于2013年上半年改造完成并开始了商品详情等浏览型系统的接入工作完成后在原有单机缓存模式之上又增加了一层集中式缓存解决了缓 存层的水 平扩展问题。万兆网卡的使用有效解决了缓存层的网络瓶颈。由于统一接入层与应用无关因此可以多应用共用使监控和维护成本大大降低并提高了质量和效 率。当然这一改造也造成应用对缓存层的强依赖链路同时这一层缓存也存在单点问题。从静态化单机缓存模式到统一接入层路只走了一半一切改造的终极目 标是利用CDN分布式、地域性特性及强大的流量容量体系实现浏览型应用的CDN静态化。 第三阶段CDN静态化 统一接入层解决了单机缓存内存使用率低的问题摆脱了单机缓存受内存大小制约在面对商品数量增加和商品热点分散的场景下只能垂直扩展那些无法水 平扩展的 问题这提升了缓存系统的可维护性和扩展性。在完成系统从单机静态化缓存到统一接入层的架构改造之后已经具备了将静态页面放置到CDN上的条件。CDN 提供了更强的服务能力放置在离用户最近的节点上是缓存系统单元化最理想的架构。同时也为双11峰值流量和防攻击提供了更为可靠稳定的保障。 CDN化涉及3个具体技术难点。 CDN分布式节点失效问题。方案采用主动失效的方式商品变更后主动发送请求给缓存校验层由其通知失效中心接收并分发处理节点失效任务以确保秒级失效。命中率问题。方案优化节点部署条件CDN节点数量可控避免失效请求量过大靠近流量集中区域且节点到主站网络稳定控制节点数量访问流量集中分布在这批节点节点内部采用类似统一缓存层的一致性Hash规则以达到类似命中率。局部区域动态内容定时切换。方案价格、库存等动态信息走动态系统接口通过异步方式获取展现端定时切换活动Banner等内容走ESI回源并同样缓存回源的静态资源。 整体架构 基于以上思路总体架构已经较为清晰方案上从缓存体系、失效模式、动态内容填充几方面入手执行改造整体架构如图7所示。 图7 静态化整体架构 缓存体系 统一接入层和CDN节点上都是用Web服务器Cache方式。静态化应用对应的域名会被解析到CDN和统一接入层的虚拟IP上CDN拿到请求 后先读取 本地缓存缓存不命中则到统一缓存层获取。统一接入层按原有逻辑处理请求缓存不命中则回源到服务器端获取数据。同时统一接入层Web服务器需要能够识 别用户请求是CDN回源类型还是正常请求以免重复打点访问日志和GZIP压缩。 缓存失效 缓存失效原理与统一接入层类似。失效执行流程大致为客户端请求经VIP被随机分配给失效中心某个节点然后失效任务被发送至代理经代理向缓存服务器发送失效命令并返回结果如图8所示。 图8 缓存失效原理 动态内容填充 业务方面因为存在定时切换页面局部内容的需求整体架构中增加ESI和页面打点作为动态内容填充方式。ESI标签由Cache层负责解析回源并且会对ESI请求做缓存并且提供如下特性。 需要定时做全站变更的页面模块用ESI的Include实现时间判断则放在应用服务器处理回源请求的时候。回源以后应用服务器设置失效时间。例如请求回源时应用服务器加上s-maxAge这个页头的缓存在定点失效。Cache系统提供合并回源避免重复防止失效后的高并发回源给应用服务器带来冲击。Cache系统在ESI的缓存失效后回源回源的请求处理期间不会挂起外部请求会继续向客户端返回老版本的页面回源请求处理完以后更新成新版本。类似Copy on Write防止回源请求挂起导致前端服务器挂起。ESI回源时对Response Header的操作不会发到客户端。 改造效果 最终基于CDN静态化的架构去除了单机缓存的横向扩展瓶颈命中率越高、系统容量越大的特性决定了可以用较小的成本支持峰值流量引入ESI编 程模型解决 了页面上的局部刷新问题支持双11业务中一些需要全网定时切换页面内容的特殊需求静态页面弱依赖改造带来高可用性并最终沉淀出了一套与应用无关的 缓存和失效体系。2013年双11当天凭借这一整套CDN静态化架构天猫商品详情等浏览型系统平稳度过了创造历史的一天无论是页面访问量PV还 是页面请求峰值QPS均创新高而系统本身非常稳定并有充足余量承受更大级别的访问流量。同时新的部署模型和基于CDN节点地域特性的缓存体系 也降低了秒级请求的冲击型峰值更好地满足了系统稳定性需求。在未来一段时间内与天猫类似的浏览型系统均能够参照这套架构体系较为方便地完成静态化改造 和接入并达到理想的稳定性和可伸缩目标。转载于:https://www.cnblogs.com/ariklee/p/3606082.html
