大型网站技术架构

网站都是从小网站一步一步发展为大型网站的，而这之中的挑战主要来自于庞大的用户、安全环境恶劣、高并发的访问和海量的数据，任何简单的业务处理，一旦需要处理数以 P 计的数据和面对数以亿计的用户时，问题就会变的很棘手

下面我们就来说说这个演变过程：

初始阶段

大型网站都是由小型网站演变而来的，网站架构也一样

小型网站最开始没有太多人访问，只需要一台服务器就绰绰有余，就像这样：

应用程序、数据库、文件等所有资源都在一台服务器上，通常使用 Linux PHP MySQL Apache 就可以完成整个项目部署，然后再买个域名，租一个廉价的服务器就可以开始我们的网站之旅了

应用服务与数据服务分离

随着业务的发展，逐渐的一台服务器已经不能满足需求，这时我们可以将 应用与数据分离

分离之后我们使用到三台服务器：应用服务器、文件服务器和数据库服务器，如下所示：

对于这三台服务器要求各不相同：

应用服务器
数据库服务器
文件服务器

应用与数据分离后，各个的职责变得更加专一，网站的性能得到进一步的提升，但随着用户的继续增加，我们需要对网站架构进一步优化

使用缓存改善性能

网站的访问一样遵循二八定律：80% 的业务访问集中在 20% 的数据上面

因此我们要对这一小部分的数据进行缓存来减轻数据库的访问压力，以提高整个网站的数据访问速度，改善数据库的读写性能

网站的缓存可以分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存

本地缓存
远程分布式缓存

如下所示：

使用缓存后，数据访问压力得到了有效的缓解，但单一的应用服务器能够处理的请求连接数有限，在访问的高峰期，应用服务器又会成为网站性能的瓶颈

使用应用服务器集群改善网站并发处理能力

使用集群是网站解决高并发，海量数据问题的常用手段，当你纵向提升到一定程度后，那就该开始横向提升了

当一台服务器的处理能力不足时，与其换一台更强大的服务器，不如增加一台服务器去分担原有的服务器压力。对于大型网站而言，无论多么强大的服务器，都满足不了持续增长的业务需求，更高效的方式就是增加服务器来分担压力

对于网站架构而言，如果增添一台新的服务器可以改善负载压力，那么就可以使用同样的方式来应对源源不断的业务需求，从而实现系统的可伸缩性

通过负载均衡调度服务器，可以将用户请求分发到应用服务器集群里的任何一台服务器上，如果有更多的用户，可以增加更多的应用服务器，使应用服务器的负载压力不再成为网站的性能问题

数据库读写分离

在使用了缓存后，大多数的操作不经过数据库访问就能完成，但仍有一部分读操作（缓存访问未命中，缓存过期）和所有的写操作需要访问数据库，在网站的用户量达到一定时，数据库的负载问题就来了

目前大多数的数据库都支持主从热备份，通过配置两台服务器的主从关系，可以将一台数据库服务器的数据更新同步到另一台，网站利用这一功能，实现数据库读写分离，从而进一步改善数据库负载压力

应用服务器在写操作的时候，访问主数据库，主数据库通过主从复制机制把数据同步更新到从数据库，这样当应用服务器进行读操作的时候，就能访问从数据库获取数据

使用反向代理和 CDN 加速网站响应

CDN 和 反向代理 的基本原理都是缓存

CDN
反向代理

使用 CDN 和 反向代理 都是为了尽快返回给用户数据，一方面加快用户访问速度，另一方面也减轻了后端服务器的压力

使用分布式文件系统和分布式数据库系统

随着网站业务的继续发展，这时候就可以像分布式应用服务器一样，对数据库系统和文件系统进行分布式管理

分布式数据库 是网站数据库拆分的最后手段，一般我们可以采取业务分库，根据不同业务的数据库部署在不同的数据库服务器上

使用 NoSQL 和搜索引擎

这两个方式都是依赖于互联网的技术手段，应用服务器通过一个统一的数据访问模块来访问各种数据，从而减轻应用程序有多个数据源的麻烦

业务拆分

对于大型网站，我们可以分而治之，把整个网站的业务分为不同的模块，比如大型的交易购物完整可以分为首页、店铺、订单、买家等，分别交给不同的业务团队来负责

同时我们将一个网站根据模块划分拆分成多个应用，每个应用进行单独的部署和维护，应用之间通过超链接建立关系（指向不同的应用地址），最后通过相同的数据存储系统来构成一个互相关联的完整系统

分布式服务

随着业务拆分，整个系统越来越大，应用的整体复杂度呈指数级增加，部署维护越来越困难，并且所有的应用服务器都要与数据库服务连接， 在数万台服务器规模的情况下，这些连接的数目是服务器规模的平方，导致资源不足

这时候就要对相同的业务进行提取，独立部署，把这些可重用的业务和连接数据库等，提取出来作为公共业务服务，而应用系统只需要通过分布式服务访问公共业务服务完成业务操作

到这里，基本上大多数的技术问题都能得到解决，还有一些实时同步等具体业务问题也都可以通过现有的技术解决

为了使网站的能够应对高并发访问，海量数据处理，高可靠运行等一系列问题，我们可以选择横向或纵向两个方向来入手

基本思路

首先可以对整个架构进行分层，一般可以分为 应用层 ， 服务层 ， 数据层 ；实践中，大的分层结构中还可以继续分层，比如 应用层 还可以继续分为 视图层 和 业务逻辑层 ，服务层也可以继续细分为 数据接口层 逻辑处理层 等

通过分层，我们把一个庞大的系统切分为不同的部分，便于分工开发和维护；各层之间相互有一定的独立性，在网站的开发中可以根据不同的需求进行相应的调整

逻辑上分层之后，在物理部署上也可以根据需求制定不同的策略，刚开始可以部署在同一台物理机上，但是随着业务的发展，必然要对不同的模块进行分离部署

分层架构不仅仅是为了规划软件的逻辑结构以便于开发维护，随着网站的发展，分层架构对网站的高并发分布式架构来说尤为重要

进行了分层以后，接下来可以从纵向进行业务分割

根据不同的业务模块一个项目划分成不同的模块交给单独的团队去开发部署，完成后分别部署在不同的服务器上，通过链接进行互联

再根据不同情况来对不同的节点进行冗余来保证网站的高可用性

接下来进行缓存，CDN，反向代理等等的优化，这里以后再细说

好了，现在我们开始进入正题

架构要素

首先，对于一个高访问量，大数据量的网站我们需要考虑什么呢？

性能

首先就是性能了，性能是一个网站的的重要指标，除非是没得选择，就这一个网站，不然用户是绝对不会忍受一个超级慢的网站

正因为性能问题无处不在，解决性能问题的方式也各种各样，从用户请求一个 url 开始，进行的每一个环节都可以进行优化；根据上面的分层，可以大致从三个方面进行优化，应用层优化，服务层优化，数据层优化

涉及到的知识就是 web 前端的优化，应用服务器端的优化和数据的存储，索引，缓存等，这些在后面的内容里会分别展开细说

但性能只是一个网站的必要条件，除此之外，因为无法预知网站可能会面临的压力或是攻击，我们还要保证网站在各种情境下（高并发，高负载，持续压力不均匀等）保持稳定的性能

可用性

对于大型网站而言，出现宕机的情况是可怕的，因为你可能有上千万的用户量，短短几分钟的宕机都有可能导致网站声誉扫地，如果是电商类的网站，更可能会导致用户的财产损失，甚至会摊上官司，那时候损失的就不仅是金钱和用户了

因此我们要保证能够提供每天 24 小时的可用，但实际中服务器并不能保证每天 24 小时都能平稳的运行，可能出现硬件问题，也可能出现软件问题，总之问题总是会有的

所以我们高可用设计的目标就是在某些服务器宕机的情况下，也能够保证服务或应用正常运行

网站高可用的主要手段是 冗余 ，应用部署在多台服务器上同时提供访问，数据存储在多台数据服务器之间互相进行热备份，这样任何一台服务器宕机都不会影响服务或应用的整体，也不会产生数据丢失

对于应用服务器而言，多台应用服务器通过一个负载均衡设备组成一个集群同时对外提供服务，当一台服务器宕机后，服务切换到其他服务器上继续执行，这样就可以保证了网站的高可用性，前提是应用服务器不允许存储用户会话信息，否则将会丢失，这样即使用户请求转接到其他服务器上面也无法继续执行

对于数据存储服务器，要提供服务器之间的实时备份，这样当一台服务器宕机的时候，将数据访问切换到其他服务器上，并进行数据恢复和备份

衡量一个系统架构设计是否满足高可用的目标，就是假设其中一台或多台服务器宕机以及出现各种不可预期的问题时，系统整体是否依然可用

伸缩性

面对着大量用户的高并发访问和海量的数据存储，不可能只用一台服务器就能够满足全部需求，存储全部数据

通过 集群 的方式将多台服务器组成一个整体共同提供服务，所谓 伸缩性 就是指通过不断向集群中加入服务器的手段来应对不断上升的用户并发访问压力和不断增长的数据存储需求

对于应用服务器集群，只要服务器上不存储数据，所有的服务器都是对等的，通过使用合适的负载均衡设备就可以向集群中不断加入新的服务器

对于缓存服务器而言，加入新的服务器可能会导致缓存路由失效，从而导致大部分的缓存数据都无法访问，需要改进缓存路由算法来保证缓存数据可访问

关系数据库虽然支持数据复制，主从热备份等机制，但是很难实现大规模集群的可伸缩性

可扩展性

网站的扩展性直接关系到网站功能模块的开发，网站快速发展，功能也不断的增加

网站架构的可扩展性的主要目的是使其能够快速的应对需求变化

是为了能够在增加新业务时，尽量实现对现有产品无影响，不需要改动或是改动很少现有业务就能够上线新产品；不同的产品业务之间的耦合度很小，一个产品或业务的改动不会对其他造成影响

大型网一定会吸引到第三方开发者，调用网站服务，开发周边产品，扩展网站业务，这都需要网站提供开放平台接口

安全性

最后的就是安全性了，互联网是一个开放的平台，任何人在任何地方都可以访问网站，安全架构就是保护网站不受恶意的访问和攻击，保护数据不被窃取

性能，可用性，伸缩性，扩展性，安全性使网站架构的几个核心要素，我们网站架构的目的主要就是为了解决这几个问题，接下来都会分别进行介绍

高性能架构

说到高性能，在不同角色的眼中对于性能的定义也不同

• 用户视角： 用户感受到的性能，就是从提交后到看到页面的时间，不同计算机性能的差异，不同浏览器解析 HTML 的速度，不同网络提供商提供的互联网服务的速度，这些差异都会导致实际时间远大于服务器处理请求的时间
  实践中，我们可以用一些前端架构优化的手段，通过优化 HTML 样式，利用浏览器异步和并发的特性，调整缓存策略，使用 CDN 服务，反向代理等，使用户能够尽快的看到内容，即使不对应用服务优化，也能够很好地改善用户体验
• 开发者视角： 开发者更关注的是应用服务器的性能，包括响应延迟，系统吞吐量，并发处理，系统稳定性等> 主要优化手段可以利用缓存加速数据读取，使用集群提高吞吐量，使用异步加快请求响应，优化代码改善程序等
• 运维人员视角： 对于运维人员，会更关注一些基础设施的性能和利用率，这里不再多说

性能测试指标

主要的性能测试指标有 响应时间 并发数 吞吐量 性能计数器 等

性能测试方法

性能测试是一个统称，具体可以分为 性能测试 ， 负载测试 ， 压力测试 ， 稳定性测试

• 性能测试
  以初期设计的指标为预期目标，不断对系统施压，看系统在预期的范围内，能否达到预期的性能
• 负载测试
  对系统不断增加并发请求以增加系统压力，直到系统某项或多项指标达到安全临界值，这时继续对系统施加压力，系统的处理能力会有所下降
• 压力测试
  在超过安全负载的情况下，继续施压，直到系统崩溃或不再能够处理任何请求，以此来计算系统的最大压力承受能力
• 稳定性测试
  在一定的压力（不均匀施压）下，系统能够稳定的运行较长时间

如上图所示，a-b 区间内就是网站日常的运行区间，绝大多数时间都处于这一区间内；而 c 点相当于系统的最大负载点，b-c 段就是因某些原因访问量超过了日常访问压力；超过了 c 点后，继续增加压力，这时候系统的性能就开始下降，但是资源消耗会更多，直到 d 点，系统的崩溃点，超过这个点继续加压的话，系统将不能处理任何请求

性能测试反映的是系统的处理能力，与其对应的是用户的等待时间（响应时间），如下如所示：

各点与上面的性能测试图都相互对应，直到系统崩溃，用户失去响应

性能优化策略

首先要定位问题产生原因，排查不同环节的日志，分析哪个环节的响应时间与预期不相符，然后分析影响性能的原因，是代码问题还是架构设计不合理，或者系统资源不足

然后就是性能优化，根据网站的分层架构，可以大致的分为 web 前端性能优化，应用服务器性能优化，存储服务器性能优化三大类

具体的优化方法我们下篇再继续

———-=======——-

根据网站的分层架构，可以大致的分为 web 前端性能优化，应用服务器性能优化，存储服务器性能优化三大类

这次来说一下 web 前端性能优化，一般来说，web 前端就是应用服务器处理之前的部分，包括浏览器渲染、加载，前端视图模型，图片视频资源， CDN 服务等，主要优化方法就是优化浏览器访问渲染过程，使用反向代理，使用 CDN 服务等

浏览器访问渲染优化

减少 http 请求数

http 协议是无状态的应用层协议，每次 http 请求都会建立新的通信链路，并且在服务端，每个 http 连接都会开启一个单独的线程去处理请求，这都会产生额外的开销

主要手段就是去合并压缩 css，JavaScript，图片文件，把需要的 css，JavaScript，图片资源进行合并减少建立的连接请求数

同时使用 http 的 keep-alive 来进行连接的复用，以此来减少建立的 http 连接数，提高访问性能

启用压缩

在服务端进行文件的压缩，减少通信传输过程中的数据量

对于文本文件，压缩率能够达到 80% 以上，因此在服务端启用 gzip 压缩是一个很好的选择，但启用压缩的同时也会给服务器带来额外的开销，所以要具体情况具体分析

css，JavaScript 代码优化

• css 代码优化：
  • 尽量使用外部样式，并且放在页面顶部加载，一方面能够及时渲染，另一方面能够避免因某些样式导致阻塞渲染
  • 压缩合并 css 文件，尽量精简文件，减少通信传输数据量和请求连接数
• JavaScript 代码优化：
  • 因为 JavaScript 代码边加载边解析，解析的过程会阻塞浏览器渲染，因此把 JavaScript 代码放在页面底部加载
  • 同样的压缩合并 JavaScript 文件，尽量精简文件，减少通信传输数据量和请求连接数
  • 写高性能的 JavaScript 代码

使用浏览器缓存

一般来说，对于网站里面不经常变化的静态资源，更新频率比较低，因此可以把这些资源缓存在浏览器中，能够很好的改善性能

通过设置 http 头里的 Cache-Control 和 Expires 属性来设定浏览器缓存时间

另外还有 Etags 和 opcode 的缓存，根据具体情况进行选择吧

CDN 加速

CDN 的本质也属于缓存，内容分发网络，把数据缓存在里用户近的地方，使用户尽快的获取数据

因为 CDN 都是部署在网络运营商的机房，这些运营商又同时为用户提供网络服务，因此用户请求的路由会优先到达 CDN 服务器，如果存在请求的资源的话，就直接返回，最短路径返回响应，加速用户访问速度，同时还能够为中心机房减轻压力

CDN 一般用来缓存静态资源，css，Script 脚本，静态页面，图片等，这些内容修改频率很低但是访问请求频率很高，因此放在 CDN 上能够很好的改善访问速度

反向代理

传统的代理服务器是当你请求不到所请求的资源时，由代理服务器帮你请求，你知道你请求的最终的服务器是谁，典型的例子就是 VPN ，通过代理服务器来请求到墙外的世界

而反向代理是当你请求一个地址时，你请求的是反向代理服务器，然后由反向代理服务器去请求其他服务器来获取内容，而你不知道最终是从哪一台服务器获取到的数据

反向代理 web 服务器接收 http 请求，然后进行请求转发，获取到内容后返回给你，你只知道是由反向代理服务器给你的数据，而不知道数据源最终是从哪个服务器来的

反向代理服务器具有保护作用，来自互联网的请求都需要经过反向代理服务器，相当于在 web 服务器之间建立起了一道屏障

除了安全以外，可以在反向代理服务器上进行一些静态资源的缓存，以此来提高访问速度，减轻应用服务器的负载压力

当然，有些动态资源也可以缓存在代理服务器上面，比如说热门的词条，帖子，博客等，这些资源的请求量可能非常非常的大，如果每次都走一遍流程的话会造成很大的压力，同时，当这些动态内容发生改变时，会通知反向代理服务器缓存失效，代理服务器会重新缓存动态资源

除此之外，反向代理服务器还可以用来做负载均衡，通过负载均衡来构建服务器集群，以此来提高系统的总体处理能力，进而应用提高服务器处理高并发的能力

PS：使用 ajax 也是提高用户体验很好的方法，不过 ajax 对于 SEO 并不友好，所以需要用到 SEO 的地方还是要考虑好是否要用 ajax

好了，关于 web 前端优化就写到这里，下次会继续写应用服务器性能优化，存储服务器性能优化

来源： https://segmentfault.com/a/1190000007390358