分布式基础(1)-大型网站架构演进过程

川长思鸟来 2023-07-14 05:29 39阅读 0赞

### 文章目录 ###

*   *   *  一.大型网站系统的特点
         *   *  1.大流量
             *  2.高并发
             *  3.高可用
             *  4.海量数据
             *  5.用户分布广泛
             *  6.网络情况复杂
             *  7.敏捷开发和快速迭代
             *  8.安全环境恶劣
         *  二.大型网站架构演进过程
         *   *  1.单机时代
             *  2.多机时代
             *  3.缓存时代
             *  4.集群时代
             *  5.读写分离时代
             *  6.反向代理与内容分发网络
             *  7.底层服务集群化
             *  8.搜索引擎技术与NoSQL
             *  9.服务拆分与微服务化

> 本文主要参考自《大型网站技术架构：核心原理与案例分析》一书第一章节和其他网络文章，如有遗漏或错误，还望海涵并指出。谢谢！

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70]

**这个世界没有哪个网站从诞生起就是大型网站；也没有哪个网站第一次发布就拥有庞大的用户，高并发的访问，海量的数据；大型网站都是从小型网站发展而来。网站的价值在于它能为用户提供什么价值，在于网站能做什么，而不在于它是怎么做的，所以当网站还很小的时候就去追求网站的架构是逐本舍末，得不偿失的。小型网站最需要做的就是去为用户提供好的服务来创造价值，得到用户的认可，活下去，野蛮生长 。  
–《大型网站技术架构：核心原理与案例分析》**

### 一.大型网站系统的特点 ###

互联网发展二十年来，越来越多的网站正在崛起，许多网站从一开始的小流量、小并发的模式发展到现在的巨大流量与高并发模式，期间有着许多的技术架构演进过程，典型的例子有淘宝网、FaceBook、微博等网站和系统，所以研究和学习大型网站技术架构的演进过程是十分有必要的。

以淘宝网为例，这种大型的网站系统具有一下特点：

#### 1.大流量 ####

淘宝网2018年的年度活跃人数为5.8亿人，每天都有千万至亿级用户在使用，所有流量巨大。

#### 2.高并发 ####

以双十一为例，仅在双十一开启的一秒钟之内就产生了百亿的钱款流水，用户并发请求巨大。

#### 3.高可用 ####

淘宝网每时每刻都会产生大量的订单，如果不能够保障24小时的持续服务，那么会对用户和淘宝店家等产生重大的影响，此时需要服务器具备高可用性，提供99.9999%（一年中的99.99999%的时间）的可用时间。

#### 4.海量数据 ####

每天的订单数据或者是用户数据、店家数据等十分地巨大，以P为基本单位，需要上万台服务器来对数据进行存储。

#### 5.用户分布广泛 ####

淘宝网具有大量的国内用户和海外用户，所以用户的分布是十分广泛的。

#### 6.网络情况复杂 ####

网络的情况受地域的影响，例如国内用户无法访问国外的某些服务器资源，各个运营商还具有网络互通的难题。

#### 7.敏捷开发和快速迭代 ####

由于用户的需求或行业的走向、热点等都会随时发生变化，所以大型网站有敏捷开发和快速迭代的需要。

#### 8.安全环境恶劣 ####

因为树大招风，越是大的网站和系统，黑客的攻击也越多，所处的安全环境也越恶劣，所以如何处理安全问题也是一个很重要的点。

### 二.大型网站架构演进过程 ###

可以简单地将大型网站架构演进的过程分为以下几个"时代"，每个时代都解决了当前急需解决的问题。

#### 1.单机时代 ####

在网站创立的初期，由于用户量级小、请求少、低并发，所以一般是采取了将应用程序、文件服务（如图片存储）和数据库都放在一台服务器中，例如现在许多小型的网站都采用了LAMP的技术架构（Liunx + Apache + MySQL + PHP）部署单机系统。这个时候使用这种单机架构是可以支撑得住的，一般的个人网站或企业系统普遍使用了这种技术架构，这是最简单的一种技术架构。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 1]

#### 2.多机时代 ####

随着网站的发展，一台服务器中的数据越来越多，导致磁盘IO变得缓慢，所以此时出现了将应用程序和文件存储系统、数据库分成多台服务器来部署的架构，这样就可以让不同的服务器各司其职，例如在CPU更好、处理速度更快的服务器上部署应用程序，而在磁盘IO快的服务器上部署数据库，在磁盘空间大的服务器部署文件系统。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 2]

#### 3.缓存时代 ####

当网站发展得越来越好，请求越来越多时，大量的请求使得数据库处理不过来甚至是阻塞、宕机，延迟越来越大，此时的做法是引入缓存。

**首先要明确的是，系统的请求也符合二八定律，即八成的请求会集中在二成的数据集上，例如淘宝网大部分的请求都是浏览商品的请求，而小部分的请求为买家修改资料，所以此时要区分出热数据和冷数据，将对于热数据的大部分请求下发到缓存中，而不是直接请求到数据库上，从而提升了请求响应速度和降低数据库的访问压力。**

缓存可以分为远程缓存和本地缓存，例如Redis就可以部署在专用的缓存服务器中当作远程缓存，而ehcache技术可以用来作为本地缓存，使一部分缓存位于应用服务器上。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 3]

#### 4.集群时代 ####

当缓存问题解决后，数据库不再承受大的压力，但是对于应用服务器来说还是需要继续承受着很大的压力的，此时出现了应用程序大量并发请求下的瓶颈，也许是因为服务器自身带宽不够或服务器自身能处理的连接请求有限，此时有两种选择：

**垂直拓展：继续选择带宽更大、处理器更好的服务器来部署应用程序，但是无论配置多好的服务器，终会有配置不够用的时候，所以可以选择水平拓展。**

**水平拓展：既然一台服务器能够处理的请求是有限的，那么为什么不可以通过拓展更多的机器来处理更多的请求呢？此时出现了集群这种解决方案，通过增加服务器，采取负载均衡的方式分发请求到多台服务器中去处理，那么就可以处理更多的请求了**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 4]

#### 5.读写分离时代 ####

为了进一步地降低数据库或缓存数据库的读写压力，可以将读请求和写请求分发给不同的机器来处理，这样就产生了读写分离的架构，这在MySQL和Redis中经常被使用到，这样做有两个好处：

1.  将读和写分离，请求的负载均衡
2.  数据的备份与容灾，防止数据的丢失

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 5]

#### 6.反向代理与内容分发网络 ####

由于网站发展越来越好，用户分布于世界各地，此时如果我们的资源如图片、文件、CSS等都部署在一台固定位置的服务器上，那么距离这台服务器越远的用户，其访问资源的速度会越慢。

**而网站的访问速度和响应速度与用户的流失率成反比的关系，这时需要提高不同地域的用户的访问速度**

内容分发网络（CDN）实质上是部署与云服务商服务器中的资源，当用户请求CDN上的资源时，会优先将请求转发到距离用户最近的服务器，这样就可以提高用户的访问速度。

而反向代理服务器的作用是将用户的请求进行转发，如果发现已经存在缓存，那么会将缓存直接返回。

**CDN与反向代理在这里的作用都是为了能更快地响应用户所需的资源**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 6]

#### 7.底层服务集群化 ####

现在这个网站的架构已经比较完善了，但是我们发现数据库和缓存服务都只存在两台机器：一个提供写服务器、一个提供读服务，但是这时会出现一个问题，就是数据库的一张表中出现了大量的数据或者是缓存服务器的内存被占据满了，此时无论如何进行读写分离，由于从库总是同步与主库，所以从库也会被占满，从而无法对外提供底层服务，或者是响应缓慢，此时的做法和一开始应用服务器的水平扩展一样，也就是增加更多的底层服务。

**水平拓展：通过增加更多的底层服务机器，来将数据库或缓存的数据与压力分发下去，让数据平摊到不同的底层服务机器上就可以解决单体压力过大的问题。**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 7]

#### 8.搜索引擎技术与NoSQL ####

此时网站架构已经十分地完善了，但是在某些服务例如商品的关键字搜索、商品数据的存储等会出现一些问题。

商品的关键字搜索服务，如果使用普通的数据库配合模糊查询来实现的话，由于模糊查询不会走索引，当数据量大的时候，这个查询过程是十分缓慢并且耗费计算资源的，所以出现了搜索引擎技术，如Solr、ES等来解决这个问题，一方面优化了关键字检索的效率，另一方面可以将一部分数据分担到Solr或ES的数据库中。

商品的数据存储，如果使用数据库来做的话每条数据都会占据大量的字段和空间，这时可以使用MongoDB等NoSQL数据库来存储这些数据，可以大大提高查询的速度和降低所占用的空间。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 8]

#### 9.服务拆分与微服务化 ####

当网站的业务越来越多，开发者也越来越多，此时出现了一些问题：

1.  业务越来越复杂，各个不同的业务之间耦合在一起，修改困难
2.  应用代码越来越庞大，打包时间很长
3.  单个业务出现了问题导致整个服务都崩溃，影响了其他业务的正常运转

所以，有架构师提出了以下的建议：

**1. 业务复杂，能否按业务线将来拆分团队，如将业务线拆分为支付业务、首页业务、用户服务业务等，然后让不同的团队去负责开发，当需要服务依赖时通过远程调用的方式进行调用**

**2. 将大的应用拆分为小的应用，分开部署，这样就不会产生某个应用挂掉了导致其他应用也不能提供服务的问题**

所以出现了近几年来非常火爆的网站架构方式：微服务化

**微服务化，即将大应用按业务模块拆分为小应用，然后使用RPC使得小应用之间相互配合，从而组成大应用。**

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 9]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70]: /images/20230529/deaef4c379ef4934b290cf9c0e41a116.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 1]: /images/20230529/76fd014749a144fea1b01f75af07043d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 2]: /images/20230529/6c694293bee44345b03ae5796ff06e22.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 3]: /images/20230529/020f58e62db74294a2f6ca57fa0cbc40.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 4]: /images/20230529/69f189de6b22439eb71c0210d963d9eb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 5]: /images/20230529/cb47366ab59d4b99a7d5eee5e6ea38a4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 6]: /images/20230529/b0d3a70e587f4bc786750f6887b07e22.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 7]: /images/20230529/ed76709ec5b8425fad897f63e7bd2852.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 8]: /images/20230529/3d9f240041ed4a6da2585f422d79055d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3BicmxvdmVqYXZh_size_16_color_FFFFFF_t_70 9]: /images/20230529/cf8b407427644a98aa316882d6f6c269.png