网站系统架构梳理-解决高负载高并发

随着互联网业务的不断丰富，网站系统架构已经细分到方方面面，尤其对于大型网站来说，所采用的技术更是涉及面非常广，从硬件到软件、编程语言、数据库、WebServer、防火墙等各个领域都有了很高的要求，已经不是原来简单的html静态网站所能比拟的。

1）对于一个中小型网站(如个人网站），完全可以使用最简单的html静态页面就可实现，配合一些图片达到美化效果，所有的页面均存放在一个目录下，这样的网站对系统架构、性能的要求都很简单。
2）对于一个大型网站（如门户网站），在面对大量用户访问、高并发请求方面，基本的解决方案集中在这样几个环节：使用高性能的服务器、高性能的数据库、高效率的编程语言、还有高性能的Web容器。

以上提供的解决思路在一定程度上意味着更大的投入，并且这样的解决思路具备瓶颈，没有很好的扩展性。下面从低成本、高性能和高扩张性的角度梳理下解决高负载高并发网站的措施：

1）HTML静态化
其实大家都知道，效率最高、消耗最小的就是纯静态化的html页面，所以我们尽可能使我们的网站上的页面采用静态页面来实现，这个最简单的方法其实也是最有效的方法。但是对于大量内容并且频繁更新的网站，
我们无法全部手动去挨个实现，于是出现了我们常见的信息发布系统CMS，像我们常访问的各个门户站点的新闻频道，甚至他们的其他频道，都是通过信息发布系统来管理和实现的，信息发布系统可以实现最简单的
信息录入自动生成静态页面，还能具备频道管理、权限管理、自动抓取等功能，对于一个大型网站来说，拥有一套高效、可管理的CMS是必不可少的。

除了门户和信息发布类型的网站，对于交互性要求很高的社区类型网站来说，尽可能的静态化也是提高性能的必要手段，将社区内的帖子、文章进行实时的静态化，有更新的时候再重新静态化也是大量使用的策略，
像Mop的大杂烩就是使用了这样的策略，网易社区等也是如此。目前很多博客也都实现了静态化。

同时，html静态化也是某些缓存策略使用的手段，对于系统中频繁使用数据库查询但是内容更新很小的应用，可以考虑使用html静态化来实现，比如论坛中论坛的公用设置信息，这些信息目前的主流论坛都可以进
行后台管理并且存储再数据库中，这些信息其实大量被前台程序调用，但是更新频率很小，可以考虑将这部分内容进行后台更新的时候进行静态化，这样避免了大量的数据库访问请求。

在进行html静态化的时候可以使用一种折中的方法，就是前端使用动态实现，在一定的策略下进行定时静态化和定时判断调用，这个能实现很多灵活性的操作，使用了这样的方法，通过设定一些html静态化的时间
间隔来对动态网站内容进行缓存，达到分担大部分的压力到静态页面上，可以应用于中小型网站的架构上。

2）图片服务器分离
大家知道，对于Web服务器来说，不管是Apache、Nginx还是其他容器，图片是最消耗资源的，于是我们有必要将图片与页面进行分离，这是基本上大型网站都会采用的策略，他们都有独立的图片服务器，甚至很多
台图片服务器。这样的架构可以降低提供页面访问请求的服务器系统压力，并且可以保证系统不会因为图片问题而崩溃。在应用服务器和图片服务器上，可以进行不同的配置优化，比如Apache在配置ContentType的
时候可以尽量少支持，尽可能少的LoadModule，保证更高的系统消耗和执行效率。

另外，在处理静态页面或者图片、js等访问方面，可以考虑使用lighttpd代替Apache，它提供了更轻量级和更高效的处理能力。    

3）数据库集群和库表散列
大型网站都有复杂的应用，这些应用必须使用数据库，那么在面对大量访问的时候，数据库的瓶颈很快就能显现出来，这时一台数据库将很快无法满足应用，于是我们需要使用数据库集群或者库表散列。

在数据库集群方面，很多数据库都有自己的解决方案，Oracle、Sybase等都有很好的方案，常用的MySQL提供的Master/Slave也是类似的方案，您使用了什么样的DB，就参考相应的解决方案来实施即可。

上面提到的数据库集群由于在架构、成本、扩张性方面都会受到所采用DB类型的限制，于是我们需要从应用程序的角度来考虑改善系统架构，库表散列是常用并且最有效的解决方案。我们在应用程序中安装业务和应
用或者功能模块将数据库进行分离，不同的模块对应不同的数据库或者表，再按照一定的策略对某个页面或者功能进行更小的数据库散列，比如用户表，按照用户ID进行表散列，这样就能够低成本的提升系统的性能
并且有很好的扩展性。sohu的论坛就是采用了这样的架构，将论坛的用户、设置、帖子等信息进行数据库分离，然后对帖子、用户按照板块和ID进行散列数据库和表，最终可以在配置文件中进行简单的配置便能让系
统随时增加一台低成本的数据库进来补充系统性能。

4）缓存
缓存一词搞技术的都接触过，很多地方用到缓存。网站架构和网站开发中的缓存也是非常重要。这里先讲述最基本的两种缓存。高级和分布式的缓存在后面讲述。
架构方面的缓存，对Apache比较熟悉的人都能知道Apache提供了自己的mod_proxy缓存模块，也可以使用外加的Squid进行缓存，这两种方式均可以有效的提高Apache的访问响应能力。
网站程序开发方面的缓存，Linux上提供的Memcached是常用的缓存方案，不少web编程语言都提供memcache访问接口，php、perl、c和Java都有，可以在web开发中使用，可以实时或者Cron的把数据、对象等内容进行
缓存，策略非常灵活。一些大型社区使用了这样的架构。

另外，在使用web语言开发的时候，各种语言基本都有自己的缓存模块和方法，PHP有Pear的Cache模块和eAccelerator加速和Cache模块，还要知名的Apc、XCache（国人开发的，支持！）php缓存模块，Java就更多了，
.net不是很熟悉，相信也肯定有。

5）镜像
镜像是大型网站常采用的提高性能和数据安全性的方式，镜像的技术可以解决不同网络接入商和地域带来的用户访问速度差异，比如ChinaNet和EduNet之间的差异就促使了很多网站在教育网内搭建镜像站点，数据进
行定时更新或者实时更新。在镜像的细节技术方面，这里不阐述太深，有很多专业的现成的解决架构和产品可选。也有廉价的通过软件实现的思路，比如Linux上的rsync等工具。

6）负载均衡
负载均衡将是大型网站解决高负荷访问和大量并发请求采用的终极解决办法。
a）硬件四层交换
第四层交换使用第三层和第四层信息包的报头信息，根据应用区间识别业务流，将整个区间段的业务流分配到合适的应用服务器进行处理。　第四层交换功能就象是虚IP，指向物理服务器。它传输的业务服从的协议
多种多样，有HTTP、FTP、NFS、Telnet或其他协议。这些业务在物理服务器基础上，需要复杂的载量平衡算法。在IP世界，业务类型由终端TCP或UDP端口地址来决定，在第四层交换中的应用区间则由源端和终端IP地址、
TCP和UDP端口共同决定。在硬件四层交换产品领域，有一些知名的产品可以选择，比如Alteon、F5等，这些产品很昂贵，但是物有所值，能够提供非常优秀的性能和很灵活的管理能力。Yahoo中国当初接近2000台服务器
使用了三四台Alteon就搞定了。

b）软件四层交换
大家知道了硬件四层交换机的原理后，基于OSI模型来实现的软件四层交换也就应运而生，这样的解决方案实现的原理一致，不过性能稍差。但是满足一定量的压力还是游刃有余的，有人说软件实现方式其实更灵活，处
理能力完全看你配置的熟悉能力。
软件四层交换我们可以使用Linux上常用的LVS来解决，LVS就是Linux Virtual Server，他提供了基于心跳线heartbeat的实时灾难应对解决方案，提高系统的鲁棒性，同时可供了灵活的虚拟VIP配置和管理功能，可以同时
满足多种应用需求，这对于分布式的系统来说必不可少。
一个典型的使用负载均衡的策略就是，在软件或者硬件四层交换的基础上搭建squid集群，这种思路在很多大型网站包括搜索引擎上被采用，这样的架构低成本、高性能还有很强的扩张性，随时往架构里面增减节点都非常
容易。这样的架构我准备空了专门详细整理一下和大家探讨。

c）七层交换
大家都知道TCP/IP的七层协议，四层交换是基于传输层的，在这一层只能处理连接的管理，但是无法和业务关联起来，通常只能针对tcp、udp的连接来进行处理，而真正的业务逻辑需要后面的服务器群自己来处理，随着
技术的发展，今天，我们在很多高级的应用中出现了七层交换。
七层交换是基于TCP/IP的第七层应用层来实现的，在这一层上，首先我们可以区分出具体的应用，比如HTTP、TELNET、FTP、DNS等等，还能根据应用中传送的内容来进行策略的管理，比如我们有这么两个网站的路径a.com/music/… 
和a.com/photo/… 原来基于四层交换只能把这两个url的请求都分发到后面一组服务器上，但是七层交换可以判断访问的是music/还是photo/路径，然后分别分发到不通的服务器群上，从而实现更灵活的系统架构设计。
当然，七层交换也分硬件和软件的实现方式，在这里就不细说了，硬件有著名的F5、Nortel等，软件有Haproxy等，七层交换的软件目前还是在性能上要远远差别于硬件实现的，要知道，这些硬件都价格不菲 :)

------------------------顺便说下LNMP框架的web业务网站从小演变到大的过程-------------------------------

1）单台服务器

网站初期还只是一个小站，访问量一天也没有多少uv（100以内），所以用一台1核1g的机器足够了。机器上安装的是CentOS系统，然后搭建了nginx+php-fpm+mysql的LNMP环境。

2）一台演变为两台服务器

后续访问量越来越大，日uv突破5000，单台机器不够了，本可以增加机器配置编程4核8G，但是考虑到还要换机器，所以直接添置一台DB服务器单独跑MySQL服务。原来的服务器只需要跑nginx+php-fpm，新加服务器跑MySQL服务。 
在这里，往往会遇到一个问题，就是如何在多台机器上编译安装 LAMP 环境，在单台机器上编译都没有问题，PHP 放在最后，因为它依赖 MySQL，但我们这里需要把 MySQL 放到另一台机器，所以编译肯定会报错。
解决这个问题，其实很简单，即使web上不需要MySQL，我们也要安装一下，因为编译 PHP 的时候依赖它。

3）增加memcached服务

访问量持续增加，uv上w了，DB 服务器和 WEB 服务器压力越来越大，这时候我们需要加一个缓存来缓解 DB 服务器的压力。同样是两台机器，只不过 WEB机器配置需要升级了，原来的1核1g不够用了，
不仅要加cpu还要加内存，因为在 WEB 上我们需要运行 memcached 服务，同时 php 也需要安装memcache 扩展。

4）增加Web服务器并做MySQL主从

访问量又扩大了，uv到了5w，数据库服务器因为一开始配置就挺高，所以没有压力，但是 WEB 服务器负载有点高了，在高峰期可以感觉到网站访问变慢。所以，这时候不得不考虑要加一台 WEB 服务器。
另外，数据库是单点，如果磁盘损坏，可能会带来意想不到的后果，所以我们有必要加一台从 DB 服务器，作为数据的备份。

在这里，两台 WEB 服务器我们并没有做负载均衡，因为为了节省资源，暂时先不去购买服务器做负载均衡，我们使用 DNS 轮询的方法来把用户的请求发到两台机器上，但这种该架构有个问题，一旦一台
WEB机器宕机，将会有一半的用户访问不到业务。还有一个问题，我们也需要考虑到，如何保证 WEB 服务器上的数据一致，比如用户可能会上传图片到 WEB 服务器上，假如他上传到了 WEB1 上，那WEB2 
是不存在这个图片的。所以我们需要做一个共享存储让 WEB1 和 WEB2 同时可以访问，所以在这里我把 WEB1 的一个目录使用 NFS 共享出来，让 WEB2 去挂载。还有一个问题就是memcached服务如何分配，
在这里，我是把 memcaced 服务分别安装到两台 WEB 上的，自己用自己的 memcached 服务。

5）增加MySQL读写分离

访问量持续上升，uv 已经到了数十万。网站在高峰期总是会卡顿那么一段时间。经排查，发现在 MySQL 服务器上有很多慢查询，经过各种调优依然没有太明显效果，最后决定做读写分离。

做读写分离有两种方案，第一可以借助程序来实现，把所有的写操作指向到主 MySQL ，所有的读操作指向到从 MySQL。对于这种方案，机器数量和环境不用做任何调整，唯一要做的是程序代码要改一下。
第二可以借助 mysql-proxy 来实现，不用修改代码，节省开发成本，但需要增加一个角色。架构是这样的。

6）避免单点引入负载均衡环境

两台 WEB 服务器因为有一台比较老，所以在高峰期时，终究是没有能扛住而挂掉。结果影响了一半的用户访问不到网站了。经过此次事故，我不得不修改架构，尽量避免单点，于是在 WEB 前端设置了负载均衡器，并且做了高可用。

在这里我拿 nginx 做了负载均衡器，并没有使用 lvs，因为我觉得 nginx 更容易操作，更好控制。为了节省成本，我并没有单独把 mysql-proxy 摘出来作为独立服务器，因为那样的话，也得为它考虑单点问题。在这个架构中，
其实还有一个缺陷，就是 NFS 服务端也是有风险的，更加保险的做法是单独搞一台服务器做NFS服务。

7）继续扩充服务规模

uv上升到100w，两台WEB服务器明显不够用了，而瓶颈并不在MySQL上。所以，只增加WEB，同时把NFS服务器单独摘出来，并做一个备用 NFS 服务器。

8）引入NoSQL环境

uv近1000w，三台 WEB 服务器也早已不够，增加到5台，而 MySQL 服务器压力逐渐变大，针对 MySQL 的慢查询，发现压力主要体现在个别 SQL 语句上，该优化的已经优化到极致，对于这几个查询，其实是可以使用 NoSQL 的。
于是，我找懂php开发的朋友帮我修改了程序，把一些访问量大的数据存储到redis，从而减少了对 MySQL 服务器的压力。 而 Redis 为了防止单点也做了主从。

9）MySQL架构演变

假设一个网站（discuz）从最开始访问量很小做到日pv千万，我们来推测一下它的mysql服务器架构演变过程。
a）第一阶段
网站访问量日pv量级在1w以下。单台机器跑web和db，不需要做架构层调优（比如，不需要增加memcached缓存）。此时，数据往往都是每日冷备份的，但有时候如果考虑数据安全性，会搭建一个mysql主从。

b）第二阶段
网站访问量日pv达到几万。此时单台机器已经有点负载，需要我们把web和db分开，需要搭建memcached服务作为缓存。也就是说，在这个阶段，我们还可以使用单台机器跑mysql去承担整个网站的数据存储和查询。如果做 MySQL 主从，目的也是为了数据安全性。

c）第三阶段
网站访问量日pv达到几十万。单台机器虽然也可以支撑，但是需要的机器配置要比之前的机器好很多。如果经费允许，可以购买配置很高的机器来跑mysql服务，但是并不是说，配置翻倍，性能也翻倍，到了一定阶段配置增加已经不能带来性能的增加。
所以，此阶段，我们会想到做mysql服务的集群，也就是说我们可以拿多台机器跑MySQL。但，MySQL的集群和web集群是不一样的，我们需要考虑数据的一致性，所以不能简单套用做web集群的方式（lvs，nginx代理）。可以做的架构是，mysql主从，一主多从。
为了保证架构的健壮和数据完整，主只能是一个，从可以是多个。

还有一个问题，我们需要想到，就是在前端web层，我们的程序里面指定了MySQL机器的ip，那么当mysql机器有多台时，程序里面如何去配置？discuz，其实有一个功能，支持MySQL读写分离。即，我们可以拿多台机器跑MySQL，其中一台写，其他多台是读，
我们只需要把读和写的 IP 分别配置到程序中，程序自动会去区分机器。当然，如果不使用 discuz 自带的配置，我们还可以引用一个软件叫做 mysql-proxy, 使用他来实现读写分离。它支持一主多从的模式。

d）第四阶段
网站访问量日pv到几百万。之前的一主多从模式已经遇到瓶颈，因为当网站访问量变大，读数据库的量也会越来越大，我们需要多加一些从进来，但是从的数量增加到数十台时，由于主需要把bin-log全部分发到所有从上，那么这个过程本身就是一件很繁琐的事情，
再加上频繁读取，势必会造成从上同步过来的数据有很大延迟。所以，我们可以做一个优化，把mysql原来的一主多从变为一主一从，然后从作为其他从的主，而前面的主只负责网站业务的写入，而后面的从不负责网站任何业务，只负责给其他从同步bin-log。这样还可以继续多叠加几个从库。

e）第五阶段
网站访问量日pv到1千万的时候，我们发现，网站的写入量非常大，我们之前架构中只有一个主，这里的主已经成为瓶颈了。所以，需要再近一步做出调整。比如，我们可以把业务分模块，把用户相关的单独分离出来，把权限、积分等也可以分离出来单独跑一个库，然后再做主从，也就是所谓的分库。
当然也可以换一个纬度，把访问量或者写入量大的表单独分离出来，跑在一台服务器上，也可以把一个表分成多个小表。这一步操作，涉及到一些程序上的改动，所以需要事先和开发同事做好沟通和设计。总之，这一步要做的就是分库分表。

-----------写在后面--------
再往后发展，继续把大表分小表即可，而国内阿里淘宝网站的数据量是巨量的，他们的数据库全部都 MySQL，他们的MySQL架构就是遵循分库分表这个原则的，只不过他们划分规则会有很多纬度，比如可以根据地域划分，可以根据买家、卖家划分，可以根据时间划分等等。