浅谈web架构之演化过程

ゞ浴缸里的玫瑰 2022-09-25 01:16 168阅读 0赞

# **前言** #

最近在开发过程中，遇到很多缓解配置的问题，工程很难启动，也不知道为什么环境需要这么多配置的意义。就在这个时候，一本好书《大型网站技术：核心原理与案例分析》给我带来全新视角，必须强势安利一把。[链接地址][Link 1]

本文先浅谈书中所提到的web架构演化过程。如果经历的项目足够多，是会深有体会的。

--------------------

# **大型网站特点** #

1.高并发，大流量  
2.高可用  
3.海量数据  
4.用户分布广泛，网络情况复杂  
5.安全环境恶劣  
6.需求快速变更，发布频繁，产品发布频率是极高的  
7.渐进式发展。好的互联网产品都是慢慢运营出来的，不是一开始就开发好的。

--------------------

# **演化过程** #

## **初始阶段** ##

一台服务器就绰绰有余。  
服务器操作系统用Linux，应用程序使用PHP开发，部署在apache上，数据库使用Mysql。汇集各种免费开源软件及一台廉价服务器就可以开始网站的发展之路了。

[![img][]][img]

回想起自己在学校做过的项目，差不多就是这么个级别。

## **应用服务和数据服务分离** ##

三台服务器：**应用服务器、文件服务器和数据库服务器**。

**应用服务器**需要处理大量的逻辑，所以需要强大的CPU；  
**数据库服务器**需要快速磁盘检索和数据缓存，所以需要更大的内存和更快的硬盘；  
**文件服务器**需要存储大量用户上传的文件，所以需要更大的硬盘。

[![img][img 1]][img 1]

## **使用缓存改善网站性能** ##

随着用户量逐渐增大，数据库压力太大导致访问延迟，进而影响整个网站的性能。需要进行改进。  
先了解下**二八定律**：**80%的业务访问集中在20%的数据上**。所以我们可以把这一小部分数据缓存在内存中，从而减小数据库的访问压力。

缓存分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式服务器上的远程缓存。**本地缓存**的访问速度更快，但是受应用服务器内存限制，数据大小有限。**远程缓存**可以以集群的方式，部署大内存的服务器作为专门的缓存服务器。

[![img][img 2]][img 2]

这也就是为什么开发过程中测试环境发布了之后，前端资源有可能未立即奏效的原因。服务器设置了本地缓存，需要待其过期才行。至于浏览器端的http缓存，可以看看[这篇文章][Link 2]

## **应用服务器集群改善并发能力** ##

网站性能得到解决后，在网站访问高峰期，应用服务器成为整个网站的瓶颈。  
对于网站架构而言，只要能通过增加一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性。  
通过**负载均衡调度服务器**，进行负载均衡。如果很更多的用户，就在集群中加入更多的应用服务器，使应用服务器的负载压力不再成为整个网站的瓶颈。

[![img][img 3]][img 3]

至于负载均衡有哪些方式，以后会具体讲到。

## **数据库读写分离** ##

使用缓存后，还是有一部分读操作和所有的写操作需要经过数据库服务器。用户达到一定规模后，数据库因为负载压力过高会成为网站的瓶颈。

利用主流数据库自带的**主从热备功能**，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上，从而实现读写分离。

[![img][img 4]][img 4]

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

CDN和反向代理的基本原理都是缓存，**区别**在于CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；  
而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，而如果，就将其直接返回给用户。

[![img][img 5]][img 5]

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

分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。不到万不得已的时候，网站更加常用的数据库拆分手段是**业务分库，将不同业务的数据库部署在不同的物理服务器**上。

[![img][img 6]][img 6]

## **使用NoSQL和搜索引擎** ##

随着业务越来越复杂，对数据存储和检索的需求也越来越复杂。

[![img][img 7]][img 7]

## **业务拆分** ##

大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段**将整个网站业务分为不同的产品线，分归不同的业务团队负责**。  
各应用之间可以**通过一个超链接建立关系**，也可以通过**消息队列进行数据分发**，当然最多的还是通过**访问同一数据存储系统来构成一个关联的完整系统**。

[![img][img 8]][img 8]

## **分布式服务** ##

如果服务器数据过多，各种连接关系会很复杂，数据库连接资源不足，拒绝服务。  
每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等。那么可以**将这些共用的业务提取出来，独立部署**。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，**通过分布式服务调用共用业务服务完成具体业务操作**。

[![img][img 9]][img 9]

像笔者所处的开发部门，就把订单流程、登陆等功能单独抽出作为公共服务，这样移动端、PC端都可以调用复用服务。

--------------------

# **小结** #

本文只是简单的说了下书中所讲到的网站发展过程的基本流程。但是笔者观望下自己所处的环境，发现既然全部都有用到。说明实用性确实很强。值得学习。

[Link 1]: http://note.youdao.com/yws/public/redirect/share?id=4ae9da1f642031f64d8c0525d7cdaef6&type=false
[img]: http://brizer.github.io/2016/07/08/%E6%B5%85%E8%B0%88web%E6%9E%B6%E6%9E%84%E4%B9%8B%E6%BC%94%E5%8C%96%E8%BF%87%E7%A8%8B/1.jpg
[img 1]: http://brizer.github.io/2016/07/08/%E6%B5%85%E8%B0%88web%E6%9E%B6%E6%9E%84%E4%B9%8B%E6%BC%94%E5%8C%96%E8%BF%87%E7%A8%8B/2.jpg
[img 2]: http://brizer.github.io/2016/07/08/%E6%B5%85%E8%B0%88web%E6%9E%B6%E6%9E%84%E4%B9%8B%E6%BC%94%E5%8C%96%E8%BF%87%E7%A8%8B/3.jpg
[Link 2]: http://brizer.github.io/2016/05/25/%E5%88%9D%E6%AD%A5%E5%AD%A6%E4%B9%A0http%E7%BC%93%E5%AD%98%E6%9C%BA%E5%88%B6/
[img 3]: http://brizer.github.io/2016/07/08/%E6%B5%85%E8%B0%88web%E6%9E%B6%E6%9E%84%E4%B9%8B%E6%BC%94%E5%8C%96%E8%BF%87%E7%A8%8B/4.jpg
[img 4]: http://brizer.github.io/2016/07/08/%E6%B5%85%E8%B0%88web%E6%9E%B6%E6%9E%84%E4%B9%8B%E6%BC%94%E5%8C%96%E8%BF%87%E7%A8%8B/5.jpg
[img 5]: http://brizer.github.io/2016/07/08/%E6%B5%85%E8%B0%88web%E6%9E%B6%E6%9E%84%E4%B9%8B%E6%BC%94%E5%8C%96%E8%BF%87%E7%A8%8B/6.jpg
[img 6]: http://brizer.github.io/2016/07/08/%E6%B5%85%E8%B0%88web%E6%9E%B6%E6%9E%84%E4%B9%8B%E6%BC%94%E5%8C%96%E8%BF%87%E7%A8%8B/7.jpg
[img 7]: http://brizer.github.io/2016/07/08/%E6%B5%85%E8%B0%88web%E6%9E%B6%E6%9E%84%E4%B9%8B%E6%BC%94%E5%8C%96%E8%BF%87%E7%A8%8B/8.jpg
[img 8]: http://brizer.github.io/2016/07/08/%E6%B5%85%E8%B0%88web%E6%9E%B6%E6%9E%84%E4%B9%8B%E6%BC%94%E5%8C%96%E8%BF%87%E7%A8%8B/9.jpg
[img 9]: http://brizer.github.io/2016/07/08/%E6%B5%85%E8%B0%88web%E6%9E%B6%E6%9E%84%E4%B9%8B%E6%BC%94%E5%8C%96%E8%BF%87%E7%A8%8B/10.jpg