在许多小公司和小企业，尤其是涉及电子广告和电子资讯类的网站，其网站的日PV不超过一百万，但由于其重要性，也要求网站应该具备负载均衡高可用的特点;另一方面，由于成本的制约，公司都会要求系统架构师设计的方案能够用最少的预算来满足这个要求，作为运维架构师的我们，应该如何满足这个要求呢?

首先是机房的选择，如果公司有自己的机房那是最好不过的了;如果没有自己的机房，建议放在BGP机房内托管，最好是选择带有硬件防火墙的BGP机房，在安全方面会更有保障。另外，如何选择服务器呢?在有了负载均衡高可用的集群环境后，我们完全可以自己组装服务器，这在性价比上也是较高的。像IBM和DELL等品牌的服务器，虽然质量有保障，但价格还是比较昂贵的。当然了，一切以稳定为前提和原则。



另外，如果考虑用云产品来部署自己的网站，可以对比下阿里云和亚马逊云的价格，亚马逊AWS宣布入华后，阿里云的全线产品下降了30%。而云计算相比传统IT的较大优势在于成本。如果对比下同等规模的机器，可以发现阿里云在价格上具有绝对的优势。所以对于小型网站来说，可以考虑采用阿里云的方式进行部署。

网站架构设计首先要考虑的是负载均衡设备的选择。这里有两种选择，一种是通过硬件来进行，常见的硬件有比较昂贵的NetScaler、F5 BIG-IP等商用的负载均衡器，优点就是有专业的维护团队来对这些服务进行后期维护;缺点就是开销太大，所以对于规模较小的网络服务来说暂时还没有使用的需要。另外一种就是类似于LVS/HAProxy、Nginx等基于Linux的负载均衡软件策略，这些都是通过软件级别来实现的，所以费用非常低廉，小型企业和公司大都会选择软件级别的负载均衡。至于负载均衡高可用架构，首推是Nginx/HAProxy+Keepalived架构，可能有读者会有疑问，为什么不选择基于LVS/DR+Keepalived的集群方案呢?这是因为我们部署的网站一般都会有动静分离、正则分发的需求，如果最初始选用LVS+Keepalived的架构，那么至少又要在中间加一层二级负载均衡的机器，这样会比较耗机器，无形中也会增加整个网站的成本。另外，很多朋友都比较担心的一个问题，认为Nginx/HAProxy+Keepalived的稳定性不如LVS+Keepalived，这其实是个误解。我们通过十几个项目的实施和几年的观察，发现这些软件级别的负载均衡器的稳定性确实很好，在高并发的情况下宕机的可能性微乎其微。而近期实施的一个商业网站，用的就是HAProxy+Keepalived，在亿PV/日高并发流量的冲击下，HAProxy稳如磐石。而小公司的并发和流量一般不是特别大，大概一天持续在100万~500万PV/日之间，所以这里也向大家推荐使用HAProxy+Keepalived。

在实际的项目实施过程中笔者发现，像这样的集群方案也比较耗费资源，特别是对于网站规模较小，机器非常少的情况，效果会不太好。笔者之前维护的公司有一个新闻类网站(此域名做了无害处理，非真实域名)，其服务器就比较少，而且是阿里云主机，前期做的是HAProxy+Keepalived集群方案，但发现效果并不是特别好，因为阿里云主机的带宽都是共享100MB，实际上分配到网站入口的带宽仅仅只有10MB左右，繁忙的时候会严重影响业务，虽然每个月我们通过加钱的方式来增加HAProxy+Keepalived的入口带宽，但并不是完美的解决方案，其他机器的共享带宽没有得到充分的利用。此外，由于所有的机器都是独享型主机，二层交换机也并不集中在一个机柜上，若在中间加一层HAProxy代理，网站的速度很明显又会变慢。这时候，笔者突然想到了最简单和原始的负载均衡机制，即DNS轮询，通过在美国的HostMonster(DNS提供商，国内像新网和万网均提供DNS轮询功能)上配置3个www的A主机，这样就解决了上面所说的一系列问题，后期如果流量持续增加，还可以增加机器，将网站入口由原先的单一入口模式改成分布式的，而且完全不影响网站的访问速度。当然了，平时一定要注意服务器的监控和服务器的稳定情况，毕竟每宕机一台服务器，肯定会有用户受到影响的。

通过这次成功的项目实施，我也明白了一个道理：集群的部署不应该一成不变，而应该根据具体情况具体分析，哪种方案实用就用哪种，哪怕是最简单的DNS轮询。

如果网站是放在IDC机房托管，而机房的最前面也没有硬件防火墙防护，那么应该尽量做好流量监控的工作，笔者一般会在主Nginx/HAProxy上安装Nload软件来对流量进行监控，Nload可以对流量进行即时监控。

很多对集群感兴趣的读者经常问我，如果网站要部署负载均衡高可用的Linux集群方案，而公司又想用最节省成本的方式来实施的话，一般需要几台服务器呢?如果资金比较充裕，推荐大家用7台来实施，即LB(2台)+Web(2台)+MySQL(2台)+NFS(1台);如果资金非常不充裕，这个方案其实还是可以压缩的，即2+2架构，最前面是2台Nginx/HAProxy+Keepalived机器，后面是2台配置比较好的Web机器(推荐DELL R710)，MySQL数据库采用一主一从的方式，分别放在2台Web机器上，监控的Nagios部署在从Nginx/HAProxy机器上，流量监控一般放在主Nginx/HAProxy上，软件采用的是MRTG+Nload的方式，文件服务器这里用的是单NFS，放在备HAProxy机器上，Web机器采用挂载NFS的目录作为本地的代码或图片存放的方法;当然了，如果大家的公司对文件服务器有更高要求的时候(比如网站的图片数量比较多的时候)，可以考虑再增加一台图片服务器。

在类似以上的小公司集群架构里，应如何解决Session同步的问题呢?可以采用Nginx的ip_hash和HAProxy的balance source算法，它们算法的原理是一样的，都会让某一客户机在相当长的一段时间内只访问固定的后端的某台真实的Web服务器。这样Session会话就会得以保持，我们在网站的页面上进行登录的时候，就不会在两台Web服务器之间跳来跳去了，自然也不会出现登录一次后网站又提醒你重新登录的情况，事实上，在千万级PV/日的网站上我们也尝试过用这些方式来解决Session同步的问题，效果也是相当不错的。

另外，小公司的Web服务器也至少有两种选择：一种是Apache，另一种是Nginx。在流量和并发量不大的环境下，完全可以选择Apache作为我们的Web服务器，虽然它的抗并发能力不高，但它的稳定性是最好的，笔者的许多电子商务网站都是基于Apache来提供Web应用的。

MySQL在这里用的就是一主一从的设计，虽然很多朋友觉得这种设计比较简单，但事实证明，它也是最稳定的。我的电子商务网站采用的也是这种架构，几年下来，从来没有因为数据库的故障而发生丢单现象。另外，从MySQL机器并非仅仅只起一个备份和备机的作用，我们设计的数据库读写分离，可将后台的复杂查询转到从MySQL机器上以减轻主MySQL数据库的压力。当然了，MySQL的主从复制状态监控也是非常重要的，笔者一般是通过Nagios和Shell脚本进行双监控的方式。

如何能帮企业节约和省钱，这其实也是运维架构师的工作职责之一，希望大家在工作中能领悟到这点。这样设计出来的网站，极具性价比，同时又具备高可用的特点，特别适合流量不大，但稳定性要求比较高的网站，有需求的朋友可以参考此架构设计。
​