大型互联网架构体系

初始阶段的网站架构

一直追溯到很久以前，那个时候还是一个一个Project,没有Module之分，在开发完毕后，将这样一个项目部署到服务器里面，供用户访问、使用；这时应用程序、数据库、文件等所有资源都在一台服务器上，网站架构如下图所示：

可是慢慢的发现一旦项目出现问题单点故障问题，那么便会遇到服务器瘫痪，用户访问资源失败，这是显而易见的大问题。

单点故障：其实是围绕主控机来说明的，但是在上文中，只涉及一台服务器部署项目，通俗的说就是项目在服务器无法正常运行。

应用服务和数据服务分离

随着网站业务的发展和用户量的增加，一台服务器也就无法满足需求了。当大量用户访问导致访问速度越来越慢，而逐渐增加的数据也会导致存储空间不足。这时候就需要将应用和数据分离，所有资源进行分离后，大致可以划分为以下三台服务器：应用服务器、文件服务器和数据库服务器。同时这三台服务器的性能也是大不一致。

• 应用服务器针对于业务逻辑处理，更需要强大的CPU
• 数据库服务器对磁盘读写操作很多，需要更快的磁盘和更大的内存
• 文件服务器存储用户上传的文件，需要更大的磁盘空间

此时网站架构如下图所示：

缓存技术改善网站性能

随着用户量持续激增，导致数据库压力太大导致网站访问效率整体下降，虽然数据库服务器或许不会崩，但是用户体验势必受到影响。那么针对于频繁读写的数据，可以存放到缓存中，当用户下次访问相同资源后，可以直接从缓存中进行读取，而不是每次都去数据库读取，这样就可以减少数据库的访问压力，从而提高整个网站的访问速度。
网站使用的缓存一般分为缓存到应用服务器或者缓存在专门的分布式缓存服务器。缓存到应用服务器可以提高访问速度，但是受到自身内存限制，所以一般都会远程到专门致力于缓存服务器，例如：redis等；当内存不够时还可以动态扩容。

数据库读写分离

网站使用缓存后，确实可以将大部分数据“读”操作不访问数据库，但是遇到（缓存访问失败，缓存过期）和全部的写操作都需要访问数据库；目前大部分主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器中；即便不利用主从功能，同样可以利用读写分离机制，改善数据库负载压力。如下图所示：

应用服务器在写数据的时候，访问数据库，主数据库通过主从复制机制加你个数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获得数据。

应用服务器集群改善网站的并发处理能力

缓存技术确实可以减弱数据访问的压力，但是单体应用服务器能够处理的请求连接是有限的。使用分布式集群是解决高并发、海量数据问题的常用手段。当一台服务器处理能力和存储空间不足时，更换服务器确实可以在短时间解决问题，但是却满足不了网站持续增长的业务需求。更好的方式是，增加多态服务器分担原有服务器的访问和存储压力，从而实现系统的可伸缩性。应用服务器实现集群是网站可伸缩架构设计中较为简单成熟的一种，如下图所示：

通过负载均衡调度服务器，例如Nginx等，可以将俩字用户浏览器的访问请求分发到集群中的任何一台服务器上。

反向代理和CDN加速网站相应

由于用户规模越来愈大，不同地区的用户访问网站是，速度差别也极大，因此可以利用CDN和反向代理。如下图所示：

业务拆分

大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成不同的产品线，如购物交易网站会将首页、店铺、订单、卖家、卖家等拆分成不同的产品线，分归不同的业务团队负责。

分布式服务

随着业务拆分越来越小，存储系统原来越庞大，应用系统的整体复杂度呈指数级增加，部署和维护也越来越困难。既然每一个应用系统都需要执行相同的业务操作，比如用户管理、商品管理等，那么可以将这些共用的业务提取出来，独立部署。由这些可复用的业务连接数据库，提供共用业务服务，而应用系统只需要管理用户界面，通过分布式服务调用共用业务服务完成具体业务操作。如下图所示：