网站性能

最开始的网站架构 最初业务量不大，访问量小，此时的架构，应用程序、数据库、文件都部署在一台服务器上，有些甚至仅仅是租用主机空间 1. 应用、数据、文件分离 将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。 2. 利用缓存改善网站性能 大部分网站访问都遵循28原则,即80%的访问请求，最终落在20%的数据上,所以我们可以对热点数据进行缓存，减少热点数据的访问路径，提高用户体验。缓存实现常见的方式是本地缓存、分布式缓存。当然还有CDN、反向代理。 2.1 本地缓存 本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，组件。本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。OSCache就是常用的本地缓存。 2.2 分布式缓存 分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。 2.3 反向代理 部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户，如果没有缓存数据才会继续访问应用服务器获取，这样做减少了获取数据的成本。反向代理有Squid，Nginx。 2.4 CDN 假设我们的服务器都部署在杭州的机房，对于浙江的用户来说访问是较快的

目录 大型网站核心架构要素 1.性能 2.可用性 3.伸缩性 4.扩展性 5.安全性 大型网站核心架构要素 软件架构需要关注的架构要素：性能、可用性、伸缩性、扩展性、安全性 1.性能 可优化性能的环节： 浏览器端： 浏览器缓存、使用页面压缩、合理布局页面、减少Cookie传输等 CDN，将静态内容存储在离用户最近的网络服务商机房，部署方向代理服务器，缓存热点文件，加快请求响应速度，减轻应用服务器负载压力。 应用服务器端： 使用服务器本地缓存和分布式缓存，加快请求处理，减轻数据库负载压力 异步操作 搭建应用服务器集群，提高整体处理能力，改善性能。 代码层面： 多线程，内存管理 数据库服务器端： 索引、缓存、SQL优化等，加入NoSQL数据库 衡量网站性能的一些指标： 响应时间 TPS：事务数/秒，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。 系统性能计数器 …… 还有其他一些指标作为日常监控，分析系统瓶颈，预测网站容量，还需要进行压力测试，知道整个系统的极限，还可以测试超出系统负载能力后，会出现什么问题。 2.可用性 一个大型网站通常需要全天无故障运行，一旦出现故障，造成的损失都是不可估量的。比如很多年前的12306买票系统故障 大型网站可用性4个9指标 99.99%。 高可用设计：保证服务器宕机时，应用依然可用。 网站高可用的主要手段就是冗余

网站性能优化对于大型网站来说非常重要，一个网站的访问打开速度影响着用户体验度，网站访问速度慢会造成高跳出率，小网站很好解决，那对于大型网站由于栏目多，图片和图像都比较庞大，那该怎么进行整体性能优化呢？本文为你提供一份大型php网站性能和并发访问优化方案. 一、大型网站性能提高策略： 大型网站，比如门户网站，在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。这几个解决思路在一定程度上意味着更大的投入。 web容器是一种服务程序，在服务器一个端口就有一个提供相应服务的程序，而这个程序就是处理从客户端发出的请求，如JAVA中的Tomcat容器，ASP的IIS或PWS都是这样的容器。一个服务器可以多个容器。 1、HTML静态化 其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。 2、图片服务器分离 大家知道，对于Web服务器来说，不管是Apache、IIS还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的、甚至很多台的图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃。

运维工作应该掌握哪些技能？ 运维中关键技术点解剖：1 大量高并发网站的设计方案 ；2 高可靠、高可伸缩性网络架构设计；3 网站安全问题，如何避免被黑？4 南北互联问题,动态CDN解决方案；5 海量数据存储架构 一、什么是大型网站运维？ 首先明确一下，全文所讲的”运维“是指：大型网站运维，与其它运维的区别还是蛮大的；然后我们再对大型网站与小型网站进行范围定义，此定义主要从运维复杂性角度考虑，如网站规范、知名度、服务器 量级、pv量等考虑，其它因素不是重点；因此，我们先定义服务器规模大于1000台，pv每天至少上亿（至少国内排名前10），如sina、baidu、 QQ， http:// 51.com 等等；其它小型网站可能没有真正意义上的运维工程师，这与网站规范不够和成本因素有关，更多的是集合网络、系统 、开发工作于一身的“复合性人才”，就如有些公司把一些合同采购都纳入了运维职责范围，还有如IDC网络规划也纳入运维职责。所以，非常重要一定需要明白：运维对其它关联工种必须非常了解熟悉：网络、系统、系统开发、存储，安全,DB等；我在这里所讲的运维工程师就是指专职运维工程师。 我们再来说说一般产品的“出生”流程： 1、首先公司管理层给出指导思想，PM定位市场需求（或copy成熟应用）进行调研、分析、最终给出详细设计。 2、架构师根据产品设计的需求，如pv大小预估、服务器规模

一、网站架构相关 （1）评估网站性能涉及的专业名词术语 　　1.PV（Page View） 　　PV即访问量，中文翻译为页面浏览，代表页面浏览量，用户每刷新一次就会计算一次。PV的具体计算方法是：从浏览器发出一个对网络服务器的请求（Request），网络服务器接到这个请求后，会将该请求对应的一个页面（Page）发送给浏览器，从而产生一个PV。 　　2.UV（Unique Visto） 　　UV即独立访问，访问网站的一台电脑客户端为一个访客，如果按天计算，程序统计会从0:00至24:00这段时间内的电脑客户端，且相同的客户端只被计算一次。 　　3.并发连接数（Concurrent TCP Connections） 　　当一个网页被浏览，服务器就会和浏览器建立连接，每个连接表示一个并发。如果当前网页页面包含很多图片，图片并不是一个个显示的，服务器会产生多个连接同时发送文字和图片以提高浏览速度。 　　4.QPS（Query Per Second） 　　QPS即每秒查询率，是衡量一个特定查询服务器在规定时间内所处理流量多少的标准，在因特网上，作为域名系统服务器的机器性能通常用每秒查询率来衡量。对于系统而言，QPS数值是一个非常重要的参数，它是综合反映系统最大吞吐能力的衡量标注。 　　5.机房的网络质量评估 　　　　1）稳定性：响应延迟，丢包率 　　　　2）带宽质量

1 秒杀业务分析# 正常电子商务流程 （1）查询商品； （2）创建订单； （3）扣减库存； （4）更新订单； （5）付款； （6）卖家发货； 秒杀业务的特性 （1）低廉价格； （2）大幅推广； （3）瞬时售空； （4）一般是定时上架； （5）时间短、瞬时并发量高； 2 秒杀技术挑战# 假设某网站秒杀活动只推出一件商品，预计会吸引1万人参加活动，也就说最大并发请求数是10000，秒杀系统需要面对的技术挑战有： 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。 解决方案 ：将秒杀系统独立部署，甚至 使用独立域名，使其与网站完全隔离 。 高并发下的应用、数据库负载 用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成负载压力。 解决方案 ：重新设计秒杀商品页面，不使用网站原来的商品详细页面， 页面内容静态化，用户请求不需要经过应用服务 。 突然增加的网络及服务器带宽 假设商品页面大小200K（主要是商品图片大小），那么需要的网络和服务器带宽是2G（200K×10000），这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。 解决方案

前一两年抓过某工商信息网站，几三周时间大约抓了过千万多万张页面。那时由于公司没啥经费，报销又拖得很久，不想花钱在很多机器和带宽上，所以当时花了较多精力研究如何让一台爬虫机器达到抓取极限。 Python爬虫这两年貌似成为了一项必备技能，无论是搞技术的，做产品的，数据分析的，金融的，初创公司做冷启动的，都想去抓点数据回来玩玩。这里面绝大多数一共都只抓几万或几十万条数据，这个数量级其实大可不必写爬虫，使用 chrome 插件web scraper或者让selenium驱动 chrome 就好了，会为你节省很多分析网页结构或研究如何登陆的时间。 本篇只关注如何让爬虫的抓取性能最大化上，没有使用scrapy等爬虫框架，就是多线程+Python requests库搞定。 对一个网站定向抓取几十万张页面一般只用解决访问频率限制问题就好了。对机器内存，硬盘空间，URL去重，网络性能，抓取间隙时间调优一般都不会在意。 如果要设计一个单台每天抓取上百万张网页，共有一亿张页面的网站时 ，访问频率限制问题就不是最棘手的问题了，上述每一项都要很好解决才行。硬盘存储，内存，网络性能等问题我们一项项来拆解。 一、优化硬盘存储 所以千万级网页的抓取是需要先设计的，先来做一个计算题。共要抓取一亿张页面，一般一张网页的大小是400KB左右， 一亿张网页就是1亿X200KB=36TB 。这么大的存储需求

Yslow是雅虎开发的基于网页性能分析浏览器插件，从年初我使用了YSlow后，改变了博客模板大量冗余代码，不仅提升了网页的打开速度，这款插件还帮助我分析了不少其他网站的代码，之前我还特意写了 提高网站速度的秘籍 ，就是通过这款插件分析得出的。网络上已经有不少Yslow使用说明了，本文我想介绍下我使用Yslow的方法和一些别人没提到的小技巧。 Yslow的安装方法 现在Yslow已经有很多版本了，本文介绍的是3.0.4最新版，打开 Yslow官网 就能看到有四个版本可供选择：火狐（firefox）浏览器、谷歌（chrome）浏览器、欧朋（opera）浏览器和移动版。 安装Yslow要先 安装 Firebug （本地址以火狐为例），两种方法启动Yslow：1、打开Firebug窗口，选择Yslow选项。2、直接点击火狐右下角的Yslow启动按钮。 （图1：Yslow的启动界面） 点击 Run Test 运行Yslow，也可以点击 Grade, Components, 或Statistics选项开始对页面的分析，如果在 Autorun YSlow each time a web page is loaded 上打上对勾，它将自动对以后打开页面进行分。 注意图中的红框，这里是规则集，YSlow （V2）包含了所有22个测试的规则，YSlow （V1）包含原始13规则，小网站或博客

架构的本质 一个软件系统随着功能越来越多，调用量急剧增长，整个系统逐渐碎片化，越来越无序，最 终无法维护和扩展，所以系统在一段时间的野蛮生长后，也需要及时干预，避免越来越无序。 架构的本质就是对系统进行有序化重构，使系统不断进化 那架构是如何实现无序到有序的呢？ 基本的手段就是分和合，先把系统打散，然后重新组合。 分的过程是把系统拆分为各个子系统 / 模块 / 组件，拆的时候，首先要解决每个组件的定 位问题，然后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的 组件有机整合在一起，相对来说，第一步的拆分更难。 拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得 柔性，可以因需而变，实现业务敏捷 架构的分类 架构一般可分业务架构、应用架构、技术架构 1. 业务架构从概念层面帮助开发人员更好的理解系统，比如业务流程、业务模块、输入输出、 业务域 2. 应用架构从逻辑层面帮助开发落地系统，如数据交互关系、应用形式、交互方式，是的整 个系统逻辑上更容易理解，步入大家熟知的 SOA 就属于应用架构的范畴 3. 技术架构主要解决技术平台选型、如操作系统、中间件、设备、多机房、水平扩展、高可 用等问题 需要注意的是，系统或者架构首先都是为人服务的，系统的有序度高，用用逻辑合理，业务 概念清晰是第一位。现在大家讨论更多的是技术架构，如高并发设计

秒杀系统架构分析与实战 #1 秒杀业务分析# 正常电子商务流程 （1）查询商品；（2）创建订单；（3）扣减库存；（4）更新订单；（5）付款；（6）卖家发货 秒杀业务的特性 （1）低廉价格；（2）大幅推广；（3）瞬时售空；（4）一般是定时上架；（5）时间短、瞬时并发量高； #2 秒杀技术挑战# 假设某网站秒杀活动只推出一件商品，预计会吸引1万人参加活动，也就说最大并发请求数是10000，秒杀系统需要面对的技术挑战有： 对现有网站业务造成冲击 秒杀活动只是网站营销的一个附加活动，这个活动具有时间短，并发访问量大的特点，如果和网站原有应用部署在一起，必然会对现有业务造成冲击，稍有不慎可能导致整个网站瘫痪。 解决方案：将秒杀系统独立部署，甚至 使用独立域名，使其与网站完全隔离 。 高并发下的应用、数据库负载 用户在秒杀开始前，通过不停刷新浏览器页面以保证不会错过秒杀，这些请求如果按照一般的网站应用架构，访问应用服务器、连接数据库，会对应用服务器和数据库服务器造成负载压力。 解决方案：重新设计秒杀商品页面，不使用网站原来的商品详细页面， 页面内容静态化，用户请求不需要经过应用服务 。 突然增加的网络及服务器带宽 假设商品页面大小200K（主要是商品图片大小），那么需要的网络和服务器带宽是2G（200K×10000），这些网络带宽是因为秒杀活动新增的，超过网站平时使用的带宽。 解决方案