某网站负载均衡实战

        任何网站的架构基本上都是根据业务规模不断扩展来进行演化和更新的，但不代表刚开始就不考虑规模做大后可能面临的问题，把高可用，易扩展，可靠稳定等问题放在网站建设时期多早考虑都不为过。而无论是刚成立的小网站还是亿级PV的巨型网站，高可用性都是需要优先考虑的问题。

       关于高可用性的权威解释，百度百科是这样说的：高可用性”（High Availability）通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。

       某网站的目标是做业界最好的保险中介第三方平台，和当初的淘宝、腾讯、百度一样，建设初期也是从一台服务器开始做起的，那时三个应用实例、一个数据库再加上ngxin反向代理服务都部署在这一台机器上，主要原因就是访问量小，一台机器就能够足够支撑业务运营，当然其弊端和风险不可控的现实也是很残酷的，曾在很短的时间内被肉鸡2次（另有博文总结），导致很大的运营压力，正因为此我也苦练linux安全防护秘籍，在实际中学习，在学习中应用，最终的效果是显而易见的，当然这是另外一个故事，再次就不多说了。

       很简单的道理，一台机器由于没有备份，一旦遇到突发情况必然会导致服务的中断，虽然业务量小影响倒不至于太大，但是对网站权重的积累以及搜索引擎抓取还是有很坏的影响的，在防肉鸡工作取得初步成果以后，网站的高可用性就成了摆在我面前的一个重要且紧急的工作。也正赶上阿里并购万网，服务器需要做迁移，于是借此契机对整个网站的部署架构进行了再次梳理，遵循的基本原则就是逻辑分层及分离部署，展现层、应用层和数据层在逻辑上分开的同时在物理上做相应的支持。

      首先把数据库单独部署并作主备，这次采用了阿里云现成的RDS（关系型数据库）产品，这样省去了很多的自己部署数据库的优化和监控的布置工作，并借鉴了阿里云的多年运维实践，使数据库这个网站中举足轻重的角色有了最初的保障。

      其次是应用服务器的的分离和主备，原来是5个应用用jboss的2个实例来完成的，这个直接的影响就是发布的高耦合，A系统或B系统的一个发布都会对对方产生影响，非常不利于紧急问题的处理，这次就把二者进行了分离，分别部署一个实例，这样一个升级不会对另一个造成影响。同时也对网本身和其支持系统从物理上进行了分离，A系统和B系统由于不直接和客户打交道，属于躲在幕后的英雄，所以单独用一台服务器来部署，网站及其内容发布系统和C系统以及D系统单独用一台服务器部署，所以整个下来是有2台服务器和5个jboss实例支撑了整个网站的应用层。接下来要说的主备或者说负载均衡才是本文要说的重点。

      负载均衡是高可用性的技术实现，是时下最流行的一种部署方式，百度百科对负载均衡的解释是：负载均衡 （Load Balancing） 负载均衡建立在现有网络结构之上，它提供了一种廉价有效透明的方法扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。最常见的部署方式是至少做两个完全相同的部署并且互相独立互不影响，这样才能确保一台down掉后，另一台能直接接手，同时可以把负载的压力根据一定的均衡策略进行分配。开始我想者着就做两台一模一样的机器，通过阿里云的负载均衡机制来调用，实现错误转移和压力分摊的效果，但是真正实施起来还是面临诸多问题和挑战的。

      首先，是对自动批处理任务的处理，如果两台机器都执行这些自动job，就会发生数据混乱，需要将一方屏蔽只保留一方，这也会导致另一个问题，自动任务的负载均衡无效，至少不能实现错误转移。

     第二、负载均衡机制中，session的问题是必须要面对和解决的问题，如何确保用户的访问一直保持在一台服务器上，如何确保第三方请求和回调在一个生命周期内的对象是一台服务器？

     第三、某网站的一切资源静态化的机制决定了对静态资源的处理必须谨慎，因为静态资源的生成是随时的、量大的，读写频繁的，负载均衡和资源共享两种机制的优劣需要分析和作出取舍的。

      第四、用户通过系统功能的操作上传的一些资源如何被网站无延迟的调用，否则容易出现404页面找不到的错误，这对搜索引擎是不友好的，对网站的权重影响是负面的，用户体验也是不好的。

      第五、如何通过负载均衡实现程序的热发布，现在每次发布弟兄们都搞到很晚，并且需要停掉服务。凌晨虽然业务量不大但是毕竟是有影响的，同时也会影响弟兄们第二天的工作。 

       做任何事也许都需要有所取舍，负载均衡实施需要面临的第一个问题就是资源共享和资源分发的取舍，我选择了前者，因为通过内容发布系统生成静态页面需要考虑session保持的问题（阿里云负载均衡产品可以通过配置实现会话保持），可以确保发布的页面到一台服务器上，同时可以通过资源分发机制分发到另一台服务器上，但是一旦页面量比较大的时候，需要较长时间，同时对系统资源占用比较大，IO读写频繁的话也可能遇到瓶颈，所以我选择了另外一台服务器作为资源共享，将静态资源内容同时挂载到两台负载均衡服务器上，同时给另外两个用户可以写入的权限，这样无论哪一台服务器生成的静态页面都可以实时的被另一台访问到，这其实会造成共享资源服务器的较大压力，但是好在静态资源大部分都被缓存到了CDN服务器和nginx服务器，从而在一定程度上缓解了大访问量对共享资源服务器的读写压力。

        为了清洗出恶意流量攻击我本来打算从web日志着手通过一定的策略过滤出恶意攻击者的ip并将其放入黑名单的，在分析nginx访问日志时发现有大量的的内网扫描记录，这些记录中根本看不到用户客户端的ip地址，后来了解到这些扫描是阿里云负载均衡产品的健康检查，是错误转移需要必须要做的（后来才知道），另外其会话保持也是通过cookie植入的方式实现的，具体的机理还没有深究，在使用上还未遇到太大问题。

        自动任务的解决方法我是通过把一台服务器的自动任务给清理掉，只保留了一台机器上存在，这有个弊端就是一旦那台机器宕机，自动任务将无法执行，这通过服务监控在一定程度上弥补，对用户体验方面无太大影响，需要再考虑更优方案。

       除了内容分发系统生成的静态页面外，还有用户上传的条款、图片、模板等也做了资源共享。

       关于热升级的事情，我开始想的是通过权重转移来实现，先将负载均衡的权重比例调成1:99，待半个小时以后基本上原来保持会话的用户都已完成交易，新加入的用户基本都转移到了权重为99的那台机器上，就可以把权重为1的那台服务关掉进行程序发布，通过IP进行测试和确认无问题后再用同样的方法升级另一台服务器，这种方法在一定程度上可行，但是有1%的问题依然存在，升级的时间点还是不能灵活定，如何针对那1%的用户在服务宕掉后依然可以无任何感觉的继续访问网站，负载均衡的错误转移机制可以确保用户不会掉线和不发生无法访问网站的情况，但是一旦用户登录了会员中心就会导致退出重新登录，其实这个可以通过session复制的机制来解决，这是我接下来要做的一个重点。

       通过一段时间的试运行，基本稳定，没有太大问题，通过监控访问日志和实验，实现了错误转移和负载均衡的基本功能。至此网站负载均衡的实施的重点工作已经完成，后续的优化工作将是持续的。