前言
如果把上世纪90年代初
CERN正式发布 Web 标准和第一个 Web 服务的出现当做网站的开始，那么网站的发展只经历了短短 30 年的时间。在此过程中网站架构经历过许多次演化，每次演化都解决了许多问题。
演化历程
与一般的企业应用不一样，互联网应用系统有如下特点。
- 高并发、大流量
- 高可用
- 海量数据
- 安全环境恶劣
- 需求快速变更，发布迭代
- 渐进式发展
初始的网站架构
最开始的网站没太多人访问，只需要一台服务器就可以，应用程序、文件、数据库所有资源都放在同一台服务器上。此时网站架构如下图，通常使用LAMP技术(Linux系统+PHP开发+Apache部署+MySQL数据库)，汇集各种开源软件。
应用与数据分离
随着网站业务发展，越来越多的用户访问导致性能越来越差，越来越多的数据导致磁盘存储空间不足。
此时需要将应用和数据分离，即分为：应用服务器、文件服务器和数据库服务器。具体架构如下图，另外，不同的服务器对性能的要求不一样。
- 应用服务器：处理大量的业务逻辑，需要更快更强大的CPU。
- 数据库服务器：快速磁盘检索和数据缓存，需要更快的硬盘和更大的内存。
- 文件服务器：存储大量用户上传的文件，需要更大的磁盘。
分离后，不同功能的服务器承担不同的服务角色，网站并发处理能力和数据存储空间得到了很大改善。
缓存改善网站性能
随着用户继续增加，网站又面临新的问题：数据库压力太大导致访问延迟，进而影响整个网站的性能。
网站访问特点遵循二八定律：**80%的业务访问集中于20%的数据上，**即热点数据。
缓存热点数据，既可以减轻数据库的访问压力，并且可以提升服务响应速度。
网站使用的缓存可以分为两种：
- 本地缓存的访问速度更快一些，但是受应用服务器内存限制，其缓存数据量有限，而且会出现和应用程序争用内存的情况。例如 MC。
- 远程分布式缓存可以使用集群的方式，部署大内存的服务器作为专门的缓存服务器，可以在理论上做到不受内存容量限制的缓存服务。例如 Redis。
服务器集群改善网站并发处理能力
使用缓存后，数据访问压力得到有效缓解，但单一应用服务器能处理的请求有限，在网站访问高峰期，应用服务器成为网站新的性能瓶颈。
当一台服务器的处理能力、存储空间不足时，不要企图去换更强大的服务器，对大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求。
这种情况下，更恰当的做法是增加一台服务器分担原有服务器的访问及存储压力。
对网站架构而言，只要能通过增加一台服务器的方式改善负载压力，就可以以同样的方式持续增加服务器不断改善系统性能，从而实现系统的可伸缩性。
集群是网站可伸缩集群架构设计中较为简单成熟的一种，如图所示。
数据库读写分离
网站在使用缓存后，使绝大部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读操作（缓存访问不命中、缓存过期）和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。
目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。
应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获得数据。
为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明。
反向代理和 CDN 加速网站响应
由于中国复杂的网络环境，不同地区的用户访问网站时，速度差别也极大。
有研究表明，网站访问延迟和用户流失率正相关，网站访问越慢，用户越容易失去耐心而离开。为了提供更好的用户体验，留住用户，网站需要加速网站访问速度。
CDN和反向代理的基本原理都是缓存。
- CDN 部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；
- 反向代理部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。
使用CDN和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。
使用分布式文件系统和分布式数据库系统
任何强大的单一服务器都满足不了大型网站持续增长的业务需求。
数据库经过读写分离后，从一台服务器拆分成两台服务器，但是随着网站业务的发展依然不能满足需求，这时需要使用分布式数据库。文件系统也是一样，需要使用分布式文件系统，分布式数据库是网站数据库拆分的最后手段，只有在单表数据规模非常庞大的时候才使用。
不到不得已时，网站更常用的数据库拆分手段是业务分库，将不同业务的数据库部署在不同的物理服务器上。
使用NoSQL和搜索引擎
随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。
业务拆分
大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成不同的产品线，如大型购物交易网站就会将首页、商铺、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责。
具体到技术上，也会根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署维护。
应用之间可以通过一个超链接建立关系（在首页上的导航链接每个都指向不同的应用地址），也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。
分布式服务
随着业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难。
由于所有应用要和所有数据库系统连接，在数万台服务器规模的网站中，这些连接的数目是服务器规模的平方，导致存数据库接资源不足，拒绝服务。
既然每一个应用系统都需要执行许多相同的业务操作，比如用户管理、商品管理等，那么可以将这些**共用的业务提取出来，独立部署。**由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作，即微服务。
后话
大型网站的架构演化到这里，基本上大多数的技术问题都得以解决，诸如跨数据中心的实时数据同步和具体网站业务相关的问题也都可以通过组合改进现有技术架构来解决。但事物发展到一定阶段，就会拥有自身的发展冲动，摆脱其初衷，向着使自己更强大的方向发展。
云计算
既然大型网站架构解决了海量数据的管理和高并发事务的处理，那么就可以把这些解决方案应用到网站自身以外的业务上去。
我们看到目前许多大型网站都开始建设云计算平台，将计算作为一种基础资源出售，中小网站不需要再关心技术架构问题，只需要按需付费，就可以使网站随着业务的增长逐渐获得更大的存储空间和更多的计算资源。
网站架构误区
- 一味追随大公司的解决方案。
- 为了技术而技术。
- 企图用技术解决所有问题。有些问题应该从业务流程上进行优化。
小结
时至今日，大型网站的架构演化方案已经非常成熟，各种技术方案也逐渐产品化。
许多小型网站已经慢慢不需要再经历大型网站经历过的架构演化之路就可以逐步发展壮大，因为现在越来越多的网站从建立之初就是搭建在大型网站提供的云计算服务基础之上，所需要的一切技术资源：计算、存储、网络都可以按需购买，线性伸缩，不需要自己一点一点地拼凑各种资源，综合使用各种技术方案逐步去完善自己的网站架构了。
所以能亲身经历一个网站从小到大的架构演化过程的网站架构师越来越少，虽然过去有这种经历的架构师也很少（从小型网站发展成大型网站的机会本来就极少），但是将来可能真就没有了。
评论