大型网站架构演化
原文来自https://www.cnblogs.com/netoxi/p/7258895.html
如何打造一个高可用、高性能、易扩展、可伸缩且安全的网站？如何让网站应用所需灵活变动，即时是山寨他人的产品，也可以山寨的更高、更快、更强，一年时间用户数从零过亿呢？对此我总结一下：
1.1 大型网站软件系统的特点
- 高并发，大流量;
- 高可用：系统7*24小时不间断服务；
- 海量数据：存储、管理海量数据；需要使用大量服务器；
- 用户分布广泛，网络情况复杂；许多大型互联网都是为全球用户提供服务的，用户分布范围广，各地网络情况千差万别；
- 安全环境恶劣；由于互联网的开放性，使得互联网更容易受到攻击，大型网站几乎每天都会被黑客攻击；
- 需求快速变更，发布频繁；和传统软件的版本发布频率不同，互联网产品为快速适应市场，满足用户需求，其产品发布频率是极高的；
- 渐进式发展：与传统软件产品或企业应用系统一开始就规划好全部的功能和非功能需求不同，几乎所有的大型互联网网站都是从一个小网站开始，渐进地发展起来的。
1.2 大型网站架构演化发展历程
初始阶段的网站架构：
需求/解决问题：
小型网站最开始没有什么人访问；
架构：
应用程序、数据库、文件等所有资源都在一台服务器上；
应用服务与数据服务分离：
需求/解决问题：
网站业务发展，一台服务器无法满足要求；越来越多用户访问导致性能变差；越来越多的数据导致存储空间不足
架构：
应用和数据分离，采用三台服务器：应用服务器，文件服务器，数据库服务器；应用服务器处理大量业务逻辑，需要更快更强大的CPU；数据库服务器快速磁盘检索和数据缓存，需要更快的磁盘和更大的内存；文件服务器存储大量用户上传的文件，需要更大的磁盘。
使用缓存改善网站性能：
需求/解决问题：
用户逐渐增多，数据库压力太大导致访问延迟。
架构：
根据二八定律：80%的业务访问集中在20%的数据上，把小部分数据缓存在内存中，可减少数据库访问压力。
类型 |
原理 |
优点 |
缺点 |
本地缓存 |
缓存在应用服务器 |
访问速度更快 |
受应用服务器内存限制 |
分布式缓存 |
部署大内存缓存服务器集群 |
理论上不受内存容量限制 |
-- |
使用应用服务器集群改善网站的并发处理能力：
需求/解决问题：
单一服务器处理的连接请求有限；
架构：
通过负载均衡调度服务器，可将来自用户浏览的访问请求分发到应用服务器集群中的任何一台服务器上，实现系统的可伸缩性。
数据库读写分离：
需求/解决问题：
一部分读操作（缓存访问不命中、缓存过期）和全部的写操作需要访问数据库。
架构：
应用服务器写数据时，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库；当应用服务器读数据时，可通过从数据库获得数据。通常在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明。
使用反向代理和CDN加速网站响应：
需求/解决问题：
中国网络环境复杂，不同地区的用户访问网站时，速度差别极大，网站访问延迟导致用户流失率提高。
架构：
CDN和反向代理目的都是尽早返回数据、加快访问速度、减轻后端服务器负载压力。
1. CDN：部署在网络提供商机房。用户请求网站服务时，可从距离自己最近的网络提供商机房获取数据。
2. 反向代理：部署在网站中心机房。用户请求到达中心机房后，首先访问反向代理服务器，如果反向代理服务器缓存着用户请求的资源，就将其直接返回给用户。
使用分布式文件系统和分布式数据库：
需求/解决问题：
读写分离伸缩性有限。
架构：
只有在单表数据规模非常庞大的时候（不到万不得已）才数据库拆分，按业务分库，不同的业务数据部署在不同的物理服务器上；
使用分布式文件系统和分布式数据库：
需求/解决问题：
随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂；
架构：
1. NoSQL和搜索引擎都是源自互联网的技术手段，可伸缩的分布式特性更好；
2. 应用服务器通过一个统一数据访问模块访问各种数据。
业务拆分：
需求/解决问题：
业务场景日益复杂。
架构：
1. 将整个网站业务分成不同产品线（如大型购物交易网站拆分为首页、商铺、订单、买家、卖家），分归不同业务团队负责。
2. 根据产品线划分，将网站拆分成不同应用，每个应用独立部署维护。应用间关联方式：
a) 超链接（首页上导航链接每个应用地址）；
b) 通过消息队列进行数据分发；
c) 通过同一数据存储系统构成一个关联的完整系统（最多）。
分布式服务：
需求/解决问题：
所有应用要和所有数据库系统链接，在数万台服务器规模的网站中，连接数目时服务器规模的平方，导致数据库连接资源不足，拒绝服务。
架构：
将共用的业务提取出服务，独立部署。