本文主要是介绍1. 大型网站技术架构论述，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
2017-1-4 之前就拜读就阿里李智慧老师的大作《大型网站技术架构 核心原理与案例分析》，之前只是简单的通读了一下，最近正好抽出时间，再次精读一下并做个总结。
1. 大型网站架构演化
大型网站软件系统的特点
- 高并发、大流量；
- 高可用(7x24小时不间断服务)
- 海量数据；
- 用户分布广泛、网络情况复杂；
- 安全环境恶劣；
- 需求快速变更，发布频繁；
- 渐进式发展
大型网站架构烟花发展历程
1.初始阶段的网站架构
大型网站都是从小型网站发展而来，网站架构也是一样的，都是从小型网站架构逐步发展而来。最开始的小型网站访问人数不多，一台服务器绰绰有余，这时的网站架构如下图：
数据库、应用程序、文件全部都存放在一台服务器上。
2.应用服务和数据服务分离
随着业务的发展，一台服务器逐渐不能满足需求；越来越多用户访问导致性能越来越差，这时首先做的应该是应用和数据分离。分离后架构采用3台服务器：应用服务器、文件服务器和数据库服务器。这三个服务器的硬件需求各不相同：
- 应用服务器：需要处理大量的业务逻辑，需要更快更强劲的CPU；
- 数据库服务器：需要快速的磁盘检索和数据缓存，需要更快地硬盘和更大的内存。
- 文件服务器：需要存储大量用户上传的图片等文件，需要更大的硬盘。
架构图如下图所示：
应用和数据分离后，不同服务器承担不同的角色，并发处理能力和数据存储空间得到很大改善。但是随着进一步发展，用户逐渐增多，面临新的挑战：数据库压力太大导致访问延迟，进而影响整个网站的性能，这时需要进一步优化：
3.使用缓存来改善网站性能
网站访问的特点遵循二八定律：80%的业务逻辑集中访问20%的数据。比如微博的热点访问。既然如此，如果我们把这一小部分集中访问的数据缓存在内存中，而不是每次都从数据库中读取，就可以减少数据库访问的压力了、从而提高整个系统数据访问速度。
网站的缓存有两种：
1. 缓存在应用服务器的本地缓存；
2. 缓存在专门的分布式缓存服务器上。
本地缓存速度快，但受到本地内存大小极限的限制。远程分布式缓存使用集群的形式。部署大内存的专门缓存服务器，理论上可以做到不受内存大小的限制。架构图如下所示：
使用缓存后，数据库数据访问压力得到缓解。但是单一应用服务器在网站访问高峰，应用服务器成为瓶颈。
4.使用应用服务器集群改善网站的并发处理能力
使应用服务器集群是为了处理高并发。永远不要想着增加单机的性能来提高网站的性能，因为硬件的发展更不上需求的发展。应用服务器实现集群是网站可伸缩集群架构设计中较为简单成熟的一种。架构图如下：
在应用服务器前通过一台负载均衡调度服务器，将来自用户的浏览器的访问请求分发到应用服务器集群中任何一台服务器上。更多的用户只需要增加更多应用服务器即可，应用服务器的负载压力不再是整个网站的瓶颈。
5. 数据库的读写分离
在使用了缓存之后，大部分的热点数据都可以直接从缓存中获得，不需要查询数据库。但是仍有一部分读操作(缓存访问不命中、缓存过期)和全部的写操作需要访问数据库。当用户数达到一定的数量级了之后，数据库因为负载压力过大而成为网站的瓶颈。
目前大部分主流的数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另外一台服务器上。我们可以利用这一特点，实现数据库的读写分离，从而改善数据库的负载压力。架构如下所示：
应用服务器需要写数据时，通过访问主数据库(写数据库)，主数据库通过主从复制机制同步数据到从数据库(读数据库).这样，当应用读取数据时直接读取从数据库的数据。为了方便应用服务器访问读写分离后的数据库，一般在应用服务器端使用专门的数据库访问模块，使数据库读写分离对应用透明。
6. 使用反向代理和CDN加速网站响应
提高网站的响应速度对提高用户体验至关重要，加速网站的访问速度主要手段有CDN和反向代理。
CDN和反向代理的基本原理都是缓存，区别在于：
1. CDN部署在网络提供商的机房，使用户请求网站服务时可以从距离自己最近的网络提供商机房获取数据；
2. 反向代理则部署在网站的机房中心，当用户请求到达机房中心后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户，就不用经过应用服务器。架构图如下：
不管是CDN还是反向代理的目的都是为了尽早的把数据返回给用户，一方面加快用户访问速度，也能减轻后端服务器的负载压力。
7. 使用分布式文件系统和分布式数据库系统
任何单一的服务器都不能满足日益增长的也无需求。数据库经过读写分离拆成2台服务器但是随着业务发展仍然不能满足需求，这时就要使用分布式数据库和分布式文件系统。
分布式数据库是网站数据库拆分的最后手段了，只有在单表数据规模非常庞大的时候才使用，不到万不得已时，网站更加常用的数据库拆分是业务的拆分，将不同的业务的数据库部署在不同的物理数据库服务器上。
架构图如下：
8. 使用NoSQL和搜索引擎
随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些，非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎，架构如下图：
这里，项目一般都是使用一个统一的数据访问模块来访问各种数据，减轻应用程序管理诸多数据源的麻烦。
9. 业务拆分
大型网站为了应付日益复杂的业务场景，通过分而治之的方法，将整个网站的业务拆分成不同的产品线，比如大型电商购物平台会将首页、上铺、订单、买家、卖家等拆分成不同产品线，分归不同的业务团队负责。
将一个网站拆分成许多不同的应用，每个应用独立部署维护。应用之间通过超链接建立关系；也可以通过消息队列进行数据分发。当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。 架构如下图：
10 分布式服务
随着业务越拆分越小，存储系统越来越庞大，也越来越复杂。由于所有应用要和所有数据库系统连接，导致数据库连接资源严重不足。
既然也多业务都会有大量重复的业务操作，那么可以将公用的业务操作提取出来供其余系统调用，而应用程序只需要管理用户界面。通过分布式服务调用公共业务服务完成具体业务操作。架构图如下：
大型网站架构技术演化到此结束。基本上大多数问题都能解决。
千万记住一点：驱动大型网站技术发展的主要力量是网站的业务发展。
技术是用来解决业务问题的，而业务的问题也可以通过业务的手段来解决。比如12306 抢票这个，除了提高并发能力还可以通过分时段抢票的业务手段解决。
这篇关于1. 大型网站技术架构论述的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
