從小故事來談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到底和負載有什麼關係呢？

 

請聽下回分解^!^