拒绝访问 |
| 百度云加速
请打开cookies.
此网站 () 的管理员禁止了您的访问。原因是您的访问包含了非浏览器特征(3922fea4f036436a-ua98).
重新安装浏览器，或使用别的浏览器1：硬件方面
普通的一个p4的服务器每天最多能支持大约10万左右的IP，如果访问量超过10W那么需要专用的服务器才能解决，如果硬件不给力 软件怎么优化都是于事无补的。主要影响服务器的速度
有：网络-硬盘读写速度-内存大小-cpu处理速度。
2：软件方面
第一个要说的就是数据库，首先要有一个很好的架构，查询尽量不用* 避免相关子查询 给经常查询的添加索引 用排序来取代非顺序存取，如果条件允许 ，一般MySQL服务器最好安装
在Linux操作系统中 。关于apache和在高并发的情况下推荐使用，ginx是Apache服务器不错的替代品。nginx内存消耗少 官方测试能够支撑5万并发连接，在实际生产环境中跑
到2～3万并发连接数。方面不需要的模块尽量关闭，使用memcached，Memcached 是一个高性能的分布式内存对象缓存系统，不使用数据库直接从内存当中调数据，这样大大提升了速
度，iiS或Apache启用GZIP压缩优化网站，压缩网站内容大大节省网站流量。
第二，禁止外部的盗链。
外部网站的图片或者文件盗链往往会带来大量的负载压力，因此应该严格限制外部对于自身的图片或者文件盗链，好在目前可以简单地通过refer来控制盗链，Apache自己就可以通过配置来禁止盗链，IIS也有一些第三方的ISAPI可以实现同样的功能。当然，伪造refer也可以通过代码来实现盗链，不过目前蓄意伪造refer盗链的还不多，可以先不去考虑，或者使用非技术手段来解决，比如在图片上增加水印。
第三，控制大文件的下载。
大文件的下载会占用很大的流量，并且对于非SCSI硬盘来说，大量文件下载会消耗CPU，使得网站响应能力下降。因此，尽量不要提供超过2M的大文件下载，如果需要提供，建议将大文件放在另外一台服务器上。
第四，使用不同主机分流主要流量
将文件放在不同的主机上，提供不同的镜像供用户下载。比如如果觉得RSS文件占用流量大，那么使用FeedBurner或者FeedSky等服务将RSS输出放在其他主机上，这样别人访问的流量压力就大多集中在FeedBurner的主机上，RSS就不占用太多资源了
第五，使用不同主机分流主要流量将文件放在不同的主机上，提供不同的镜像供用户下载。比如如果觉得RSS文件占用流量大，那么使用FeedBurner或者FeedSky等服务将RSS输出放在其他主机上，这样别人访问的流量压力就大多集中在FeedBurner的主机上，RSS就不占用太多资源了。
第六，使用流量分析统计软件。在网站上安装一个流量分析统计软件，可以即时知道哪些地方耗费了大量流量，哪些页面需要再进行优化，因此，解决流量问题还需要进行精确的统计分析才可以。比如：Google Analytics（Google分析）。
高并发和高负载的约束条件：硬件、部署、操作系统、Web 服务器、PHP、MySQL、测试
部署：服务器分离、数据库集群和库表散列、镜像、负载均衡
负载均衡分类： 1)、DNS轮循 2）代理服务器负载均衡 3）地址转换网关负载均衡 4）NAT负载均衡 5）反向代理负载均衡 6）混合型负载均衡
部署方案1：
适用范围：静态内容为主体的网站和应用系统；对系统安全要求较高的网站和应用系统。
Main Server：主服务器
承载程序的主体运行压力，处理网站或应用系统中的动态请求；
将静态页面推送至多个发布服务器；
将附件文件推送至文件服务器；
安全要求较高，以静态为主的网站，可将服务器置于内网屏蔽外网的访问。
DB Server：数据库服务器
承载数据库读写压力；
只与主服务器进行数据量交换，屏蔽外网访问。
File/Video Server：文件/视频服务器
承载系统中占用系统资源和带宽资源较大的数据流；
作为大附件的存储和读写仓库；
作为视频服务器将具备视频自动处理能力。
发布服务器组：
只负责静态页面的发布，承载绝大多数的Web请求；
通过Nginx进行负载均衡部署。
部署方案2：
适用范围：以动态交互内容为主体的网站或应用系统；负载压力较大，且预算比较充足的网站或应用系统；
Web服务器组：
Web服务无主从关系，属平行冗余设计；
通过前端负载均衡设备或Nginx反向代理实现负载均衡；
划分专用文件服务器/视频服务器有效分离轻/重总线；
每台Web服务器可通过DEC可实现连接所有数据库，同时划分主从。
数据库服务器组：
相对均衡的承载数据库读写压力；
通过数据库物理文件的映射实现多数据库的数据同步。
共享磁盘/磁盘阵列
将用于数据物理文件的统一读写
用于大型附件的存储仓库
通过自身物理磁盘的均衡和冗余，确保整体系统的IO效率和数据安全；
方案特性：
通过前端负载均衡，合理分配Web压力；
通过文件/视频服务器与常规Web服务器的分离，合理分配轻重数据流；
通过数据库服务器组，合理分配数据库IO压力；
每台Web服务器通常只连接一台数据库服务器，通过DEC的心跳检测，可在极短时间内自动切换至冗余数据库服务器；
磁盘阵列的引入，大幅提升系统IO效率的同时，极大增强了数据安全性。
Web服务器：
Web服务器很大一部分资源占用来自于处理Web请求，通常情况下这也就是Apache产生的压力，在高并发连接的情况下，Nginx是Apache服务器不错的替代品。Nginx (&engine x&) 是俄罗斯人编写的一款高性能的 HTTP 和反向代理服务器。在国内，已经有新浪、搜狐通行证、网易新闻、网易博客、金山逍遥网、金山爱词霸、校内网、YUPOO相册、豆瓣、迅雷看看等多家网站、 频道使用 Nginx 服务器。
Nginx的优势：
高并发连接：官方测试能够支撑5万并发连接，在实际生产环境中跑到2～3万并发连接数。
内存消耗少：在3万并发连接下，开启的10个Nginx 进程才消耗150M内存（15M*10=150M）。
内置的健康检查功能：如果 Nginx Proxy 后端的某台 Web 服务器宕机了，不会影响前端访问。
策略：相对于老牌的Apache，我们选择Lighttpd和Nginx这些具有更小的资源占用率和更高的负载能力的web服务器。
MySQL本身具备了很强的负载能力，MySQL优化是一项很复杂的工作，因为这最终需要对系统优化的很好理解。大家都知道数据库工作就是大量的、 短时的查询和读写，除了程序开发时需要注意建立索引、提高查询效率等软件开发技巧之外，从硬件设施的角度影响MySQL执行效率最主要来自于磁盘搜索、磁盘IO水平、CPU周期、内存带宽。
　　根据服务器上的硬件和软件条件进行MySQl优化。MySQL优化的核心在于系统资源的分配，这不等于无限制的给MySQL分配更多的资源。在MySQL配置文件中我们介绍几个最值得关注的参数：
改变索引缓冲区长度(key_buffer)
改变表长(read_buffer_size)
设定打开表的数目的最大值(table_cache)
对缓长查询设定一个时间限制(long_query_time)
如果条件允许 ，一般MySQL服务器最好安装在Linux操作系统中，而不是安装在FreeBSD中。策略： MySQL优化需要根据业务系统的数据库读写特性和服务器硬件配置，制定不同的优化方案，并且可以根据需要部署MySQL的主从结构。
1、加载尽可能少的模块；
2、如果是在平台下，尽可能使用IIS或者Nginx来替代我们平常用的Apache；
3、安装加速器（都是通过缓存代码预编译的结果和数据库结果来提高代码的执行速度）eAccelerator，eAccelerator是一个自由开放源码php加速器，优化和动态内容缓存，提高了性能php脚本的缓存性能，使得PHP脚本在编译的状态下，对服务器的开销几乎完全消除。
Apc：Alternative PHP Cache（APC）是 PHP 的一个免费公开的优化代码缓存。它用来提供免费，公开并且强健的架构来缓存和优化 PHP 的中间代码。
memcache：memcache是由Danga Interactive开发的，高性能的，分布式的内存对象缓存系统，用于在动态应用中减少数据库负载，提升访问速度。主要机制是通过在内存里维护一个统 一的巨大的hash表，Memcache能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等
Xcache：国人开发的缓存器，
策略： 为PHP安装加速器。
代理服务器（缓存服务器）：
Squid Cache（简称为Squid）是一个流行的自由软件（GNU通用公共许可证）的代理服务器和Web缓存服务器。Squid有广泛的用途，从作为网页服务器的前置cache服务器缓存相关请求来提高Web服务器的速度，到为一组人共享网络资源而缓存万维网，域名系统和其他网络搜索，到通过过滤流量帮助网络安全，到局域网通过代理网。Squid主要设计用于在Unix一类系统运行。
策略：安装Squid 反向代理服务器，能够大幅度提高服务器效率。
压力测试：压力测试是一种基本的质量保证行为，它是每个重要软件测试工作的一部分。压力测试的基本思路很简单：不是在常规条件下运行手动或自动测试，而是在计算机数量较少或系统资源匮乏的条件下运行测试。通常要进行压力测试的资源包括内部内存、CPU 可用性、磁盘空间和网络带宽等。一般用并发来做压力测试。压力测试工具：webbench，ApacheBench等
漏洞测试：在我们的系统中漏洞主要包括：注入漏洞，xss跨站脚本攻击等。安全方面还包括系统软件，如操作系统漏洞，mysql、apache等的漏洞，一般可以通过升级来解决。
漏洞测试工具：Acunetix Web Vulnerability Scanner
No related content found.
阅读(...) 评论() &Hi，亲爱的小伙伴！
欢迎来到社区!
Tools Online | 在线开发工具
RankList | 热门文章
扫码关注 PHP1 官方微信号
Recommend | 推荐阅读
| 中国最专业的PHP中文社区 |
Copyright (C) 1998 - . All Rights Reserved
第一PHP社区温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
郑州宇晨PHP培训,本着教书育人的目的,希望能在短暂的4个月内,让学员毕业之后脱颖而出,找到一份自己满意的工作。这里学习和实战相结合让您毕业之后更加自信的适应工作环境！如若您一个月内学习PHP实在比较吃力,您可申请退学我们将全额退还您的学费。选择宇晨PHP培训让您安心学习无后顾之忧！欢迎您的垂询.联系电话:139
在线扣扣: 网址:www.hnphp.net
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
演进为此，自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节点地域特性的缓存体系， 也降低了秒级请求的冲击型峰值，更好地满足了系统稳定性需求。在未来一段时间内，与天猫类似的浏览型系统均能够参照这套架构体系较为方便地完成静态化改造 和接入，并达到理想的稳定性和可伸缩目标。
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
在LOFTER的更多文章
loftPermalink:'',
id:'fks_',
blogTitle:'天猫浏览型系统的CDN静态化架构演变',
blogAbstract:'在天猫双11活动中，商品详情、店铺等浏览型系统，通常会承受超出日常数倍甚至数十倍的流量冲击。随着历年来双11流量的大幅增加，每年这些浏览型系统都要面临容量评估、硬件扩容、性能优化等各类技术挑战。因此，架构方面的重点在于，如何能够利用合理成本应对瞬间飙高的峰值请求，并确保活动完整周期中系统容量的可伸缩性、用户响应时间的稳定性，以及外部依赖系统出现问题时的高可用性。此外，作为最主要的页面流量承载体系，架构方面还需考虑防爬攻击、流控容灾等安全、稳定的需求，并综合衡量网络带宽、硬件成本、缓存效率等各方面要素，找准平衡点，从而达到以不变应万变的理想效果。',
blogTag:'宇晨php培训,郑州php培训',
blogUrl:'blog/static/',
isPublished:1,
istop:false,
modifyTime:6,
publishTime:4,
permalink:'blog/static/',
commentCount:0,
mainCommentCount:0,
recommendCount:0,
bsrk:-100,
publisherId:0,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:true,
hostIntro:'郑州宇晨PHP培训,本着教书育人的目的,希望能在短暂的4个月内,让学员毕业之后脱颖而出,找到一份自己满意的工作。这里学习和实战相结合让您毕业之后更加自信的适应工作环境！如若您一个月内学习PHP实在比较吃力,您可申请退学我们将全额退还您的学费。选择宇晨PHP培训让您安心学习无后顾之忧！欢迎您的垂询.联系电话:139
在线扣扣: 网址:www.hnphp.net',
hmcon:'1',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}}