网站性能检测评分
注：本网站页面html检测工具扫描网站中存在的基本问题，仅供参考。
大型网站项目优化
大型商业网站建设知识-网站运营优化常识 运营视频课程
随之大型商业网站平台不断兴起，凸显优化需求和数据额前沿效果，成为实现转化和满足自然排名推广的途径，对具有远瞻的企业来讲，商业性网站并非着力于眼前，而是竞技策略，毕竟小型网站短期能获利，同大企业营销战略来说，略显微薄，通过网站优化常识分析网站建设知识!
大型商业网站建设知识：
1、行业及页面的优化基础考虑
毕竟网站所涉含的栏目和产品多样化，要通过什么样的SEO手法，从多维度去维系海量长尾词和关键词上排名，从而获取大量真实用户流量，打造平台生态化基础。
2、网站建设运营初期筹划
其中对岗位的设置，人员技术水平的提升，资源的投入份额，以及合理的经营目标，都视为大型商业网站建设后，网站运营优化需具备的前提。
3、互联网市场分析及锁定用户
商业平台网站定位是提供什么行业信息服务、生活服务、还是其他?拟订周期性目标。
(1)分析市场环境：竞争对手情况分析，包含：市场份额、内容特征、网站竞争力强弱、品牌优势等。
(2)市场营销机会：从网站的经营理念到自身实力做对分析，平台的优势和自身现有条件下，可实现的定位和优势，若只是人力上的优势，就不算得是优势。
(3)服务定位分析：什么是免费服务、什么是收费服务、什么是增值服务，具体服务类别以及详细服务内容，通过服务对网站进行整改，满足消费心理。
(4)关键词挖掘：模拟用户搜索习惯和搜索量，分批整理和排除不必要的关键词，做好梯度上词。
(5)页面布局：对大型商业平台网站而言，长尾词分布、规划及拓展面，为网站运营优化做好词排名基础建设。
(6)用户消费分析：分析用户消费能力，按照不同梯度进行不同的策略定制，对企业和个人消费都存在不同程度的策略定制。
4、大型商业网站优化运营计划
(1)制作详细的运营推广进度表，通过对具体的人员、任务安排、完成度、时间周期，做一个较为完善的衡量标准，并且针对于周期性计划，落实到每天来进行完成。
5、商业型网站运营内容
(1)站内优化
(2)站外推广
(3)内容营销
(4)框架完善
大型网站SEO基础系列 – 多维度导航优化 SEO视频课程
对于企业网站来说，尤其是电商网站或者分类网站，常会使用多维度导航的结构，这种结构能帮助用户更好地筛选出所需要的结果。然而对SEO来说，却是个噩梦，我之前服务过的客户，经常有由于多维导航而导致的数以百万计的筛选页面链接产生，而且还是可抓取可收录的，
之前有不少帖子深入研究过这个问题，这篇文章介绍了多维导航对SEO的具体影响（https://moz/blog/building-faceted-navigation-that-doesnt-suck），我也写过一篇文章http://86i87/2013/06/21/crawler-resource-distribution/
本文想解决的是把梳理这一类现象，并且给出对应的解决方案。我们面对的核心问题其实是：“有哪些方法可以影响Google对页面的抓取和收录，以及这些方法的优缺点是什么？”
简要回顾多维度导航
一句话概括，多维度导航是指网页上存在根据一系列属性（属性之间无明显相关性）筛选结果的导航形式。以下图为例，通过处理器类型、屏幕分辨率、外壳颜色等不同属性来挑选笔记本电脑，这样的展现方式就是多维度导航
由于每种可能的排列组合属性的方式都会生成一种URL，多维度导航给SEO带来了几个问题
1.产生了大量的重复内容
2.消耗了有限的爬虫资源，而且返回给搜索引擎错误的信号
3.稀释了链接权重，同时链接权重传递给了本不该获得权重的页面。
来点具体的案例
看看一些多维度导航在网站上具体实施的例子以及对SEO的影响，你就知道为何要重视这个问题了。
Macy’s
在Google上搜索“site:https://macys/ black dresses”, Macys网站上符合这个条件的商品有1991个，然而Google却收录了12000多个页面。原因在于多维度导航设置的缺陷，可以从SEO的角度修复
Home Depot
再来看看Home Depot这个网站，搜索外开门会找到8930个页面，真的有必要让搜索引擎收录这么多相似产品的筛选页面吗？其实未必，当然也可以通过下面介绍的方法修复这个问题。
对于大型电商网站来说，这样的情况还真不少，我想说的是，其实这些网站在多维度导航这件事上还可以做得更阿基SEO友好一点。
多维度导航SEO解决方案
解决这个问题，首先要明确哪些内容需要被收录，哪些则是要避免收录的，以及如何达成这两个目的、我们来看看咱们手头都有哪些武器？
“Noindex, follow”
Noindex标签是大多数人首先想到的方案，该标签唯一的作用就是告诉爬虫别收录这个页面，因此对避免收录这个目的来说相当有用。
不过，虽然使用Noindex标签可以有效减少重复页面收录，但仍然会消耗爬虫资源，以及这些重复页面会接受链接权重，因此有效页面能获得的权重就会减少。
操作实例: 以上文提到的Macys网站为例，如果想收录“black dresses”页面，但是不想收录“100元以内的black dress”页面，在后面的筛选页面里面添加noindex标签就可以了。不过爬虫资源和链接资源的消耗是无法规避的。
Canonicalization
使用Canonical标签也是常见的应对方法。Canonical标签的意义在于告诉Google爬虫这一类页面相似度很高，只需要抓取网站返回给你的标准版页面就可以啦。Canonical标签的设计初衷就是为了解决重复内容的问题，而且链接权重也会被集中到标准版页面，看起来是个不错的方案。
可惜的是，Google爬虫的爬行资源还是会被消耗。
操作实例: /black-dresses?under-100/ 可以设置canoncial的URL指向 /black-dresses/.既解决了重复问题，又解决了链接权重分散的问题。
Robots.txt屏蔽
禁止爬虫抓取这部分筛选页面当然也很有效。好处是：速度快，操作方便，并可以自定义拼比页面。不过还是会有不好的影响：首先屏蔽之后，链接权重就好像被黑洞吸进去一样，彻底没有了；另外，有的时候Google也不会遵守Robots协议。比如下图，就是被Robots屏蔽的页面依然会展现在搜索结果里。
操作实例: 在Robots.txt中disallow *?under-100* .可以杜绝Google访问任何包含under-100参数的页面，然而如果有其他链接指向这类URL，Google仍然会收录。
“Nofollow” 不想收录的链接
可以通过Nofollow多维度导航链接来解决抓取资源消耗的问题，可惜的是，nofollow标签也无法彻底解决问题，这些重复页面依然会被收录，同时链接权重也依然会丢失。
操作实例: 给指向不想被收录的页面的内部链接都加上nofollow标签，意思就是告诉Google别去抓这些页面啦，抓点别的内容更好。
一起解决以上所有问题
首先，如果导航结构还没上线的话，我强烈建议通过不改变URL的方式实现多维度导航（多数通过js脚本实现），这样既不妨碍用户体验，又不会生成多个URL。可惜也有问题：有一些核心导航也能有被收录的价值，还是得给这类页面做入口。
下面这张表格也许能看得更清楚一些：
解决方案是否解决重复内容问题？是否解决爬虫资源问题？是否解决链接权重传递问题？是否允许外部链接传递权重？是否允许内部链接权重转移？备注
“Noindex, follow”YesNoNoYesYes
CanonicalizationYesNoYesYesYes只能用于相似页面
Robots.txtYesYesNoNoNoRobots屏蔽的页面仍然有可能被收录
NofollowNoYesNoYesNo
JavaScriptYesYesYesYesYes投入更多技术资源
所以有完美的解决方案吗？
首先,并没有一劳永逸的方案，完美的做法应该是以上方案的有机结合。下面这个例子也许适用于大多数网站，但是更重要的是了解自己网站的结构和问题所在，再给出针对性的方案。
制定方案之前先问自己一个问题，对你的网站来说，爬虫的抓取资源和链接权重哪个更加重要？不同答案意味着不同的做法。
例如：不在乎链接权重的损失，只想更好地分配爬虫的抓取资源,我会建议这样做：
1.目录页、子目录可以保留目前的可抓取状态（ /clothing/, /clothing/womens/, /clothing/womens/dresses/类似这样的地址）
2.对单个目录页而言，只允许带一个筛选条件的URL被访问
a. 对包含一个及以上筛选条件的页面，该页面上的筛选链接都加上nofollow属性（比如/clothing/womens/dresses?color=black/）
b.对包含两个及以上筛选条件的页面，同时添加Noindex标签（比如/clothing/womens/dresses?color=black?brand=express?/）
3.评估一下那些筛选条件对SEO有利（例如颜色和品牌名），把这些筛选条件加入白名单，做到可被搜索引擎抓取和收录
4.正确设置canonical 和 rel=prev/next 标签（可参考这篇文章http://gsqi/marketing-blog/how-to-set-up-pagination-rel-next-prev/）
上述做法可以逐渐缓解多维度导航给网站带来的问题，另外这个方案结合了集中不同的处理方法，包含了nofollow，noindex，canonical标签的组合使用，以获得更好的效果。
其他注意事项
有两点需要单独拎出来说一下
面包屑很有用
如果在目录页/子目录页没有面包屑导航， 就是给自己挖了个深坑。因为对于结构复杂的网站来说，面包屑是帮助爬虫理清网站结构最好的工具。
固定好URL中的筛选参数
某些情况下，有的网站筛选条件选择的顺序不一样，也会产生不同的URL，这样会让重复页面成倍增长，所以请务必写死筛选条件的排序。
总结
希望这篇文章能给你更多改善多维度导航，提升搜索表现的想法，其实主要就下面几点：
1.多维度导航用户体验很好，但是往往不利于SEO
2.多维度导航对SEO影响最大的点在于：重复内容、抓取资源浪费、链接权重不能有效传递
3.最核心的问题是：如何控制Google的爬行和收录？
4.没有万能的解决方案，好的做法是组合以下工具：noindex，follow；canonical；robots文件；nofollow；ajax/js.
5.设计解决方案的前提是对链接权重和爬虫资源有个优先级的判断。
阿里P8十年架构经验,两千字一张图，透析大型网站技术架构 公司视频课程
1 架构演化
大型网站的关注指标
高可用
高性能
易扩展
可伸缩
安全
大型网站的特点
高并发，大流量
高可用
海量数据
用户分布广泛，网络情况复杂
安全环境恶劣
需求快速变更，发布频繁
渐进式发展
大型网站架构演化发展过程
初始阶段，多使用LAMP来搭建，All In One即所有资源存放在一台服务器上
应用服务和数据服务分离，有独立的数据库服务器
使用缓存改善网站性能（依据是二八定律：80%的业务访问集中在20%的数据上）
这里需要考虑哪些数据适合缓存
缓存可以是本地缓存，也可以是远程分布式缓存
需要考虑使用合理的缓存策略，防止透传
使用应用服务器集群改善网站的并发处理能力
如果能通过增加一台服务器的方式来改善负载压力，就可以以同样的方式持续增加服务器来不断改善系统性能，从而实现系统的可伸缩性
这里需要考虑使用哪些负载均衡的策略
数据库读写分离
可以利用主流数据库提供的主从热备功能，通过配置两台数据库的主从关系，同时业内也有很多优秀的开源中间件如Atlas
缓存中的数据，如果更新过快，那么会持续刷新缓存，从而降低性能
使用反向代理和CDN加速网络响应
CDN和反向代理的基本原理都是缓存
CDN部署在网络提供商的机房，用户在请求网络服务时，可以从距离自己最近的网络提供商机房获取数据
反向代理部署在网站的中心机房，当用户的请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，那么就将其直接返回给用户
CDN的重点：——《大型网站系统与Java中间件实践》
全局调度
缓存技术
内容分发
带宽优化
使用分布式文件系统和分布式数据库系统
网站常用的数据库拆分手段是业务分库，即将不同业务的数据库部署到不同的物理服务器上
使用NoSQL和搜索引擎
ES
MongoDB
业务拆分，使用分而治之的手段将整个网站业务分成不同的产品线
SOA、服务化
中心化的 gataway方式
消息队列
不同服务访问同一个DB等
这部分十分重要，道理很简单，但是执行起来的效果千差万别。
当下火热的微服务，也是基于这种思想。
技术实现方式也有很多
分布式服务
大型网站架构演化的价值观
网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的。因此对于小型网站来说，最需要做的是位用户提供好的服务来创造价值，得到用户的认可，从而活下去，野蛮生长。
大型网站架构技术的核心价值是随网站所需灵活应对， 它是一个演化的过程
驱动大型网站技术发展的主要力量是网站的业务发展，是业务成就了技术，而不是相反。因此要摒弃为了技术而技术的套路
网站架构设计误区
一味追求大公司的解决方案
为了技术而技术
企图用技术解决所有问题
2 架构模式
分层，这是在横向方向对系统进行切分
分层的挑战在于必须合理规划层次边界和接口
分层包括物理分层和逻辑分层两种
分割，这是在纵向方向对系统进行切分
将不同的功能和服务分割开来，包装秤高内聚低耦合的模块单元
分布式
1） 分布式应用和服务；
2） 分布式静态资源；
3） 分布式数据和存储；
4） 分布式计算；
5） 分布式配置、分布式锁、分布式文件系统。。。
1） 分布式意味着服务调用必须通过网络，需要考虑带宽的影响；
2） 服务器越多，宕机的概率越大
分层和分割的目的在于小模块便于分布式部署
带来的问题：
常用的分布式方案：
集群，即多台服务器部署相同的应用，从而构成一个集群，通过负载均衡设备共同对外提供服务
即使访问量很小的分布式应用和服务，也至少要部署到两台服务器来构成一个小集群，这样可以提高系统的可用性
缓存，即将数据放在距离计算最近的位置以加快处理速度
CDN
反向代理
本地缓存
分布式缓存
异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步进行协作
1） 提高系统可用性；
2） 加快网站响应速度；
3） 消除并发访问高峰
通常需要使用消息队列
带来的好处：
冗余
集群带来的必然结果
安全需求的必然结果
自动化，DevOps思维，尽量减少人工干预
自动化发布
自动化代码管理
自动化测试
自动化安全监测
自动化部署
自动化监控
自动化报警
自动化失效转移、恢复
自动化分配资源
......
安全
3 大型网站核心架构要素
性能
一个性能问题可能会导致网站用户严重流失
衡量性能的指标：响应时间、TPS、系统性能计数器等
可用性
没有网站可以完美的7*24运行
网站高可用结构的前提是必然会出现服务器宕机，儿高可用设计的目标是当服务器宕机时，服务或者应用依然可用
必要的手段是集群，即冗余
伸缩性，即通过不断向集群中加入服务器的手段来环节不断上升的用户并发访问压力和不断增长的数据存储需求
衡量标准：是否可以构建集群；是否可以方便的向集群中添加新的服务器
扩展性，直接关注网站的功能，保证可以快速响应需求变更
衡量标准： 网站增加新的业务产品时，是否对现有业务透明无影响
安全性
衡量标准： 针对现存和潜在的各种攻击和窃密手段，是否可以有效的应对
4 瞬时响应 - 网站的高性能架构
不同视角下的网站性能
用户视角
主要是端到端的感觉
主要通过前段优化的手段来提升用户体验
开发人员视角
主要关注应用程序本身以及相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等
主要优化手段： 使用缓存加速数据读取、使用集群提高吞吐能力、使用异步消息加快请求响应、使用代码优化提升程序性能
运维人员视角
主要关注基础设施性能和资源利用率
主要优化手段： 建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用率
性能测试指标
响应时间，即应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间
并发数，即系统能够同时处理的请求的数目，也反映了系统的负载特性
吞吐量，即单位时间内系统处理的请求数量，体现系统的整理处理能力
性能计数器， 描述服务器或者操作系统性能的一些数据指标
性能测试方法
性能测试，以系统设计初期规划的性能指标为预期目标，对系统不断增压，验证系统在资源可接受范围内，是否能达到性能预期
负载测试，对系统不断的增加并发请求，知道系统的某项或者多项性能指标达到安全临界值
压力测试，超过安全负载的情况下，继续对系统增压，直到系统崩溃或者不能再处理任何请求
稳定性测试，在特定硬件、软件、网络情况下，给系统加载一定压力，是系统运行较长一段时间，来观察系统是否稳定
Web前端优化
浏览器访问优化
减少http请求
使用浏览器缓存
启用压缩
CSS放在页面最上面，JavaScript放在页面最下面
减少Cookie传输
CDN加速
反向代理
应用服务器性能优化
分布式缓存
一般会使用消息队列，带来的额外好处是会削平峰值
1）不同的缓存服务器之间进行通信，例如JBoss Cache；
2）不同缓存服务器之间不进行通信，例如Memcached
缓存从本质上来说，就是一个内存hash表
缓存需要缓存那些读写比很高、很少变化的数据，一般来说读写比在2:1以上时，缓存才有意义
应用程序读取数据时，首先到缓存中读取，如果缓存不存在或者已失效，再访问数据库，同时将新的数据放入缓存
缓存也需要注意缓存热点数据
缓存预热，在新启动的缓存系统中，在启动时就加载热点数据，这样启动后就可以直接使用
缓存穿透， 应用持续大量访问不存在的数据，因为这类数据不存在于缓存中，因此会大量访问数据库，从而降低性能
对于分布式缓存来说，目前有两类：
异步操作
使用集群
代码优化
多线程
1） 将对象设计成无状态对象；
2） 使用局部对象；
3） 并发访问资源时使用锁
需要注意线程安全问题，方法：
资源复用
主要是单例和资源池（对象池）
数据结构，选择合适的算法
垃圾回收
合理设置垃圾回收策略
存储性能优化
机械硬盘 vs 固态硬盘
B+树 vs LSM树
RAID vs HDFS
5 万无一失 - 网站的高可用架构
网站可用性度量
网站不可用时间 = 故障修复时间点 - 故障发现时间点
网站年度可用性指标 = （1 - 网站不可用时间/年度总时间）* 100%
一般以几个9来表示，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟
网站高可用架构的设计目标是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问
网站高可用架构的主要手段：数据和服务的冗余备份以及失效转移，一旦服务器宕机，就将服务切换至其他可用的服务器上。
高可用的应用
无状态应用： 应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等，请求提交到任何一个服务器上，处理的结构都是相同的。
通过负载均衡进行无状态服务的失效转移
负载均衡： 主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上， 以提升整体的负载处理能力
应用服务器集群的Session管理
Session复制
Session绑定
利用Cookie记录Session
Session服务器
高可用的服务
分级管理
核心服务与非核心服务隔离
核心服务优先使用高性能服务器
超时设置
异步调用
必须满足可以使用异步调用方式
服务降级
幂等性设计
服务高可用（高可靠）一直是美团外卖的第一要求，为了提高可用性，做了很多策略，包括并不限于上文提出的各种架构设计方案。
其实造成线上问题的很大一部分原因是由于发版造成的，也体现出了SOP的重要性。
关于降级与依赖隔离，可以考虑采用Hystrix实现自动降级与依赖隔离 。
高可用的数据
数据一旦出现问题，对于网站往往是毁灭性的打击，因此保护网站的数据就是保护企业的命脉。
主要手段：数据备份和失效转移
缓存服务高可用
观点一：缓存服务已经承担了业务中绝大多数的数据读取访问，因此需要同样保证高可用
观点二：缓存服务并不是数据存储服务，出现服务不可用导致数据丢失应从别的手段解决，而不是提高缓存服务本身高可用
缓存服务器集群中单机故障，集群规模较大时，数据丢失比例和数据负载压力影响很小。
CAP原理： 一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Parition Tolerance）这三个条件
数据高可用含义：
副本间数据一致
多个副本可读
同时写入数据副本
1）数据持久性
2）数据可访问性
3）数据一致性
数据一致性分类：
1） 数据强一致；
2） 数据用户一致；
3） 数据最终一致
数据备份
1） 异步热备；
2） 同步热备
冷备的优点是简单和廉价，成本和技术难度较低，缺点是不能保证数据最终一致
热备分为两种：
失效转移
1） 心跳检测（Keepalived、Heartbeat）；
2） 应用程序访问失败报告
失效确认：
访问转移
数据恢复
高可用网站的软件质量保证
网站发布，它的过程和服务器宕机效果箱单，其对系统可用性的影响也 类似
一般采取批量更新的方式进行，不会一次关掉集群中的全部服务器
自动化测试
一般使用Selenium来进行测试
预发布验证
预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的区别是没有配置在负载均衡服务器上，外部用户无法访问
代码控制
主干开发，分支发布
分支开发，主干发布，这是目前使用的主流方式
自动化发布
火车模型：将每个应用的发布过程看做一次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目下车，通过的项目继续坐着火车旅行，直到火车到达终点。
实际中，可能所有项目在途中都下车了，这样火车不得不回到原点，等待...
阿里P8十年架构经验,两千字一张图，透析大型网站技术架构 流量视频课程
1 架构演化
大型网站的关注指标
高可用
高性能
易扩展
可伸缩
安全
大型网站的特点
高并发，大流量
高可用
海量数据
用户分布广泛，网络情况复杂
安全环境恶劣
需求快速变更，发布频繁
渐进式发展
大型网站架构演化发展过程
初始阶段，多使用LAMP来搭建，All In One即所有资源存放在一台服务器上
应用服务和数据服务分离，有独立的数据库服务器
使用缓存改善网站性能（依据是二八定律：80%的业务访问集中在20%的数据上）
这里需要考虑哪些数据适合缓存
缓存可以是本地缓存，也可以是远程分布式缓存
需要考虑使用合理的缓存策略，防止透传
使用应用服务器集群改善网站的并发处理能力
如果能通过增加一台服务器的方式来改善负载压力，就可以以同样的方式持续增加服务器来不断改善系统性能，从而实现系统的可伸缩性
这里需要考虑使用哪些负载均衡的策略
数据库读写分离
可以利用主流数据库提供的主从热备功能，通过配置两台数据库的主从关系，同时业内也有很多优秀的开源中间件如Atlas
缓存中的数据，如果更新过快，那么会持续刷新缓存，从而降低性能
使用反向代理和CDN加速网络响应
CDN和反向代理的基本原理都是缓存
CDN部署在网络提供商的机房，用户在请求网络服务时，可以从距离自己最近的网络提供商机房获取数据
反向代理部署在网站的中心机房，当用户的请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，那么就将其直接返回给用户
CDN的重点：——《大型网站系统与Java中间件实践》
全局调度
缓存技术
内容分发
带宽优化
使用分布式文件系统和分布式数据库系统
网站常用的数据库拆分手段是业务分库，即将不同业务的数据库部署到不同的物理服务器上
使用NoSQL和搜索引擎
ES
MongoDB
业务拆分，使用分而治之的手段将整个网站业务分成不同的产品线
SOA、服务化
中心化的 gataway方式
消息队列
不同服务访问同一个DB等
这部分十分重要，道理很简单，但是执行起来的效果千差万别。
当下火热的微服务，也是基于这种思想。
技术实现方式也有很多
分布式服务
大型网站架构演化的价值观
网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的。因此对于小型网站来说，最需要做的是位用户提供好的服务来创造价值，得到用户的认可，从而活下去，野蛮生长。
大型网站架构技术的核心价值是随网站所需灵活应对， 它是一个演化的过程
驱动大型网站技术发展的主要力量是网站的业务发展，是业务成就了技术，而不是相反。因此要摒弃为了技术而技术的套路
网站架构设计误区
一味追求大公司的解决方案
为了技术而技术
企图用技术解决所有问题
2 架构模式
分层，这是在横向方向对系统进行切分
分层的挑战在于必须合理规划层次边界和接口
分层包括物理分层和逻辑分层两种
分割，这是在纵向方向对系统进行切分
将不同的功能和服务分割开来，包装秤高内聚低耦合的模块单元
分布式
1） 分布式应用和服务；
2） 分布式静态资源；
3） 分布式数据和存储；
4） 分布式计算；
5） 分布式配置、分布式锁、分布式文件系统。。。
1） 分布式意味着服务调用必须通过网络，需要考虑带宽的影响；
2） 服务器越多，宕机的概率越大
分层和分割的目的在于小模块便于分布式部署
带来的问题：
常用的分布式方案：
集群，即多台服务器部署相同的应用，从而构成一个集群，通过负载均衡设备共同对外提供服务
即使访问量很小的分布式应用和服务，也至少要部署到两台服务器来构成一个小集群，这样可以提高系统的可用性
缓存，即将数据放在距离计算最近的位置以加快处理速度
CDN
反向代理
本地缓存
分布式缓存
异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步进行协作
1） 提高系统可用性；
2） 加快网站响应速度；
3） 消除并发访问高峰
通常需要使用消息队列
带来的好处：
冗余
集群带来的必然结果
安全需求的必然结果
自动化，DevOps思维，尽量减少人工干预
自动化发布
自动化代码管理
自动化测试
自动化安全监测
自动化部署
自动化监控
自动化报警
自动化失效转移、恢复
自动化分配资源
......
安全
3 大型网站核心架构要素
性能
一个性能问题可能会导致网站用户严重流失
衡量性能的指标：响应时间、TPS、系统性能计数器等
可用性
没有网站可以完美的7*24运行
网站高可用结构的前提是必然会出现服务器宕机，儿高可用设计的目标是当服务器宕机时，服务或者应用依然可用
必要的手段是集群，即冗余
伸缩性，即通过不断向集群中加入服务器的手段来环节不断上升的用户并发访问压力和不断增长的数据存储需求
衡量标准：是否可以构建集群；是否可以方便的向集群中添加新的服务器
扩展性，直接关注网站的功能，保证可以快速响应需求变更
衡量标准： 网站增加新的业务产品时，是否对现有业务透明无影响
安全性
衡量标准： 针对现存和潜在的各种攻击和窃密手段，是否可以有效的应对
4 瞬时响应 - 网站的高性能架构
不同视角下的网站性能
用户视角
主要是端到端的感觉
主要通过前段优化的手段来提升用户体验
开发人员视角
主要关注应用程序本身以及相关子系统的性能，包括响应延迟、系统吞吐量、并发处理能力、系统稳定性等
主要优化手段： 使用缓存加速数据读取、使用集群提高吞吐能力、使用异步消息加快请求响应、使用代码优化提升程序性能
运维人员视角
主要关注基础设施性能和资源利用率
主要优化手段： 建设优化骨干网、使用高性价比定制服务器、利用虚拟化技术优化资源利用率
性能测试指标
响应时间，即应用执行一个操作需要的时间，包括从发出请求开始到收到最后响应数据所需要的时间
并发数，即系统能够同时处理的请求的数目，也反映了系统的负载特性
吞吐量，即单位时间内系统处理的请求数量，体现系统的整理处理能力
性能计数器， 描述服务器或者操作系统性能的一些数据指标
性能测试方法
性能测试，以系统设计初期规划的性能指标为预期目标，对系统不断增压，验证系统在资源可接受范围内，是否能达到性能预期
负载测试，对系统不断的增加并发请求，知道系统的某项或者多项性能指标达到安全临界值
压力测试，超过安全负载的情况下，继续对系统增压，直到系统崩溃或者不能再处理任何请求
稳定性测试，在特定硬件、软件、网络情况下，给系统加载一定压力，是系统运行较长一段时间，来观察系统是否稳定
Web前端优化
浏览器访问优化
减少http请求
使用浏览器缓存
启用压缩
CSS放在页面最上面，JavaScript放在页面最下面
减少Cookie传输
CDN加速
反向代理
应用服务器性能优化
分布式缓存
一般会使用消息队列，带来的额外好处是会削平峰值
1）不同的缓存服务器之间进行通信，例如JBoss Cache；
2）不同缓存服务器之间不进行通信，例如Memcached
缓存从本质上来说，就是一个内存hash表
缓存需要缓存那些读写比很高、很少变化的数据，一般来说读写比在2:1以上时，缓存才有意义
应用程序读取数据时，首先到缓存中读取，如果缓存不存在或者已失效，再访问数据库，同时将新的数据放入缓存
缓存也需要注意缓存热点数据
缓存预热，在新启动的缓存系统中，在启动时就加载热点数据，这样启动后就可以直接使用
缓存穿透， 应用持续大量访问不存在的数据，因为这类数据不存在于缓存中，因此会大量访问数据库，从而降低性能
对于分布式缓存来说，目前有两类：
异步操作
使用集群
代码优化
多线程
1） 将对象设计成无状态对象；
2） 使用局部对象；
3） 并发访问资源时使用锁
需要注意线程安全问题，方法：
资源复用
主要是单例和资源池（对象池）
数据结构，选择合适的算法
垃圾回收
合理设置垃圾回收策略
存储性能优化
机械硬盘 vs 固态硬盘
B+树 vs LSM树
RAID vs HDFS
5 万无一失 - 网站的高可用架构
网站可用性度量
网站不可用时间 = 故障修复时间点 - 故障发现时间点
网站年度可用性指标 = （1 - 网站不可用时间/年度总时间）* 100%
一般以几个9来表示，2个9是基本可用，网站年度不可用时间小于88小时；3个9是较高可用，网站年度不可用时间小于9小时；4个9是具有自动恢复能力的高可用，网站年度不可用时间小于53分钟；5个9是极高可用性，网站年度不可用时间小于5分钟
网站高可用架构的设计目标是保证服务器硬件故障时服务依然可用、数据依然保存并能够被访问
网站高可用架构的主要手段：数据和服务的冗余备份以及失效转移，一旦服务器宕机，就将服务切换至其他可用的服务器上。
高可用的应用
无状态应用： 应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行相应的业务逻辑处理，多个服务实例之间完全对等，请求提交到任何一个服务器上，处理的结构都是相同的。
通过负载均衡进行无状态服务的失效转移
负载均衡： 主要使用在业务量和数据量较高的情况下，当单台服务器不足以承担所有的负载压力时，通过负载均衡手段，将流量和数据分摊到一个集群组成的多台服务器上， 以提升整体的负载处理能力
应用服务器集群的Session管理
Session复制
Session绑定
利用Cookie记录Session
Session服务器
高可用的服务
分级管理
核心服务与非核心服务隔离
核心服务优先使用高性能服务器
超时设置
异步调用
必须满足可以使用异步调用方式
服务降级
幂等性设计
服务高可用（高可靠）一直是美团外卖的第一要求，为了提高可用性，做了很多策略，包括并不限于上文提出的各种架构设计方案。
其实造成线上问题的很大一部分原因是由于发版造成的，也体现出了SOP的重要性。
关于降级与依赖隔离，可以考虑采用Hystrix实现自动降级与依赖隔离 。
高可用的数据
数据一旦出现问题，对于网站往往是毁灭性的打击，因此保护网站的数据就是保护企业的命脉。
主要手段：数据备份和失效转移
缓存服务高可用
观点一：缓存服务已经承担了业务中绝大多数的数据读取访问，因此需要同样保证高可用
观点二：缓存服务并不是数据存储服务，出现服务不可用导致数据丢失应从别的手段解决，而不是提高缓存服务本身高可用
缓存服务器集群中单机故障，集群规模较大时，数据丢失比例和数据负载压力影响很小。
CAP原理： 一个提供数据服务的存储系统无法同时满足数据一致性（Consistency）、数据可用性（Availibility）、分区耐受性（Parition Tolerance）这三个条件
数据高可用含义：
副本间数据一致
多个副本可读
同时写入数据副本
1）数据持久性
2）数据可访问性
3）数据一致性
数据一致性分类：
1） 数据强一致；
2） 数据用户一致；
3） 数据最终一致
数据备份
1） 异步热备；
2） 同步热备
冷备的优点是简单和廉价，成本和技术难度较低，缺点是不能保证数据最终一致
热备分为两种：
失效转移
1） 心跳检测（Keepalived、Heartbeat）；
2） 应用程序访问失败报告
失效确认：
访问转移
数据恢复
高可用网站的软件质量保证
网站发布，它的过程和服务器宕机效果箱单，其对系统可用性的影响也 类似
一般采取批量更新的方式进行，不会一次关掉集群中的全部服务器
自动化测试
一般使用Selenium来进行测试
预发布验证
预发布服务器是一种特殊用途的服务器，它和线上的正式服务器唯一的区别是没有配置在负载均衡服务器上，外部用户无法访问
代码控制
主干开发，分支发布
分支开发，主干发布，这是目前使用的主流方式
自动化发布
火车模型：将每个应用的发布过程看做一次火车旅程，火车定点运行，期间有若干站点，每一站都进行例行检查，不通过的项目下车，通过的项目继续坐着火车旅行，直到火车到达终点。
实际中，可能所有项目在途中都下车了，这样火车不得不回到原点，等待...
