从小故事来谈nginx负载均衡

负载均衡

 

负载均衡是任何一个有必定规模的互联网企业都会考虑的问题，负载方式不少，有依靠硬件实现的，也有依靠软件实现负载的。

 

今天来聊聊使用软件来负载的方式

 

你可能听过各自负载的方式，好比常见的nginx,dubbo,springcloud等等技术框架都能实现负载，做为软件大牛的你有没有考虑过这些负载方式的区别呢？

 

下面小源就来假象个案例来谈谈经常使用的负载，我想对你必定会有帮助。

 

【如下故事纯属虚构，请勿对号入座】

 

从一个tomcat谈起

 

在好久好久之前，小源成立了本身的公司，并作了一个购物网站-《小源购物网》，刚开始架构很是简单，传统的java开发框架，一个tomcat容器，通过1个月的没日没夜的编码，搞定，上线。

 

1年后，项目没想到火了，天天都有大量的人来购买娃娃、飞机、杯子。忽然发现一个tomcat搞不定，怎么办？两个tomcat呗！

 

那么问题来了，两个tomcat没问题，服务器也整几台，可是我域名只有一个啊，怎么办？

  

Nginx登场

  Nginx登场，经过一棒子程序猿的倒腾，在项目中引入nginx就能解决并发问题了，其中的研究过程也并不简单，session怎么共享，配置文件怎么配置等等，说多了都是泪，无论怎么说，起码完成了任务，能让2个tomcat联合起来工做了。

 

 然而在线商城愈来愈火，没过2个月，发现2个tomcat也搞不定了，怎么办？只能集成更多tomcat了，固然Nginx集成不少tomcat都没问题，架构图以下

 

 

可是……

 

增长tomcat小源得修改nginx.conf这配置文件,修改了配置问题我固然能够reload，让nginx生效，但reload狗血的常常有问题，而我又不得不常常重启。。

 

重启就麻烦大了，我那服务不得中止，客户好好的在购物，忽然发现不能下单，不能付款了，这不很是糟糕？

 

其实也还好，虽然客户友好度很差，但小源通常凌晨3点加班来维护，幸苦是辛苦，但勉强能接受。

 

直到有一天……

 

 

噩梦的一天

  那天小源正在午睡，3伏天，太阳高晒着，在睡梦中砰的一声，电是没停，但是那台nginx服务器已经在冒烟了。。

 

 怎么办？那一天nginx的服务器确定是报销了，没过多久客户的投诉电话就没完没了的打了过来，而这只是刚过去10分钟……

 

 只能从新搭建个服务器了，好在服务器还有，只是配置文件什么了都忘记备份了，火急火燎的我足足花了1个小时才把服务器弄好，仍是nginx配置文件很是熟练的状况下。

 

问题虽然解决了，但当天小源依然被投资经理一顿臭骂，一个小时损失了不少钱啊，并且客户的投诉还堆积如山。

 

之后再发生这状况怎么办？我确定记得把配置文件进行备份了，但再发生nginx死机也是不能接受的啊。

 

终于……

 

Nginx+keepalived上线

一个nginx机群确定是不行了，那我得用两个nginx机群才行，一个nginx冒烟了，另外个nignx立刻等顶替，这样不就行了吗？

 

好了，那么整体的架构图以下。

 

 

 

终于，这样的架构解决了很大的问题。

 

可是这架构也有问题，至于到底有什么问题呢？

 

Dubbo,spring cloud,zookeeper到底和负载有什么关系呢？

 

请听下回分解^!^