** 如果您觉得文章对您有点用，麻烦在您阅读、收藏、转发的时候，顺手帮忙点个赞、留个言、加关注，这是我继续写下去的绝佳动力。**
在和网友交流的时候，经常听到网友报怨说SiteServer CMS性能不好，速度不快，让帮忙想想解决办法。本人使用SiteServer CMS架构过几个也算不小的门户网站，并没有碰到这么明显的性能问题。抱着好奇心帮网友看了看他的系统部署结构，了解完之后真的有种让人哭笑不得的感觉，后台数据已经超100万了竟然还在使用access数据库。
正好最近在研读李神的《大型网站技术架构》一书，就想着结合SiteServer CMS多年的使用经验，写两篇文章和大家互相交流学习。本篇是以讲解大型网站架构演化发展历程为主，以及大型网站的特性，这篇是以理论为主。后面跟着写一篇利用SiteServer CMS 如何架构大型网站，这篇以实践为主。
一、大型网站系统应有的特点
- **高并发、大流量 **
需要面对高并发用户，大流量访问。Google 日均 PV 35 亿，日 IP 访问数 3 亿；腾讯 QQ 的最大在线用户数 1.4 亿（2011年数据）。 - **高可用 **
系统 7 x 24 小时不间断服务。 - **海量数据 **
需要存储、管理海量数据，需要使用大量服务器。Facebook 每周上传的照片数量接近 10 亿，百度收录的网页数目有数百亿，Google 有近百万台服务器为全球用户提供服务。 - **用户分布广泛，网络情况复杂 **
许多大型互联网站都是为全球用户提供服务的，用户分布范围广，各地网络情况千差万别。在国内，还有各个运营商网络互通难的问题。 - **安全环境恶劣 **
由于互联网的开放性，使得互联网站更容易受到攻击，大型网站几乎每天都会被黑客攻击。 - **需求快速变更，发布频繁 **
和传统软件的版本发布频率不同，互联网产品为快速适应市场，满足用户需求，其产品发布频率极高。一般大型网站的产品每周都有新版本发布上线。 - **渐进式发展 **
几乎所有的大型互联网网站都是从一个小网站开始，渐进地发展起来的。Facebook 是扎克伯格同学在哈佛大学的宿舍里开发的；Google 的第一台服务器部署在斯坦福大学的实验室；阿里巴巴是在马云家的客厅诞生的。好的互联网产品都是慢慢运营出来的，不是一开始就开发好的，这也正好与网站架构的发展演化过程对应。
二、大型网站架构演化发展历程
阶段1：单机时代
草根时期，快速开发网站并上线。当然，通常只是先试水，用户规模也没有形成，经济能力和投入也非常有限。应用程序、数据库、文件等所有资源都集中在一台 Server上，典型案例：基于 LAMP 架构的 PHP 网站；
优点：简单、快速迭代达成业务目标；
缺点：存在单点、谈不上高可用；
技术点：应用设计要保证可扩展；
阶段2：使用缓存改善网站性能
好景不长，随着访问的人越来越多，你发现响应速度又开始变慢了，查找原因，发现是访问数据库的操作太多，导致数据连接竞争激烈，所以响应变慢，但数据库连接又不能开太多，否则数据库机器压力会很高，因此考虑采用缓存机制来减少数据库连接资源的竞争和对数据库读的压力。
优点：简单有效、方便维护；
缺点：存在单点、谈不上高可用；
技术点：客户端（浏览器）缓存、前端页面缓存、页面片段缓存、本地数据缓存/数据库缓存、远程缓存；
知识体系：缓存技术，包括像Map数据结构、缓存算法、所选用的框架本身的实现机制等。
缓存主要为分三种：
- 页面缓存：客户端缓存，减少对网站的访问；
- 本地缓存：访问速度快，但数据量有限，减少对DB查询；
- 远程缓存：远程访问，可以集群，因此容量不受限制；
阶段3：应用和数据分离
随着网站业务的发展，一台服务器逐渐不能满足需求，越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足，这时候，就需要将应用和数据分离，此时整个网站使用三台服务器：应用服务器，文件服务器和数据库服务器。
优点：简单有效、方便维护、提高不同Server对硬件资源的利用率；
缺点：存在单点、谈不上高可用；
技术点：文件服务器部署、数据库服务器，扩展数据访问模块；
三台服务器对硬件资源要求各不相同：
- 应用服务器需要处理大量的业务逻辑，因此需要更快更强大的CPU；
- 数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存；
- 文件服务器需要存储大量的用户上传文件，因此需要更大的硬盘；
阶段4：使用应用服务器集群改善网站的并发处理能力
当有一台服务器的处理能力、存储空间不足时，不要企图去更换更强大的服务器，对于大型网站而言，不管多么强大的服务器，都满足不了网站持续增长的业务需求。此时，应该考虑增加一台服务器分担原有服务器的访问以及存储压力。
优点：增加服务器和HA机制，系统性能及可用性得到保证；
缺点：应用之间缓存、Session一致性问题；
技术点：负载均衡；
知识体系：负载均衡技术（硬件负载均衡、软件负载均衡、负载算法等）、主备技术（ARP欺骗、linux heart-beat等）、状态信息或缓存同步技术（Cookie技术、UDP协议、状态信息广播、所选用的缓存同步技术的实现细节等）、共享文件技术（NFS等）、存储技术（存储设备等）。
使用应用服务器集群改善网站的并发处理能力会碰到一些问题，典型的有：
1、如何让访问分配到这两台机器上，这个时候通常会考虑的方案是IIS自带的负载均衡方案，或LVS这类的软件负载均衡方案；
2、如何保持状态信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储、cookie或同步session信息等机制等；
3、如何保持数据缓存信息的同步，例如之前缓存的用户数据等，这个时候通常会考虑的机制有缓存同步或分布式缓存；
4、如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件系统或存储等；
在解决了这些问题后，终于是把webserver增加为了多台，系统终于是又恢复到了以往的速度。通过集群解决高并发、海量数据问题的常用手段，实现系统的可伸缩性。通过负载均衡调度器，可将用户访问分发到集群中的某台 Server 上，应用服务器的负载压力不再成为整个网站的瓶颈。
阶段5：动态程序和静态页面分离
动静分离也是提高网站响应速度的一种常用方式。将动态请求与静态请求分离开，尽量减少对应用服务器的压力。同时，可以再进一步对静态请求，进行缓存，以加快响应速度。需要开发人员配合（把静态资源放独立站点下）。
优点：减轻应用负载压力，针对静态文件缓存；
缺点：静态文件缓存更新失效问题；
技术点：动静分离、静态文件缓存方案；
阶段6：使用反向代理和CDN加速网站响应
CDN和反向代理的基本原理都是缓存，使用 CDN 和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。区别在于：
- CDN部署在网络提供商的机房，用户在请求时，能从最近的机房获取到资源；
- 反向代理部署在网站的中心机房，当用户请求到达中心机房后，首先访问的是机房的反向代理服务器，如果反向代理服务器中存储了用户请求的资源，那么优先返回该部分资源给用户。
优点：减轻应用负载压力，异地缓存有效解决不同地方用户访问过慢的问题；
缺点：成本大幅增加，架构进一步复杂化，也维护难度进一步增大，静态文件缓存更新失效问题；
技术点：CDN、反向代理方案；
阶段7：数据库读写分离
单台数据库也感觉快撑不住了，一般都会尝试做“读写分离”，因为大部分互联网“读多写少”。目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到另外一台服务器上，网站利用这一功能，实现数据库读写分离，从而改善数据库负载压力。
优点：简单有效、降低数据库单台压力；
缺点：读写分离，增加程序难度，架构变复杂，维护难度增加；
技术点：数据库主从同步部署，扩展数据访问模块，实现读写分离；
知识体系：数据读写分离要求对数据库的复制、standby等策略有深入的掌握和理解，同时会要求具备自行实现的技术；
阶段8：应用和数据库垂直拆分（业务拆分）
随着业务越来越复杂，网站的功能越来越多，虽然部署层面是采用的集群，但是应用程序架构层面还是“集中式”的，这样会导致很多耦合，不便于开发、维护，而且容易“一荣俱损”。所以，通常会把网站拆分出不同的子站点来单独宿主。
通过分而治之的手段将整个网站业务分成不同的产品线，如首页、商铺、订单、卖家、买家等拆分成不同的产品线，分归不同的业务团队负责。各个应用之间可以通过建立一个超链接建立关系，也可以通过消息队列进行数据分发。
应用都拆了，由于单个数据库的连接，QPS，TPS，I/O处理能力都非常有限，DB层面也可以去做垂直分库操作，目前一个大型互联网公司都用分库甚至分表方案。
优点：降低耦合、分压；降低DB耦合、分压DB；
缺点：应用架构复杂；数据访问模块复杂；
技术点：业务抽取拆分；
三、网站架构总结
这个世界没有那个网站从诞生起就是大型网站，也没有哪个网站从发布起就有庞大的用户，高并发的访问以及海量的用户，大型网站都是从小型网站发展而来的。
大型网站架构技术的核心价值不是从无到有建立一个网站，而是能够伴随小型网站业务的逐步发展，慢慢演化成一个大型网站，在此过程中，不需要放弃什么，不需要推翻什么，不需要剧烈的革命，就慢慢的把一个有=只有一台服务器，几百个用户的小网站演化成一个几十万台服务器，数十亿用户的大型网站。
- **一切以解决业务目标为首要任务； **
- **没有以业务为目标的任何架构、技术，都是毫无意义的耍流氓； **
- **再牛逼的架构、再牛逼的技术，不能够解决业务的问题，你也只能算是会架构、会技术的工匠，而不能算是真正意义上的架构师； **
- **业务成就了技术，平台成就了人，事业成就了人，而不是相反； **