大型网站技术架构演变_互联网_IT计算机_专业资料(1)PPT课件
大型网站技术架构方案专业知识讲座
开发框架 多层设计 业务分割 。。。
本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不 当之处，请联系本人或网站删除。
网站架构各子系统介绍
Web前 端系统 负 载均衡系统 数 据库集群系统 缓 存系统 分 布式存储系统 分 布式服务器管理系统 代 码分发系统
SVN: 管理方便，逻辑明确，符合一般人思维习惯； 易于管理，集中式服务器更能保证安全性； 代码一致性非常高，更新速度快； 适合开发人数不多的项目开发； 学习成本低，快速上手
Rsync (remote sync) 可以镜像保存整个目录树和文件系统； 可以很容易做到保持原来文件的权限、时间、软硬链接等等； 无须特殊权限即可安装; 快速、安全、支持匿名传输，以方便进行网站镜象。
7
本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不
负载均衡系当统之处，: 请N联g系i本n人x或网站删除。
Http server Reverse Proxy Mail server LB server: >50,000 connection Bug free 7*24 Easy to upgrade …
本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不
负载均衡系统 当之处，请联系本人或网站删除。
大型网站解决高负荷访问和大量并发请求采用的 终极解决办法
代码分发系统: SVN + Rsync 本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不 当之处，请联系本人或网站删除。
本文档所提供的信息仅供参考之用，不能作为科学依据，请勿模仿。文档如有不 当之处，请联系本人或网站删除。
大型网站架构演变和知识体系
也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，
于是开始采用squid来做相对静态的页面的缓存。
第一步：物理分离webserver和数据库
由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段：将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更高的流量，并且不会因为数据库和应用形成互相的影响。
经过上面这个漫长而痛苦的过程，终于是再度迎来了完美的时代，不断的增加we，人气的重要毋庸置疑，随着人气的越来越高，各种各样的功能需求也开始爆发性的增长，这个时候突然发现，原来部署在webserver上的那个web应用已经非常庞大了，当多个团队都开始对其进行改动时，可真是相当的不方便，复用性也相当糟糕，基本是每个团队都做了或多或少重复的事情，而且部署和维护也是相当的麻烦，因为庞大的应用包在N台机器上复制、启动都需要耗费不少的时间，出问题的时候也不是很好查，另外一个更糟糕的状况是很有可能会出现某个应用上的bug就导致了全站都不可用，还有其他的像调优不好操作（因为机器上部署的应用什么都要做，根本就无法进行针对性的调优）等因素，根据这样的分析，开始痛下决心，将系统根据职责进行拆分，于是一个大型的分布式应用就诞生了，通常，这个步骤需要耗费相当长的时间，因为会碰到很多的挑战：
大型网站技术架构演变
分布式数据库及文件架构，就应用程序而言，不透明 一般需要与集群式、分布式架构中作出权限后才决定方案
使用NOSQL和搜索引擎
• •
数据存储和检索需求越来越复杂 传统关系型技术无法满足需求（存储、速度）
• • •
数据交互能力大大提升 一般都会涉及集群架构 对持久化、ACD需要有折冲
业务拆分
• • •
大型网站业务场景复杂，需要分而治之地解决不同业务（产品线问题）问题 根据业务划分多个不同产品线及板块，由不同业务团队负责，并最终提供不同服务 不同应用独立部署，通过链接、消息队列、接口服务进行交互通讯，最多的是通过共享同一存储系统实现关联
• 性能减弱
• •
可用性提升 维护更容易，项目更简单
分布式服务
•
•
请求再多也能通过扩展支撑
数据库读写分离
• •
存在不能缓存的情况多，数据库写入也不少的情况下，数据库负载压力成为网站瓶颈 利用热备功能，配置主-从关系，实现读-写分离，分摊单一节点数据库压力
•
利用独立数据库访问模块，实现读写分离调度，对应用透明 读、写分离调度模块，可以是独立硬件，也可以程序级调度 程序 主-从复制基于时间调度（简单但不够实时）或事件调度 （复杂但相对精准）
大型网站技术架构演变
黄若儒
大型网站软件系统的特点
• 高并发、大流量——需要面对高并发用户，大流量访问。 • 高可用——系统7x24小时不间断服务。 • 海量数据——需要存储、管理海量数据，需要使用大量服务器。 • 用户分布广泛，网络情况复杂——需要为全球范围的用户提供服务。 • 安全环境恶劣——互联网开放性，导致更容易受到攻击。 • 需求快速变更，发布频繁——需要快速适应市场，满足用户需求。 • 渐进式发展——没有全盘一篮子规划，只有基于实际的无限变更发展
大型网站系统架构演化之路
大型网站系统架构演化之路前言一个成熟的大型网站(如淘宝、天猫、腾讯等)的系统架构并不是一开始设计时就具备完整的高性能、高可用、高伸缩等特性的，它是随着用户量的增加，业务功能的扩展逐渐演变完善的，在这个过程中，开发模式、技术架构、设计思想也发生了很大的变化，就连技术人员也从几个人发展到一个部门甚至一条产品线。
所以成熟的系统架构是随着业务的扩展而逐步完善的，并不是一蹴而就;不同业务特征的系统，会有各自的侧重点，例如淘宝，要解决海量的商品信息的搜索、下单、支付，例如腾讯，要解决数亿用户的实时消息传输，百度它要处理海量的搜索请求，他们都有各自的业务特性，系统架构也有所不同。
尽管如此我们也可以从这些不同的网站背景下，找出其中共用的技术，这些技术和手段广泛运用在大型网站系统的架构中，下面就通过介绍大型网站系统的演化过程，来认识这些技术和手段。
一、最开始的网站架构最初的架构，应用程序、数据库、文件都部署在一台服务器上，如图：二、应用、数据、文件分离随着业务的扩展，一台服务器已经不能满足性能需求，故将应用程序、数据库、文件各自部署在独立的服务器上，并且根据服务器的用途配置不同的硬件，达到最佳的性能效果。
三、利用缓存改善网站性能在硬件优化性能的同时，同时也通过软件进行性能优化，在大部分的网站系统中，都会利用缓存技术改善系统的性能，使用缓存主要源于热点数据的存在，大部分网站访问都遵循28原则(即80%的访问请求，最终落在20%的数据上)，所以我们可以对热点数据进行缓存，减少这些数据的访问路径，提高用户体验。
缓存实现常见的方式是本地缓存、分布式缓存。
当然还有CDN、反向代理等，这个后面再讲。
本地缓存，顾名思义是将数据缓存在应用服务器本地，可以存在内存中，也可以存在文件，OSCache就是常用的本地缓存组件。
本地缓存的特点是速度快，但因为本地空间有限所以缓存数据量也有限。
分布式缓存的特点是，可以缓存海量的数据，并且扩展非常容易，在门户类网站中常常被使用，速度按理没有本地缓存快，常用的分布式缓存是Memcached、Redis。
互联网架构的演变过程（一）
互联⽹架构的演变过程（⼀）简介web1.0时代web2.0时代互联⽹时代互联⽹+ --》智慧城市。
2012年提出。
云计算+⼤数据时代背景随着互联⽹的发展，⽹站应⽤的规模不断扩⼤，常规的垂直应⽤架构已⽆法应对，分布式服务架构以及流动计算架构势在必⾏，亟需⼀个治理系统确保架构有条不紊的演进。
1、第⼀时期单⼀应⽤架构all in one(所有的模块在⼀起，技术也不分层)⽹站的初期，也认为互联⽹发展的最早时期。
会在单机部署上所有的应⽤程序和软件。
所有的代码都是写在JSP⾥⾯，所有的代码都写在⼀起。
这种⽅式称为all in one。
特点：1、不具备代码的可维护性。
2、容错性差。
因为我们所有的代码都写在JSP页⾥。
当⽤户或某些原因发⽣异常。
（1、⽤户直接看到异常错误信息。
2、这个错误会导致服务器宕机）容错性，是指软件检测应⽤程序所运⾏的软件或硬件中发⽣的错误并从错误中恢复的能⼒，通常可以从系统的可靠性、可⽤性、可测性等⼏个⽅⾯来衡量。
单体地狱。
:只需⼀个应⽤，将所有功能都部署在⼀起，以减少部署节点和成本。
2 第⼀时期后阶段解决⽅案:1、分层开发（提⾼维护性）【解决容错性】2、MVC架构（Web应⽤程序的设计模式）3、服务器的分离部署特点：1、MVC分层开发（解决容错性问题）2、数据库和项⽬部署分离问题：随着⽤户的访问量持续增加，单台应⽤服务器已经⽆法满⾜需求。
解决⽅案：集群。
3 可能会产⽣的⼏个问题：1.1. ⾼可⽤“⾼可⽤性”（High Availability）通常来描述⼀个系统经过专门的设计，从⽽减少停⼯时间，⽽保持其服务的⾼度可⽤性。
(⼀直都能⽤)1.2. ⾼并发⾼并发（High Concurrency）是互联⽹分布式系统架构设计中必须考虑的因素之⼀，它通常是指，通过设计保证系统能够同时并⾏处理很多请求。
⾼并发相关常⽤的⼀些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），并发⽤户数等。
大型网站架构
大型网站架构演变之前也有一些介绍大型网站架构演变的文章，例如LiveJournal的、ebay的，都是非常值得参考的，不过感觉他们讲的更多的是每次演变的结果，而没有很详细的讲为什么需要做这样的演变，再加上近来感觉有不少同学都很难明白为什么一个网站需要那么复杂的技术，于是有了写这篇文章的想法，在这篇文章中 将阐述一个普通的网站发展成大型网站过程中的一种较为典型的架构演变历程和所需掌握的知识体系，希望能给想从事互联网行业的同学一点初步的概念，:-)，文中的不对之处也请各位多给点建议，让本文真正起到抛砖引玉的效果。
架构演变第一步：物理分离webserver和数据库最开始，由于某些想法，于是在互联网上搭建了一个网站，这个时候甚至有可能主机都是租借的，但由于这篇文章我们只关注架构的演变历程，因此就假设这个时候 已 经是托管了一台主机，并且有一定的带宽了，这个时候由于网站具备了一定的特色，吸引了部分人访问，逐渐你发现系统的压力越来越高，响应速度越来越慢，而这 个时候比较明显的是数据库和应用互相影响，应用出问题了，数据库也很容易出现问题，而数据库出问题的时候，应用也容易出问题，于是进入了第一步演变阶段： 将应用和数据库从物理上分离，变成了两台机器，这个时候技术上没有什么新的要求，但你发现确实起到效果了，系统又恢复到以前的响应速度了，并且支撑住了更 高的流量，并且不会因为数据库和应用形成互相的影响。
看看这一步完成后系统的图示：这一步涉及到了这些知识体系：这一步架构演变对技术上的知识体系基本没有要求。
架构演变第二步：增加页面缓存好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力，这个时候首先也许会选择采用squid 等类似的机制来将系统中相对静态的页面（例如一两天才会有更新的页面）进行缓存（当然，也可以采用将页面静态化的方案），这样程序上可以不做修改，就能够 很好的减少对webserver的压力以及减少数据库连接资源的竞争，OK，于是开始采用squid来做相对静态的页面的缓存。
大型网站架构一览(从底层到前端技术框架分析)
大型网站的挑战要紧来自庞大的用户，高并发的访问和海量数据，任何简单的业务一旦需要处置数以P计的数据和面对数以亿计的用户，问题就会变得棘手。
大型网站架构要紧确实是解决这种问题。
网站系统架构层次如以下图所示：一、前端架构前端指用户请求抵达网站应用效劳器之前经历的环节，通常不包括网站业务逻辑，不处置动态内容。
阅读器优化技术并非是优化阅读器，而是通过优化响应页面，加速阅读器页面的加载和显示，经常使用的有页面缓存、归并HTTP减少请求次数、利用页面紧缩等。
CDN内容分发网络，部署在网络运营商机房，通过将静态页面内容分发到离用户最近最近的CDN效劳器，利用户能够通过最短途径获取内容。
动静分离，静态资源独立部署静态资源，如JS、CSS等文件部署在专门的效劳器集群上，和Web应用动态内容效劳分离，并利用专门的（二级）域名。
图片效劳图片不是指网站Logo、按钮图标等，这些文件属于上面提到的静态资源，应该和JS、CSS部署在一路。
那个地址的图片指用户上传的图片，如产品图片、用户头像等，图片效劳一样适用独立部署的图片效劳器集群，并利用独立（二级）域名。
反向代理部署在网站机房，在应用效劳器、静态资源效劳器、图片效劳器之前，提供页面缓存效劳。
DNS域名效劳，将域名解析成IP地址，利用DNS能够实现DNS负载均衡，配置CDN也需要修改DNS，使域名解析后指向CDN效劳器。
二、应用层架构应用层是处置网站要紧业务逻辑的地址。
开发框架网站业务是多变的，网站的大部份软件工程师都是在加班加点开发网站业务，一个好的开发框架相当重要。
一个号的开发框架应该能够分离关注面，使美工、开发工程师能够各司其事，易于协作。
同时还应该内置一些平安策略，防护Web用解决。
页面渲染将别离开发保护的动态内容和静态页面模板集成起来，组合成最终显示给用户的完整页面。
负载均衡将多台应用效劳器组成一个集群，通过负载均衡技术将用户请求分发到不同的效劳器上，以应付大量用户同时访问时产生的高并发负载压力。
大型网站的演变过程
⼤型⽹站的演变过程前⾔随着互联⽹的不断发展，以及⽹站负载的不断增⾼，⼀个成熟⽹站的架构需要满⾜下⾯的⼏点，才能为⽤户提供稳定可⽤的服务⾼并发、⼤流量：PV 量巨⼤；⾼可⽤：7*24 ⼩时不间断服务；海量数据：⽂件数⽬分分钟 xxTB；⽤户分布⼴泛，⽹络情况复杂：⽹络运营商；安全环境恶劣：⿊客的攻击；需求快速变更，发布频繁：快速适应市场，满⾜⽤户需求；渐进式发展：慢慢地运营出⼤型⽹站；⽬标解决了上述问题之后，我们需要达到⼀个什么样的⽬标和⽬的呢？每个⽬标背后⾯临着技术、设计、维护等诸多⽅⾯的挑战；⽽⽬标本⾝的期望值也会根据实际情况进⾏调整，这也意味着⽹站架构建设是个不断调整的过程。
有了问题，也定了伟⼤的⽬标，那么⽹站在不同阶段⾯对不同的问题，是如何解决的？⼜是如何⼀步步成长为⼤型⽹站架构，实现这些伟⼤的⽬标呢？架构体系演进1. 单机时代草根时期，快速开发⽹站并上线。
当然，通常只是先试⽔，⽤户规模也没有形成，经济能⼒和投⼊也⾮常有限。
应⽤程序、数据库、⽂件等所有资源都集中在⼀台 Server上，典型案例：基于 LAMP 架构的 PHP ⽹站；优点：简单、快速迭代达成业务⽬标；缺点：存在单点、谈不上⾼可⽤；技术点：应⽤设计要保证可扩展；2. 缓存出场当⽹站发展到有⼀定的业务量和⽤户规模，⽹站的访问速度变慢，主要瓶颈是在数据库上，所以此时再⽤草根时代的架构显然已经不能满⾜我们业务的需求了，那想提升⽹站速度，就需要解决数据库上的瓶颈，于是，缓存出场了。
单机时代+缓存优点：简单有效、⽅便维护；缺点：存在单点、谈不上⾼可⽤；技术点：客户端（浏览器）缓存、前端页⾯缓存、页⾯⽚段缓存、本地数据缓存/数据库缓存、远程缓存；缓存分类：页⾯缓存：客户端缓存，减少对⽹站的访问；本地缓存：访问速度快，但数据量有限，减少对DB查询；远程缓存：远程访问，可以集群，因此容量不受限制；3. 数据库和应⽤逻辑分离市场反响还不错，⽤户量每天在增长，数据库疯狂读写，逐渐发现⼀台服务器快撑不住了。