架构的演变历程

单机服务器

背景: 用户量很少，基本上没有人访问，单机服务器显然够用。

目的: 就是让用户够用就行。

操作：搭建一台服务器，上面部署了应用程序，数据库，文件。

• 非常原始并且简单的一个服务器，可以把这个阶段理解为一个小的博客网站。其实就是一个demo网站，因为用户量很少，没有什么访问量，一两分钟还不来访问一次呢，所以这样的架构完全够用了。

三台服务器

背景: 随着业务的发展，单机服务器扛不住了，性能越来越差，用户访问网页，半天还打不开，用户快气死了。单机服务器内存、磁盘、CPU都满满的，再不整治，就挂了。

目的: 就是让用户可用，能够满足用户的需求，起码能正常打开网页吧。

操作：搭建三台服务器，分别是应用服务器，数据库服务器，文件服务器。将这三块进行分离，架构清晰，也方面后面进行扩展。

• 根据不同的场景及需求，合理分配不同配置的机器给到应用、数据库、文件服务器。

• 应用服务器占用CPU较多，应用程序经常进行逻辑计算，业务逻辑处理，比较占用CPU，应该选择CPU偏好的机器。

• 数据库服务器占用内存磁盘较多，数据库用于存储数据，查询数据，存储数据需要磁盘大的，查询数据需要内存大的机器，应该选用内存磁盘偏好的机器。

• 文件服务器占用磁盘较多，文件服务器基本上都是存储文件的，需求点在磁盘空间，所以应该选用磁盘较大的机器。

引入缓存

背景: 网站访问的特点，大部分流量都会落到部分数据上，这些数据称为热点数据。用户访问量的增加，使得性能也越来越差，数据库扛不住了。

目的: 就是让用户可用，能够满足用户的需求。

操作：搭建缓存服务器，将热点数据放入缓存服务器中，从而降低数据库服务器的负载。 缓存服务器可以是分布式集群，这样就具有良好的伸缩性，不受容量控制。

• 也可以有些本地缓存的情况，本地缓存更快。但其容量严格会受到应用服务器的限制。

• 最佳实践就是能用分布式缓存，尽量用分布式缓存。本地缓存除非有特别的场景才用。缓存越多，数据不一致的情况越严重。

应用服务器集群

背景: 应用服务器的处理能力不足，存储空间不足，无法支撑用户的访问。

目的: 就是让用户可用，能够满足用户的需求。

操作：搭建应用服务器集群，还有负载均衡服务器。凡是遇到集群的情况，为了确保每台服务器负载流量相差无几，都需要有个负载均衡服务器对集群服务器进行调节。

• 当一台服务器的处理能力、存储空间不足时，不要企图去更换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求。

• 这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。

• 对网站架构而言，只要能通过增加一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性。

• 应用服务器实现集群是网站可伸缩架构设计中较为简单成熟的一种。

• 使用集群是网站解决高并发、海量数据问题的常用手段。

数据库读写分离

背景: 缓存虽然能够将大部分的请求抗住，但是还会有些请求会落到数据库，比如：缓存没有命中、缓存过期、写操作。随着这些流量的不断增加，数据库服务器性能开始下降。

目的: 降低数据库负载，提高数据库服务器的性能。对用户而言，依然是让用户可用，能够满足用户的需求。

操作：搭建主从数据库，主数据库主要用来写数据，从数据库主要用来读数据，主数据库(Master)将数据同步给从数据库(Slave)。

• 这也是开始数据库治理的首要套路，也是很有效果的套路，但是引入主从，必将会带来数据不一致的情况，这个也是老生长谈的话题。

反向代理&CDN加速

背景: 不同地区网络环境不同，网站访问延迟较大，网络访问延迟必将导致用户留存率下降。我自己打开个网页，2s以内不出来，就马上给关了。

目的: 提高系统性能，留住用户。对用户而言，依然是让用户可用，能够满足用户的需求。

操作：使用反向代理和CDN加速(CDN主要存放的是一些前端资源 html+css+js+img)

• CDN 部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据

• 反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户

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

分布式文件&分布式数据库

背景: 单点服务器总是会出现性能瓶颈的，无论单机服务器配置多好，总会有个上限的。

目的: 解除单点服务器性能瓶颈。对用户而言，依然是让用户可用，能够满足用户的需求。

操作：搭建分布式文件系统和分布式数据库系统，替换掉单点服务器。

• 分布式数据库一般遵循按照业务划分，分表分库，只要业务分的足够细，数据库数据库是可以无限扩展的。

NoSQL和搜索引擎

背景: 网站越来越复杂，对数据存储和检索的需求也越来越复杂，现有数据库无法满足这些需求。

目的: 满足数据存储和检索需求，降低检索对数据库的负载。对用户而言，依然是让用户可用，能够满足用户的需求。

操作：使用NoSQL集群和搜索引擎集群

• NoSQL Not only SQL，用来存储更复杂的数据结构。NoSQL也可搭建集群，具有良好的伸缩性。

• 搜索引擎，最原始的情况一般都是使用like关键字进行模糊匹配，但是虽然业务的不断发展，还会用到全文索引等情况，这种情况下现在数据库就不再支持了，就有专门的搜索引擎来做这个事情，搜索引擎也可以搭建集群，也会有良好的伸缩性。但是规模较大，拥有研发能力的公司基本上是有专门自己的检索团队的，拥有这种能力的，一般都是自研检索产品。

应用服务器拆分

背景: 网站业务越来越复杂，业务越来越细化，很多业务在一个集群上，耦合性太高，牵一发而动全身。

目的: 降低业务耦合度，为了业务更加独立，协作发展。

操作：业务拆分，划分成不同的应用服务器集群。其中也会用到消息队列进行架构解耦。

• 业务拆分，从组织架构上来看，就会分成不同的团队，每个团队负责一块业务。随着组织架构的划分，技术上一般会采用应用程序分离和使用消息队列解耦。

• 各个业务的服务器也都是集群部署，消息队列也是集群部署。都要求有良好的伸缩性，以保证不会出现性能瓶颈。

分布式服务

背景: 随着业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难

目的: 降低系统复杂度，更容易维护系统。

操作：将这些共用的业务提取出来，独立部署

• 抽出共用服务，独立部署。比如商品管理，算价模块。