|
|
<h1><center>大型网站架构技术</center></h1>
|
|
|
|
|
|
**作者：行癫（盗版必究）**
|
|
|
|
|
|
------
|
|
|
|
|
|
## 一：大型架构的特点
|
|
|
|
|
|
1.高并发,大流量
|
|
|
|
|
|
goole日均pv数35亿，日均IP访问数3亿，腾讯QQ的最大在线用户数5.74 亿（2021年数据），淘宝2012年“双11”活动一天交易额超过191亿，活动开始第一分钟独立访问用户达1000万，微信以及WeChat的月活跃帐户达到12.6亿等
|
|
|
|
|
|
2.高可用
|
|
|
|
|
|
系统7x24小时不间断服务
|
|
|
|
|
|
3.海量数据
|
|
|
|
|
|
需要存储、管理海量数据，需要大量服务器。Facebook每周上传的照片数目接近10亿，百度收录的网页数据有数百亿，google有近百万台服务器为全球用户提供服务。
|
|
|
|
|
|
4.用户分布广泛，网络情况复杂
|
|
|
|
|
|
许多大型互联网站都是为全球用户提供服务的，用户分布范围广，各地网络情况千差万别。在国内，还有各个运营商网络互通困难的问题
|
|
|
|
|
|
5.安全环境恶劣
|
|
|
|
|
|
由于互联网的开放性，使得互联网站更容易受到攻击，大型网站几乎每天都会被黑客攻击
|
|
|
|
|
|
6.需求快速变更，发布频繁
|
|
|
|
|
|
和传统软件的版本发布频率不同，互联网产品为快速适应市场，满足用户需求，其产品发布频率极高
|
|
|
|
|
|
7.渐进式发展
|
|
|
几乎所有的大型网站都是从一个小网站开始，facebook是扎克伯格在哈弗大学的宿舍里开发的，google第一台服务器部署在斯坦福大学的实验室里，阿里巴巴是在马云家的客厅里诞生的。
|
|
|
|
|
|
## 二：架构演进
|
|
|
|
|
|
#### 1.初始阶段的网站架构
|
|
|
|
|
|
大型网站都是从小型网站发展而来，网站架构也是一样，是从小型网站架构逐步演化而来。小型网站最开始没有太多人访问，只需要一台服务器就绰绰有余，这时的网站架构如下图所示，应用程序、数据库、文件等所有资源都在一台服务器上
|
|
|
|
|
|
<img src="D:\行癫kubernetes\虚拟化技术\大型网站架构技术.assets\image-20220710151757707.png" alt="image-20220710151757707" style="zoom:50%;" />
|
|
|
|
|
|
#### 2.应用服务和数据服务分离
|
|
|
|
|
|
随着网站业务的发展，一台服务器逐渐不能满足需求：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足；这时就需要将应用和数据分离；应用和数据分离后整个网站使用3台服务器：应用服务器、文件服务器和数据库服务器；这3台服务器对硬件资源的要求各不相同。
|
|
|
|
|
|
应用服务器需要处理大量的业务逻辑，因此需要更快更强大的CPU
|
|
|
|
|
|
数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的磁盘和更大的内存
|
|
|
|
|
|
文件服务器需要存储大量用户上传的文件，因此需要更大的硬盘
|
|
|
|
|
|
<img src="D:\行癫kubernetes\虚拟化技术\大型网站架构技术.assets\image-20220710151937584.png" alt="image-20220710151937584" style="zoom:50%;" />
|
|
|
|
|
|
#### 3.使用缓存改善网站性能
|
|
|
|
|
|
网站访问的特点和现实世界的财富分配一样遵循二八定律：80% 的业务访问集中在20% 的数据上；既然大部分业务访问集中在一小部分数据上，那么如果把这一小部分数据缓存在内存中，就可以减少数据库的访问压力，提高整个网站的数据访问速度，改善数据库的写入性能了；网站使用的缓存可以分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。
|
|
|
|
|
|
本地缓存的访问速度更快一些，但是受应用服务器内存限制，其缓存数据量有限，而且会出现和应用程序争用内存的情况
|
|
|
|
|
|
远程分布式缓存可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务
|
|
|
|
|
|
<img src="D:\行癫kubernetes\虚拟化技术\大型网站架构技术.assets\image-20220710152124678.png" alt="image-20220710152124678" style="zoom:50%;" />
|
|
|
|
|
|
#### 4.使用集群改善网站并发能力
|
|
|
|
|
|
应用服务器作为网站的入口，会承担大量的请求，我们往往通过应用服务器集群来分担请求数；应用服务器前面部署负载均衡服务器调度用户请求，根据分发策略将请求分发到多个应用服务器节点。
|
|
|
|
|
|
<img src="D:\行癫kubernetes\虚拟化技术\大型网站架构技术.assets\image-20220710152332946.png" alt="image-20220710152332946" style="zoom:50%;" />
|
|
|
|
|
|
常用的负载均衡技术硬件的有F5，价格比较贵，软件的有LVS、Nginx、HAProxy。LVS是四层负载均衡，根据目标地址和端口选择内部服 务器，Nginx和HAProxy是七层负载均衡，可以根据报文内容选择内部服务器，因此LVS分发路径优于Nginx和HAProxy，性能要高些，而 Nginx和HAProxy则更具配置性，如可以用来做动静分离（根据请求报文特征，选择静态资源服务器还是应用服务器）
|
|
|
|
|
|
#### 5.数据库读写分离和分库分表
|
|
|
|
|
|
随着用户量的增加，数据库成为最大的瓶颈，改善数据库性能常用的手段是进行读写分离以及分表，读写分离顾名思义就是将数据库分为读库和写库，通过主备功能实现数据同步。分库分表则分为水平切分和垂直切分，水平切换则是对一个数据库特大的表进行拆分，例如用户表。垂直切分则是根据业务不同来切换，如用户业务、商品业务相关的表放在不同的数据库中。
|
|
|
|
|
|
<img src="D:\行癫kubernetes\虚拟化技术\大型网站架构技术.assets\image-20220710152631824.png" alt="image-20220710152631824" style="zoom:50%;" />
|
|
|
|
|
|
#### 6.使用CDN和反向代理
|
|
|
|
|
|
假如我们的服务器都部署在成都的机房，对于四川的用户来说访问是较快的，而对于北京的用户访问是较慢的，这是由于四川和北京分别属于电信和联通的不 同发达地区，北京用户访问需要通过互联路由器经过较长的路径才能访问到成都的服务器，返回路径也一样，所以数据传输时间比较长。对于这种情况，常常使用 CDN解决，CDN将数据内容缓存到运营商的机房，用户访问时先从最近的运营商获取数据，这样大大减少了网络访问的路径。比较专业的CDN运营商有蓝汛、 网宿。
|
|
|
|
|
|
而反向代理，则是部署在网站的机房，当用户请求达到时首先访问反向代理服务器，反向代理服务器将缓存的数据返回给用户，如果没有没有缓存数据才会继续走应用服务器获取，也减少了获取数据的成本。反向代理有Squid，Nginx。
|
|
|
|
|
|
<img src="D:\行癫kubernetes\虚拟化技术\大型网站架构技术.assets\image-20220710152631824.png" alt="image-20220710152631824" style="zoom:50%;" />
|
|
|
|
|
|
#### 7.使用分布式文件系统
|
|
|
|
|
|
用户一天天增加，业务量越来越大，产生的文件越来越多，单台的文件服务器已经不能满足需求。需要分布式的文件系统支撑。常用的分布式文件系统有NFS。
|
|
|
|
|
|
|
|
|
|
|
|
#### 8.使用NoSql和搜索引擎
|
|
|
|
|
|
对于海量数据的查询，我们使用nosql数据库加上搜索引擎可以达到更好的性能。并不是所有的数据都要放在关系型数据中。常用的NOSQL有mongodb和redis，搜索引擎有lucene
|
|
|
|
|
|
|
|
|
|
|
|
#### 9.将应用服务器进行业务拆分
|
|
|
|
|
|
随着业务进一步扩展，应用程序变得非常臃肿，这时我们需要将应用程序进行业务拆分，如百度分为新闻、网页、图片等业务。每个业务应用负责相对独立的业务运作。业务之间通过消息进行通信或者同享数据库来实现。
|
|
|
|
|
|
|
|
|
|
|
|
#### 10.搭建分布式服务
|
|
|
|
|
|
这时我们发现各个业务应用都会使用到一些基本的业务服务，例如用户服务、订单服务、支付服务、安全服务，这些服务是支撑各业务应用的基本要素。我们将这些服务抽取出来利用分部式服务框架搭建分布式服务。淘宝的Dubbo是一个不错的选择。
|
|
|
|
|
|
|
|
|
|
|
|
总结：
|
|
|
|
|
|
大型网站的架构是根据业务需求不断完善的，根据不同的业务特征会做特定的设计和考虑，本文只是讲述一个常规大型网站会涉及的一些技术和手段。
|
|
|
|
|
|
## 三：架构模式
|
|
|
|
|
|
关于什么是模式，这个来自建筑学的词汇是这样定义的："每一个模式描述了一个在我们周围不断重复发生的问题及该问题解决方案的核心。这样，你就能一次又一次地使用该方案而不必做重复工作"。模式的关键在于模式的可重复性，问题与场景的可重复性带来解决方案的可重复使用。
|
|
|
|
|
|
分层：一般可分为，应用层，服务层，数据层，管理层，分析层
|
|
|
|
|
|
分割：一般按照业务/模块/功能特点进行划分，比如应用层分为首页，用户中心
|
|
|
|
|
|
分布式：将应用分开部署（比如多台物理机），通过远程调用协同工作
|
|
|
|
|
|
集群：一个应用/模块/功能部署多份（如：多台物理机），通过负载均衡共同提供对外访问
|
|
|
|
|
|
缓存：将数据放在距离应用或用户最近的位置，加快访问速度
|
|
|
|
|
|
异步：客户端发出请求，不等待服务端响应，等服务端处理完毕后，使用通知或轮询的方式告知请求方
|
|
|
|
|
|
冗余：增加副本，提高可用性，安全性，性能
|
|
|
|
|
|
安全：对已知问题有有效的解决方案，对未知/潜在问题建立发现和防御机制
|
|
|
|
|
|
自动化：将重复的，不需要人工参与的事情，通过工具的方式，使用机器完成
|
|
|
|
|
|
敏捷性：积极接受需求变更，快速响应业务发展需求
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
