下载文档原格式
⼤型⽹站技术架构1. ⼤型⽹站架构演化发展历程1）初始阶段的⽹站架构应⽤程序、数据库、⽂件等所有资源都在⼀台服务器上。
Linux+PHP+Apache+MySQL。
初始阶段的⽹站架构2）应⽤服务和数据服务分离使⽤三台服务器：应⽤服务器、⽂件服务器、数据库服务器。
应⽤服务和数据服务分离3）使⽤缓存改善⽹站性能⽹站使⽤缓存4）使⽤应⽤服务器集群改善⽹站的并发处理能⼒应⽤服务器集群部署5）数据库读写分离数据库读写分离6）使⽤反向代理和CDN加速⽹站响应⽹站使⽤反向代理和CDN加速访问7）使⽤分布式⽂件系统和分布式数据库系统使⽤分布式⽂件和分布式数据库系统8）使⽤NoSQL和搜索引擎使⽤NoSQL和搜索引擎9）业务拆分垂直拆分，分⽽治之，按业务拆分成不同的应⽤。
业务拆分10）分布式服务⽔平拆分，提取公共组件，中台战略。
分布式服务2. ⼤型⽹站架构模式1）分层⽔平切分：应⽤层、服务层、数据层。
2）分割垂直切分：按业务切分。
3）分布式分布式应⽤和服务、分布式数据和存储、分布式计算、分布式锁、分布式⽂件系统。
4）集群5）缓存6）异步7）冗余8）⾃动化9）安全3. ⼤型⽹站核⼼架构要素软件架构：系统的各个重要组成部分及其关系构成了系统的架构，这些组成部分可以是具体的功能模块，也可以是⾮功能的设计与决策，他们相互关系组成⼀个整体，共同构成了软件系统的架构。
1）性能性能优化，前端：浏览器缓存、页⾯压缩、CDN缓存、反向代理缓存。
后端：缓存、异步、集群、多线程、改善内存管理、数据库索引、SQL优化。
2）可⽤性⾼可⽤的⼿段：冗余、负载均衡集群。
3）伸缩性关注点：⾮功能性需求（技术需求）。
衡量架构伸缩性的主要标准：是否可以⽤多台服务器构建集群，是否容易向集群中添加新的服务器，新服务器是否可以提供和原服务器⽆差别的服务，集群可容纳的总的服务器数量是否有限制。
4）扩展性关注点：功能需求。
衡量架构扩展性的主要标准：增加新的业务产品时，是否可以实现对现有产品透明⽆影响，不需要改动或者很少改动既有业务功能就可以上线新产品，不同产品之间是否很少耦合，⼀个产品改动对其他产品功能⽆影响。
大型网站系统架构演化之路前言一个成熟的大型网站(如淘宝、天猫、腾讯等)的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的，它是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。
所以成熟的系统架构是随着业务的扩展而逐步完善的，并不是一蹴而就;不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯，要解决数亿用户的实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同。
尽管如此我们也可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段广泛运用在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。
一、最开始的网站架构最初的架构，应用程序、数据库、文件都部署在一台服务器上，如图：二、应用、数据、文件分离随着业务的扩展，一台服务器已经不能满足性能需求，故将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。
三、利用缓存改善网站性能在硬件优化性能的同时，同时也通过软件进行性能优化，在大部分的网站系统中，都会利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大部分网站访问都遵循28原则(即80%的访问请求，最终落在20%的数据上)，所以我们可以对热点数据进行缓存，减少这些数据的访问路径，提高用户体验。
缓存实现常见的方式是本地缓存、分布式缓存。
当然还有CDN、反向代理等，这个后面再讲。
本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，OSCache就是常用的本地缓存组件。
本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。
分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。
大型网站架构演变之前也有一些介绍大型网站架构演变的文章，例如LiveJournal的、ebay的，都是非常值得参考的，不过感觉他们讲的更多的是每次演变的结果，而没有很详细的讲为什么需要做这样的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是有了写这篇文章的想法，在这篇文章中 将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点初步的概念，:-)，文中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。
架构演变第一步：物理分离webserver和数据库最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已 经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这 个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段： 将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更 高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：这一步涉及到了这些知识体系：这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
互联⽹架构的演变互联⽹架构的演变：1 最初是前端⼀个web 加⼀个DB的结构这种结构，web容易挂掉，业务就会终⽌，由于⾼可⽤的需求，出现了下⾯这样的架构2 加了⼀个web，两个web之间是主备的关系，⼀个挂了，另⼀个来代替，⽤来解决⾼可⽤问题3 之后发现这样的架构⽀持的访问量不够了，前端撑不住那么⼤的访问量，因为前端的访问量和DB的落库有⼤概是10⽐1的⽐例，前端访问10个，会有1个能够落库，所以随着访问量的增加，前端先扛不住了，这个时候主、备结构已经不能解决⾼可⽤的问题，所以在web前⾯加了⼀个ngx，作为负载均衡进⾏访问的转发，这个时候，web和web之间的主备关系就不存在了，在ngx进⾏转发的时候会有⼀个session保持的操作，再后来就出现⽆状态的概念，在两个web之间进⾏轮询，给谁都⾏4当⽆状态的概念出来以后，web这⼀层就可以进⾏多次的横向扩展，这是第⼀次质的飞越后来⼈们觉得⼀个ngx也会出问题，就设计了主、备结构的ngx5 后来主、备ngx结构也不满⾜需求了，就在ngx前⾯加了⼀个lvs，lvs负责把请求转发给nginx这时nginx就解放出来了，不是主、备结构了，⽽是作为⼀个层级的结构，可以进⾏⽆限横向扩展；lvs这⾥是⼀个单点，它可以被设计成主、备的结构，⼀台挂了，另⼀台接管，但是不能横向扩展。
注意：lvs不能直接做负载集群，不能说⼀台不够了，再来⼀台，做不了负载集群，但是如果负载不够怎么办，它只能抗10到20万的访问量，怎么扩呢？可以⼀个ip放在⼀台lvs上，再来⼀个ip时放到另外⼀个lvs上边，⽤这种⽅式把它进⾏扩展；然后lvs本⾝的⾼可⽤怎么做呢，它做不了⾼负载，没法扩展它的吞吐量，但是⾼可⽤是可以做的，有主、备的结构，⼀个挂了，另⼀个接管，就可以了，实际上公司⾥边的做法，可以做两台lvs互为主、备，4个ip在⼀边，4个ip在另⼀边，两台共同提供业务，就做到了⾼负载，当⼀台出故障的时候，这个8个ip就可以集中到另外⼀台lvs上。
大型网站架构演变今日我们来谈谈一个网站普通是如何一步步来构建起系统的，虽然我们希翼网站一开头就能有一个很好的架构，但马克思告知我们事物是在进展中不断前进的，网站架构也是随着业务的扩大、用户的需求不断完美的，下面是一个网站架构逐步进展的基本过程，读完后，请思量，你现在在哪个阶段。
架构演化第一步：物理分别WebServer和数据库最开头，因为某些主意，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但因为这篇文章我们只关注架构的演化历程，因此就假设这个时候已经是托管了一台主机，并且有一定的带宽了。
这个时候因为网站具备了一定的特色，吸引了部分人拜访，逐渐你发觉系统的压力越来越高，响应速度越来越慢，而这个时候比较显然的是数据库和应用相互影响，应用出问题了，数据库也很简单浮现问题，而数据库出问题的时候，应用也简单出问题。
于是进入了第一步演化阶段：将应用和数据库从物理上分别，变成了两台机器，这个时候技术上没有什么新的要求，但你发觉的确起到效果了，系统又复原到以前的响应速度了，并且支撑住了更高的流量，并且不会由于数据库和应用形成相互的影响。
看看这一步完成后系统的图示：架构演化其次步：增强页面缓存好景不长，随着拜访的人越来越多，你发觉响应速度又开头变慢了，查找缘由，发觉是拜访数据库的操作太多，导致数据衔接竞争激烈，所以响应变慢。
但数据库衔接又不能开太多，否则数据库机器压力会很高，因此考虑采纳缓存机制来削减数据库衔接资源的竞争和对数据库读的压力。
这个时候首先大概会挑选采纳squ等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）举行缓存（固然，也可以采纳将页面静态化的计划），这样程序上可以不做修改，就能够很好的削减对WebServer的压力以及削减数据库衔接资源的竞争，OK，于是开头采纳squid来做相对静态的页面的缓存。
看看这一步完成后系统的图示：这一步涉及到了这些学问体系：前端页面缓存技术，例如squid，如想用好的话还得深化把握第1页共2页。
前言一个成熟的大型网站（如淘宝、京东等）的系统架构并不是开始设计就具备完整的高性能、高可用、安全等特性，它总是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。
所以成熟的系统架构是随业务扩展而完善出来的，并不是一蹴而就；不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯，要解决数亿的用户实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同。
尽管如此我们也可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段可以广泛运行在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。
一、最开始的网站架构最初的架构，应用程序、数据库、文件都部署在一台服务器上，如图：二、应用、数据、文件分离随着业务的扩展，一台服务器已经不能满足性能需求，故将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。
三、利用缓存改善网站性能在硬件优化性能的同时，同时也通过软件进行性能优化，在大部分的网站系统中，都会利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大部分网站访问都遵循28原则（即80%的访问请求，最终落在20%的数据上），所以我们可以对热点数据进行缓存，减少这些数据的访问路径，提高用户体验。
缓存实现常见的方式是本地缓存、分布式缓存。
当然还有CDN、反向代理等，这个后面再讲。
本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，OSCache就是常用的本地缓存组件。
本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。
分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。
