大型网站架构演化-20141028
网站架构演变过程
架构演变第一步：物理分离webserver和数据库最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：这一步涉及到了这些知识体系：这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：这一步涉及到了这些知识体系：前端页面缓存技术，例如squid，如想用好的话还得深入掌握下squid的实现方式以及缓存的失效算法等。
架构演变第三步：增加页面片段缓存增加了squid做缓存后，整体系统的速度确实是提升了，webserver的压力也开始下降了，但随着访问量的增加，发现系统又开始变的有些慢了，在尝到了squid之类的动态缓存带来的好处后，开始想能不能让现在那些动态页面里相对静态的部分也缓存起来呢，因此考虑采用类似ESI之类的页面片段缓存策略，OK，于是开始采用ESI来做动态页面中相对静态的片段部分的缓存。
大型网站架构
大型网站架构演变之前也有一些介绍大型网站架构演变的文章，例如LiveJournal的、ebay的，都是非常值得参考的，不过感觉他们讲的更多的是每次演变的结果，而没有很详细的讲为什么需要做这样的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是有了写这篇文章的想法，在这篇文章中 将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点初步的概念，:-)，文中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。
架构演变第一步：物理分离webserver和数据库最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已 经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这 个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段： 将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更 高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：这一步涉及到了这些知识体系：这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
大型网站的演变过程
⼤型⽹站的演变过程前⾔随着互联⽹的不断发展，以及⽹站负载的不断增⾼，⼀个成熟⽹站的架构需要满⾜下⾯的⼏点，才能为⽤户提供稳定可⽤的服务⾼并发、⼤流量：PV 量巨⼤；⾼可⽤：7*24 ⼩时不间断服务；海量数据：⽂件数⽬分分钟 xxTB；⽤户分布⼴泛，⽹络情况复杂：⽹络运营商；安全环境恶劣：⿊客的攻击；需求快速变更，发布频繁：快速适应市场，满⾜⽤户需求；渐进式发展：慢慢地运营出⼤型⽹站；⽬标解决了上述问题之后，我们需要达到⼀个什么样的⽬标和⽬的呢？每个⽬标背后⾯临着技术、设计、维护等诸多⽅⾯的挑战；⽽⽬标本⾝的期望值也会根据实际情况进⾏调整，这也意味着⽹站架构建设是个不断调整的过程。
有了问题，也定了伟⼤的⽬标，那么⽹站在不同阶段⾯对不同的问题，是如何解决的？⼜是如何⼀步步成长为⼤型⽹站架构，实现这些伟⼤的⽬标呢？架构体系演进1. 单机时代草根时期，快速开发⽹站并上线。
当然，通常只是先试⽔，⽤户规模也没有形成，经济能⼒和投⼊也⾮常有限。
应⽤程序、数据库、⽂件等所有资源都集中在⼀台 Server上，典型案例：基于 LAMP 架构的 PHP ⽹站；优点：简单、快速迭代达成业务⽬标；缺点：存在单点、谈不上⾼可⽤；技术点：应⽤设计要保证可扩展；2. 缓存出场当⽹站发展到有⼀定的业务量和⽤户规模，⽹站的访问速度变慢，主要瓶颈是在数据库上，所以此时再⽤草根时代的架构显然已经不能满⾜我们业务的需求了，那想提升⽹站速度，就需要解决数据库上的瓶颈，于是，缓存出场了。
单机时代+缓存优点：简单有效、⽅便维护；缺点：存在单点、谈不上⾼可⽤；技术点：客户端（浏览器）缓存、前端页⾯缓存、页⾯⽚段缓存、本地数据缓存/数据库缓存、远程缓存；缓存分类：页⾯缓存：客户端缓存，减少对⽹站的访问；本地缓存：访问速度快，但数据量有限，减少对DB查询；远程缓存：远程访问，可以集群，因此容量不受限制；3. 数据库和应⽤逻辑分离市场反响还不错，⽤户量每天在增长，数据库疯狂读写，逐渐发现⼀台服务器快撑不住了。
大型网站技术架构
大型网站架构演Βιβλιοθήκη 过程使用缓存改善网站性能问题：访问量持续增长，web性能再次变差；响应速度变慢
2-8定律：web的访问规律：80%业务访问集中在20%的数 据上；
增加应用服务器本地缓存，这个最直接，也最简单
增加远程分布式缓存集群：当本地的内存不足以放下需要的 缓存的数据时，就只能通过分布式
大型网站技术架构
演讲人
2 0 2 5 - 11 - 11
目录
01. 大型网站架构演变过程
02. 大型网站架构模式
03. 网站的高可用架构
04. 网站的可扩展性
05. 架构核心要素
06. 网站的高性能架构
07. 网站的伸缩性架构
08. 网站的安全性架构
ONE
01
大型网站架构演变过程
大型网站架构演变过程
大型网站架构演变过程
业务切分
按照业务来划分子系统，按产品线划分系统，通 过分布式服务来协同工作；
系统发展到最后都是一个拆分的过程，也不会像 三国一样合就必分，系统职能越来越单一化。这 也回到了面向对象编程的五项基本原则的单一职 责的原则。
业务切分
初始架构
02
应用、DB、文 件都在一块
03
经典的LAMP 模式
大型网站架构演变过程
应用服务和数据分离
问题：性能变差、 数据存储空间不 够
3台服务器
应用服务和数据分 离
问题：性能变差、数据存储空间 不够
3台服务器
应用服务器 数据服务器 文件服务器
需要处理大量业务逻辑，这需要更强的CPU；
需要快速磁盘检索和数据缓存，这需要更快 的硬盘和更大的内存；
阿里巴巴大型网站架构演变和知识体系
阿里巴巴大型网站架构演变和知识体系之前也有一些介绍大型网站架构演变的文章，例如LiveJournal的、ebay的，都是非常值得参考的，不过感觉他们讲的更多的是每次演变的结果，而没有很详细的讲为什么需要做这样的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是有了写这篇文章的想法，在这篇文章中将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点初步的概念，文中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。
架构演变第一步：物理分离webserver和数据库最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：这一步涉及到了这些知识体系：这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
解读大型网站系统架构的演化
解读大型网站系统架构的演化大型网站的架构是根据业务需求不断完善的，根据不同的业务特征会做特定的设计和考虑，本文只是讲述一个常规大型网站会涉及的一些技术和手段。
作者：李平来源：LEE的博客|2014-09-26 09:53收藏分享前言一个成熟的大型网站（如淘宝、京东等）的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性，它总是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。
所以成熟的系统架构是随业务扩展而完善出来的，并不是一蹴而就；不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯，要解决数亿的用户实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同。
尽管如此我们也可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段可以广泛运行在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。
一、最开始的网站架构最初的架构，应用程序、数据库、文件都部署在一台服务器上，如图：二、应用、数据、文件分离随着业务的扩展，一台服务器已经不能满足性能需求，故将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。
三、利用缓存改善网站性能在硬件优化性能的同时，同时也通过软件进行性能优化，在大部分的网站系统中，都会利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大部分网站访问都遵循28原则（即80%的访问请求，最终落在20%的数据上），所以我们可以对热点数据进行缓存，减少这些数据的访问路径，提高用户体验。
缓存实现常见的方式是本地缓存、分布式缓存。
当然还有CDN、反向代理等，这个后面再讲。
本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，OSCache就是常用的本地缓存组件。
大型互联网架构演变历程
大型互联网架构演变历程大型互联网架构的演变历程可以追溯到20世纪90年代中期的互联网初期阶段。
在那个时候，互联网是一个相对较小的网络，主要用于学术研究和军事应用。
随着商业互联网的发展，大型互联网架构逐渐成为了互联网发展的关键因素之一、本文将就大型互联网架构的演变历程进行探讨。
第一阶段：单一服务器架构在互联网的初期阶段，大多数网站都采用了单一服务器架构。
这种架构将所有的资源都放置在一台服务器上，包括网络服务、数据库、应用程序等。
这种架构简单易用，适合小规模的网站，但是当访问量增加时，单一服务器很快就会达到其性能极限，导致网站的响应速度下降。
第二阶段：分布式服务器架构为了解决单一服务器架构的性能瓶颈问题，出现了分布式服务器架构。
这种架构将网站的资源分布到多个服务器上，通过负载均衡来提高网站的性能和可靠性。
这种架构还引入了分布式文件系统，用于存储和管理大量的数据。
分布式服务器架构提供了更高的吞吐量和更好的扩展性，适合处理大规模的访问量。
第三阶段：多层架构随着互联网发展的趋势，网站的规模和复杂性也不断增加。
为了应对这种情况，出现了多层架构。
这种架构将网站的功能划分为多个层次，每个层次都有特定的职责。
常见的多层架构包括：负载均衡层、应用层、数据层等。
负载均衡层负责将访问流量分发到不同的服务器上，应用层负责处理业务逻辑，数据层负责存储和管理数据。
多层架构提供了更好的可扩展性和灵活性，使得各个层次可以独立扩展和升级。
第四阶段：微服务架构随着互联网应用的进一步发展，出现了大量的互联网服务和API。
为了更好地组织和管理这些服务和API，出现了微服务架构。
微服务架构将应用拆分成小的、独立的服务单元，每个服务单元都可以独立开发、部署和扩展。
这种架构使得互联网应用更加模块化和可维护，同时也提高了系统的可靠性和容错性。
第五阶段：容器化和云原生架构近年来，容器化和云原生架构成为了大型互联网架构的新趋势。
容器化技术可以将应用程序和相关依赖打包成一个容器，在不同的环境中运行。
大型网站架构演变
大型网站架构演变今日我们来谈谈一个网站普通是如何一步步来构建起系统的，虽然我们希翼网站一开头就能有一个很好的架构，但马克思告知我们事物是在进展中不断前进的，网站架构也是随着业务的扩大、用户的需求不断完美的，下面是一个网站架构逐步进展的基本过程，读完后，请思量，你现在在哪个阶段。
架构演化第一步：物理分别WebServer和数据库最开头，因为某些主意，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但因为这篇文章我们只关注架构的演化历程，因此就假设这个时候已经是托管了一台主机，并且有一定的带宽了。
这个时候因为网站具备了一定的特色，吸引了部分人拜访，逐渐你发觉系统的压力越来越高，响应速度越来越慢，而这个时候比较显然的是数据库和应用相互影响，应用出问题了，数据库也很简单浮现问题，而数据库出问题的时候，应用也简单出问题。
于是进入了第一步演化阶段：将应用和数据库从物理上分别，变成了两台机器，这个时候技术上没有什么新的要求，但你发觉的确起到效果了，系统又复原到以前的响应速度了，并且支撑住了更高的流量，并且不会由于数据库和应用形成相互的影响。
看看这一步完成后系统的图示：架构演化其次步：增强页面缓存好景不长，随着拜访的人越来越多，你发觉响应速度又开头变慢了，查找缘由，发觉是拜访数据库的操作太多，导致数据衔接竞争激烈，所以响应变慢。
但数据库衔接又不能开太多，否则数据库机器压力会很高，因此考虑采纳缓存机制来削减数据库衔接资源的竞争和对数据库读的压力。
这个时候首先大概会挑选采纳squ等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）举行缓存（固然，也可以采纳将页面静态化的计划），这样程序上可以不做修改，就能够很好的削减对WebServer的压力以及削减数据库衔接资源的竞争，OK，于是开头采纳squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：这一步涉及到了这些学问体系：前端页面缓存技术，例如squid，如想用好的话还得深化把握第1页共2页。
大型网站技术架构演变_互联网_IT计算机_专业资料.pptPPT18页
Hale Waihona Puke 21、要知道对好事的称颂过于夸大，也会招来人们的反感轻蔑和嫉妒。——培根 22、业精于勤，荒于嬉；行成于思，毁于随。——韩愈
23、一切节省，归根到底都归结为时间的节省。——马克思 24、意志命运往往背道而驰，决心到最后会全部推倒。——莎士比亚
大型网站技术架构演变_互联 网_IT计算机_专业资料.ppt
41、实际上，我们想要的不是针对犯 罪的法 律，而 是针对 疯狂的 法律。 ——马 克·吐温 42、法律的力量应当跟随着公民，就 像影子 跟随着 身体一 样。— —贝卡 利亚 43、法律和制度必须跟上人类思想进 步。— —杰弗 逊 44、人类受制于法律，法律受制于情 理。— —托·富 勒
25、学习是劳动，是充满思想的劳动。——乌申斯基
谢谢！
大型网站架构演化20141028
大型网站架构演化所谓网站架构模式即为了解决大型网站面临的高并发访问、海量数据、高可靠运行等一系列问题与挑战。
为此，在实践中提出了许多解决方案，以实现网站高性能、高可靠性、易伸缩、可扩展、安全等各种技术架构目标。
1、初始阶段的网站架构初始阶段都比较简单，通常一台服务器就可以搞定一个网站了，看图。
2、应用服务和数据服务分离随着网站业务的发展，一台服务器逐渐不能满足需求；这时候就需要将应用和数据分离，如图。
3、使用缓存改善网站性能毫无疑问，现在的网站基本上都会使用缓存，即：80%的业务访问都会集中在20%的数据上。
4、使用应用服务器集群改善网站的并发处理能力因为单一应用服务器能够处理的请求连接有限，在网站访问高峰时期，应用服务器会成为整个网站的瓶颈。
因此使用负载均衡处理器势在必然。
通过负载均衡调度服务器，可将来自浏览器的访问请求分发到应用的集群中的任何一台服务器上。
5、数据库读写分离当用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
而目前主流的数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库的数据更新同步到另一台服务器上。
网站利用数据库这一功能实现数据库读写分离，从而改善数据库负载压力。
6、使用反向代理和CDN加上网站相应提高网站的访问速度，主要手段有使用CDN和反向代理。
CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，而反向代理是部署在网站的中心机房，当用户请求到达中心机房后，首先访问的反向代理，如果反向代理缓存着用户请求的资源，则直接返回给用户。
7、使用分布式文件系统和分布式数据库系统任何强大的单一服务器都满足不了大型网站持续增长的业务需求。
分布式数据库是网站数据库拆分的最后手段，只用在单表数据规模非常大的时候才使用。
不到不得已时，网站更常用的数据库拆分手段是业务拆分，将不同业务的数据部署在不同的物理服务器上。
8、使用NoSQL和搜索引擎搜素引擎也基本已经形成现在大型网站必须提供的功能了，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。
小型网站到大型网站的架构演变
小型网站到大型网站的架构演变之前也有一些介绍大型网站架构演变的文章，例如LiveJournal的、ebay的，都是非常值得参考的，不过感觉他们讲的更多的是每次演变的结果，而没有很详细的讲为什么需要做这样的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是有了写这篇文章的想法，在这篇文章中将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点初步的概念，:)，文中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。
架构演变第一步：物理分离webserver和数据库最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：这一步涉及到了这些知识体系：这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
大型网站框架从单台服务器到群集的演变过程
大型网站框架从单台服务器到群集的演变过程之前也有一些介绍大型网站架构演变的文章，例如LiveJournal的、ebay的，都是非常值得参考的，不过感觉他们讲的更多的是每次演变的结果，而没有很详细的讲为什么需要做这样的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是有了写这篇文章的想法，在这篇文章中将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点初步的概念，:)，文中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。
架构演变第一步：物理分离webserver和数据库最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候已经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：物理分离webserver和数据库这一步涉及到了这些知识体系：这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid等类似的机制来将系统中相对静态的页面(例如一两天才会有更新的页面)进行缓存(当然，也可以采用将页面静态化的方案)，这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
大型网站架构演化所谓网站架构模式即为了解决大型网站面临的高并发访问、海量数据、高可靠运行等一系列问题与挑战。
为此，在实践中提出了许多解决方案，以实现网站高性能、高可靠性、易伸缩、可扩展、安全等各种技术架构目标。
1、初始阶段的网站架构初始阶段都比较简单，通常一台服务器就可以搞定一个网站了，看图。
2、应用服务和数据服务分离随着网站业务的发展，一台服务器逐渐不能满足需求；这时候就需要将应用和数据分离，如图。
3、使用缓存改善网站性能毫无疑问，现在的网站基本上都会使用缓存，即：80%的业务访问都会集中在20%的数据上。
4、使用应用服务器集群改善网站的并发处理能力因为单一应用服务器能够处理的请求连接有限，在网站访问高峰时期，应用服务器会成为整个网站的瓶颈。
因此使用负载均衡处理器势在必然。
通过负载均衡调度服务器，可将来自浏览器的访问请求分发到应用的集群中的任何一台服务器上。
5、数据库读写分离当用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
而目前主流的数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库的数据更新同步到另一台服务器上。
网站利用数据库这一功能实现数据库读写分离，从而改善数据库负载压力。
6、使用反向代理和CDN加上网站相应提高网站的访问速度，主要手段有使用CDN和反向代理。
CDN和反向代理的基本原理都是缓存，区别在于CDN部署在网络提供商的机房，而反向代理是部署在网站的中心机房，当用户请求到达中心机房后，首先访问的反向代理，如果反向代理缓存着用户请求的资源，则直接返回给用户。
7、使用分布式文件系统和分布式数据库系统任何强大的单一服务器都满足不了大型网站持续增长的业务需求。
分布式数据库是网站数据库拆分的最后手段，只用在单表数据规模非常大的时候才使用。
不到不得已时，网站更常用的数据库拆分手段是业务拆分，将不同业务的数据部署在不同的物理服务器上。
8、使用NoSQL和搜索引擎搜素引擎也基本已经形成现在大型网站必须提供的功能了，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。
9、业务拆分大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将真个网站业务拆分成不同的产品线。
具体到技术上，也会根据产品线话费，将一个网站拆分成许多不同的应用，每个应用独立部署维护。
应用之间可以通过超链接建立管理，也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
10、分布式服务由于每一个应用系统都需要执行许多相同的业务操作，比如用户管理，session管理，那么可以将这些公用的业务提取出来，独立部署。
1、分层分层是企业应用系统中最常见的一种架构牧师，将系统在横向维度上切分成几个部分，每个部分负责一部分相对简单并比较单一的职责，然后通过上层对下层的依赖和调度组成一个完整的系统。
在网站的分层架构中，常见的为3层，即应用层、服务层、数据层。
应用层具体负责业务和视图的展示；服务层为应用层提供服务支持；数据库提供数据存储访问服务，如数据库、缓存、文件、搜索引擎等。
分层架构是逻辑上的，在物理部署上，三层架构可以部署在同一个物理机器上，但是随着网站业务的发展，必然需要对已经分层的模块分离部署，即三层结构分别部署在不同的服务器上，是网站拥有更多的计算资源以应对越来越多的用户访问。
所以虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护，但在网站的发展过程中，分层结构对网站支持高并发向分布式方向的发展至关重要。
2、分隔如果说分层是将软件在横向方面进行切分，那么分隔就是在纵向方面对软件进行切分。
网站越大，功能越复杂，服务和数据处理的种类也越多，将这些不同的功能和服务分隔开来，包装成高内聚低耦合的模块单元，不仅有助于软件的开发维护也便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。
大型网站分隔的粒度可能会很小。
比如在应用层，将不同业务进行分隔，例如将购物、论坛、搜索、广告分隔成不同的应用，有对立的团队负责，部署在不同的服务器上。
3、分布式对于大型网站，分层和分隔的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。
分布式意味着可以使用更多的计算机完同样的工作，计算机越多，CPU、内存、存储资源就越多，能过处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。
在网站应用中，常用的分布式方案有一下几种.分布式应用和服务：将分层和分隔后的应用和服务模块分布式部署，可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗。
分布式静态资源：网站的静态资源如JS、CSS、Logo图片等资源对立分布式部署，并采用独立的域名，即人们常说的动静分离。
静态资源分布式部署可以减轻应用服务器的负载压力；通过使用独立域名加快浏览器并发加载的速度。
分布式数据和存储：大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据库需要分布式存储。
分布式计算：目前网站普遍使用Hadoop和MapReduce分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。
4、集群对于用户访问集中的模块需要将独立部署的服务器集群化，即多台服务器部署相同的应用构成一个集群，通过负载均衡设备共同对外提供服务。
服务器集群能够为相同的服务提供更多的并发支持，因此当有更多的用户访问时，只需要向集群中加入新的机器即可；另外可以实现当其中的某台服务器发生故障时，可以通过负载均衡的失效转移机制将请求转移至集群中其他的服务器上，因此可以提高系统的可用性。
5、缓存缓存目的就是减轻服务器的计算，使数据直接返回给用户。
在现在的软件设计中，缓存已经无处不在。
具体实现有CDN、反向代理、本地缓存、分布式缓存等。
使用缓存有两个条件：访问数据热点不均衡，即某些频繁访问的数据需要放在缓存中；数据在某个时间段内有效，不过很快过期，否在会因为数据过期而脏读，影响数据的正确性。
6、异步使用异步，业务之间的消息传递不是同步调用，而是将一个业务操作分成多个阶段，每个阶段之间通过共享数据的方法异步执行进行协作。
具体实现则在单一服务器内部可用通过多线程共享内存对了的方式处理；在分布式系统中可用通过分布式消息队列来实现异步。
异步架构的典型就是生产者消费者方式，两者不存在直接调用。
7、冗余网站需要7×24小时连续运行，那么就得有相应的冗余机制，以防某台机器宕掉时无法访问，而冗余则可以通过部署至少两台服务器构成一个集群实现服务高可用。
数据库除了定期备份还需要实现冷热备份。
甚至可以在全球范围内部署灾备数据中心。
8、自动化具体有自动化发布过程，自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。
9、安全网站在安全架构方面有许多模式：通过密码和手机校验码进行身份认证；登录、交易需要对网络通信进行加密；为了防止机器人程序滥用资源，需要使用验证码进行识别；对常见的XSS攻击、SQL注入需要编码转换；垃圾信息需要过滤等。
所谓架构，一种通俗的说法就是“最高层次的规划，难以改变的决定”，这些规划和决定奠定了事物未来发展的方向和最终的蓝图。
而软件架构即“有关软件整体结构与组件的抽象描述，用于指导大型软件系统各方面的设计”。
一般来说软件架构需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。
1、性能性能是网站架构设计的一个重要方面，任何软件架构设计方案都必须考虑可能带来的性能问题。
也正因为性能问题几乎无处不在，所以优化网站性能的手段也非常多：浏览器端：可以通过浏览器缓存、页面压缩传输、合理布局页面、减少Cookie传输等手段，甚至可以使用CDN加速功能。
应用服务器端：可以使用服务器本地缓存和分布式缓存，也可以通过异步操作方式来加快响应，在高并发请求的情况下，可以将多台应用服务器组成一个集群共同对外服务，提高整体处理能力，改善性能。
数据库服务器端：可用使用索引、缓存、SQL性能优化等手段，还可以使用NoSQL数据库来优化数据模型、存储结构等。
衡量网站性能有一系列指标，重要的有响应时间、TPS、系统性能计数器等，通过这些指标以确定系统设计是否达到目标。
2、可用性可用性即能够不间断提供服务的时间。
几乎所有网站都承诺7×24小时可用，但事实上任何网站都不可能达到完全的7×24，总会有一些故障时间，扣除这些故障时间，就是网站的可用时间。
一些大型网站可以做到4个9以上的可用性，也就是99.99%。
网站高可用的主要手段就是冗余，应用部署在多台服务器上同时提供服务，数据存储在多台服务器上相互备份，任何一台服务器都不会影响应用的整体可以，通常的实现手段即把多台服务器通过负载均衡设备组成一个集群。
衡量一个系统架构设计是否满足高可用的目标，就是假设系统中任何一台或者多台服务器宕机时，以及出现各种不可预期的问题时，系统整体是否依然可用。
3、伸缩性大型网站需要面对大量用户的高并发访问和存储海量数据，网站通过集群的方式将多台服务器组成一个整体共同提供服务。
所谓伸缩性是指通过不断向集群中加入服务器的手段来缓解不断整体上市用户并发访问压力和不断增长的数据存储需求。
衡量架构伸缩性的主要标准就是是否可用多台服务器构建集群，是否容易向集群中添加新的服务器。
加入新的服务器后是否可以提供和原来的服务器无差别的服务。
集群中可容纳的总服务器数量是否有限制。
4、扩展性不同于其他架构要素主要关注非功能性需求，网站的扩展性架构直接关注网站的功能需求。
网站快速发展，功能不断扩展，如何设计网站的架构使其能够快速响应需求变化，是网站可扩展架构的主要目标。
衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不同产品之间是否很少耦合等。
网站可扩展架构的主要手段是事件驱动架构和分布式服务。
事件驱动通常利用消息队列实现，通过这种方式将消息生产和处理逻辑分隔开。
服务器服务则是将业务和可复用服务分离开来，通过分布式服务框架调用。
新增加产品可用通过调用可复用的服务来实现自身的业务逻辑，而对现有产品没有任何影响。
5、安全性互联网是开发的，任何人在任何地方都可以访问网站。
网站的安全架构就是保护网站不受恶意访问和攻击，保护网站的重要数据不被窃取。
衡量网站安全架构的标准就是针对现存和潜在的各种攻击和窃密手段，是否有可靠的应对策略。
网站性能是客观的指标，可以具体体现到响应时间、吞吐量、并发数、性能计数器等技术指标。
1、性能测试指标1.1 响应时间指应用执行一个操作需要的时间，指从发出请求到最后收到响应数据所需要的时间。