大型网站技术架构读书笔记01—大型网站架构演化史

今天的笔记是简单介绍一个大型网站从小到大的演化。

每一个大型网站都是从小型网站逐渐演化过来的，大多数网站的演化都要经历以下阶段。

一：网站初始阶段架构

最开始网站的规模很小，访问量和并发量不大，数据量也不是很大。所以只需要一台服务器就可以支撑网站运行的全部工作，其架构图如下：



这个时候应用程序，文件和数据库 都部署在一台服务器上。典型的部署方式有LPAM(操作系统Linux，应用程序PHP，服务器Appache，数据库MySSQL)或者（操作系统Windows，应用程序ASP.NET，服务器IIS，数据库SQL Server）或者（操作系统Linux，应用程序JSP，服务器Linux，数据库Oracle）。这样一个网站就成功上线并且开始运行了。

二：应用服务和数据分离

随着网站业务的发展，用户访问量并发量的增加，一台服务器明显满足不了要求，这个时候就可以把一台服务器上的三个部分分开部署到不同的服务器上，整个后台共有三台服务器：应用程序服务器，文件系统服务器，数据库服务器。他们的职责不同，性能上也就有所差异。应用程序需要处理复杂的业务逻辑，所以需要性能强大的CPU，文件系统服务器主要用来存储文件，因此硬盘空间一定要大。数据库服务器要进行大量的磁盘操作(I/O操作)，所以要配备性能强大的磁盘。这个时候的网站架构如下：



不同的服务器负责不同的功能，从而使网站可以有效的抵抗增加的用户访问和大量的数据处理。

三：使用缓存改善性能

随着访问的进一步增加，数据库的压力急剧增加，因为用户的访问请求需要在数据库服务器上进行大量的读写操作。而单台数据库的并发是非常有限的，这个时候要想办法把在数据库服务器上进行的读写操作转移到其他服务器上，那就是使用缓存（本地缓存和分布式缓存两种）来减轻数据库服务器的压力。
网站的访问通常遵循二八定律：80%的业务访问集中在20%的数据上，如果这个时候我们把数据库中这20%的数据缓存起来，是不是就可以马上减轻数据库的访问压力，进而改善网站的整体性能呢？答案当然是肯定的。这个时候的网站架构图如下：

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

当用户量增加到一定程度的时候，一台应用程序服务器是处理不了所有的请求的。面对逐渐增加的访问量，并发量以及海量数据，网站常用的手段是搭建服务器集群，用一组服务器去处理用户请求。集群也可以实现系统的伸缩性，这个时候的网站架构如下：



这个时候挡在最前沿的是负载均衡服务器，用户请求首先到达负载均衡服务器，然后由负载均衡服务器将用户请求分发到集群中一台服务器上去处理，当用户量增加的时候，只需向应用服务器集群中添加服务器即可，这样的系统具有很强的伸缩性。

五：数据库读写分离

虽然使用缓存极大地减轻了数据库服务器的压力，但一台数据库服务器即使再强大，性能最终还是有限的。面对继续增加用户访问量，数据库服务器负载还是会明显加重，进而成为整个网站运行的瓶颈。
用户在数据库服务器上的操作简化来说无非就是读和写，所以解决方案就来了，我们可以把数据库的读操作和写操作分离开来放到两台服务器上不就减轻一台数据库服务器的压力了嘛。这种方案叫做数据库的主从复制，读写分离。具体架构图如下：


主数据库服务器负责写操作，从数据库服务器负责读造作，然后通过主从复制机制将数据从主服务器更新到从服务器上。

六：使用反向代理和CDN加速网站响应

用户规模的进一步扩大，业务范围地域的进一步扩展，以及不同地区用户网络状态的差异等因素使得网站的响应速度还是会受一定影响。为了进一步改善网站性能，我们在网站中加入了CDN服务器和反向代理服务器，他们的本质都是缓存（这两台服务器的缓存中存储了访问频率非常高的数据），尽最大可能的使用户请求直接从缓存里面拿到数据，而不是到达应用程序服务器后访问数据库去拿数据。不同的是CDN部署在网络提供商的机房，可以使用户从地理位置上离自己最近的服务器中拿到想要的数据。反向代理服务器部署在网站的中心机房，用户请求过来以后，最先到达反向代理服务器，然后从反向代理服务器的缓存中拿数据，如果缓存中没有找到数据，那就交给应用程序服务器去处理。这个时候的架构图如下：



通过反向代理和CDN可以使绝大部分的用户请求根本就到达不了应用服务器集群，因为反向代理服务器和CDN中存储的热点数据已经满足了这些请求。

七：使用分布式文件系统和分布式数据库系统

数据库虽然经过读写分离，但两台服务器还是难以满足逐渐增长的业务需求，单个文件系统服务器也无法存储逐渐增加的数据。这个时候解决方案和应用服务器的解决方案一样，那就是继续构建服务器集群，使用更多的服务器来处理用户用户请求。架构图如下：


数据库实现集群相对来说是比较难的，因为不同服务器的数据库之间数据的统一性很难保持。分布式数据库也是网站数据库拆分的最后手段，只有在单表规模非常庞大的时候才使用，不到万不得已时，尽量不要使用（个人建议哈）。网站常用的数据库拆分手段是业务分库，把不同业务的数据库部署到不同的服务器上，但这样有一个缺点就是不同数据库之间的表不能进行联合查询操作了，所以在分库的时候一定要合理设计不同数据库的表结构。

八：使用NoSQL和搜索引擎

网站数据量极大地情况下，关系型数据库的查询性能会大打折扣。这个时候可以使用NoSQL和独立的搜索引擎服务器来实现网站的部分查询功能。这个时候架构图如下：



由于应用程序访问的数据源有缓存，数据库，文件系统，搜索引擎，NoSQL,所以可以提供一个统一的数据访问模块来访问各种数据，避免应用程序管理太多数据源。

九：业务拆分

当业务规模非常大的时候，一台服务器的请求再少可能也比较繁忙，因为它处理的业务实在太多了。面对这种情况，网站一般会采取业务拆分的手段。将不同的业务部署到不同的服务器上以进一步减轻应用服务器压力。这个时候架构图如下：

十：分布式服务

随着网站发展为超大规模集团性网站的时候，还可以通过分布式服务的方法来进一步提高网站性能。将不同的服务独立部署，并且每个服务都有自己的服务器集群。不同的应用程序集群通过访问这些分布式业务来完成用户请求的处理。分布式在服务器数量达到数万台的时候会大大减轻网站的各方面成本。这个时候的网站架构图如下：



到这里大型网站的所有架构技术问题基本上都可以解决了，期待以后还会出现更好的网站架构方案。
本文章参考书籍 《大型网站技术架构核心原理与分析》

最后再推荐一个可以帮助技术人员实现技术变现的平台， 技易 ，微信公众号如下: