一、前言

這是《大話云原生》系列的第二篇，第一篇《煮餃子與docker、kubernetes之間的關(guān)系》推出之后受到大家的歡迎，很多朋友聯(lián)系到我給我加油打氣，還得到了CSDN頭部博主哪吒大佬的支持，感謝！我會繼續(xù)寫下去！

書接上回介紹了《煮餃子與docker、kubernetes之間的關(guān)系》之后，小娜同學(xué)（我老婆）問：為什么不把服務(wù)統(tǒng)一開發(fā)成一個應(yīng)用？搞什么分布式？這樣感覺很龐大，很復(fù)雜??？為什么要這么搞？所以大話云原生第二篇-負載均衡篇，現(xiàn)在開始！

二、從路邊攤說起

周五晚上加了班，下班的時候已經(jīng)很晚了，打電話給小娜打算去吃燒烤，就去我們經(jīng)常去的那家“夫妻攤位”燒烤。到了之后才發(fā)現(xiàn)“夫妻攤位”升級了，現(xiàn)在變成了“夫妻飯館”。由于已經(jīng)比較晚了，店里人并不多，就和老板娘聊了起來。聊聊小飯館的昨天、今天和明天！

老板娘介紹到：“以前路邊攤的時候我倆剛結(jié)婚，手里資金有限，就想著開一個路邊燒烤攤。我老公負責(zé)烤串做菜，我呢、負責(zé)服務(wù)收銀及上菜。掙點小錢！”。老板娘謙虛，等我年紀大了沒準也搞個烤串的營生，誰讓我愛吃呢！老板娘說之所以能走到今天，主要是因為以下幾點：

她的攤位很少會出現(xiàn)長時間的等菜的現(xiàn)象。因為攤位的桌椅板凳的容量通常是有限的，通常也沒那么多客人，食品總的需求量的上限也基本是固定的，相對好協(xié)調(diào)。

溝通順暢、快速，這頭點菜點串吼一嗓子、那邊就開始做上了。做好了再吼一嗓子，就上菜了。

短小精悍、容易掉頭。夫妻倆之所以選擇從路邊攤開始，是因為船小好掉頭。有可能干一陣發(fā)現(xiàn)這個位置客流少，就可以立刻停止經(jīng)營或者換個地方經(jīng)營。

哎，別說，夫妻倆這個階段就有點像一些軟件服務(wù)創(chuàng)業(yè)公司，剛開始創(chuàng)業(yè)的時候，一般做的應(yīng)用服務(wù)都是單體應(yīng)用。筆者也見過一些小型創(chuàng)業(yè)公司上來就想搞微服務(wù)云原生，我覺得這不太現(xiàn)實。企業(yè)的架構(gòu)都是一步一步衍進的，不要總想著一口吃一個胖子。如果京東淘寶從第一天做應(yīng)用服務(wù)的時候就想做成今天的樣子，他們一定活不到今天。就像一個沒開過飯店的人第一次創(chuàng)業(yè)就要開五星級飯店，等待他的十有八九就是失??！

這里我所說的單體應(yīng)用的特點，其實和路邊攤的特點是差不多的：

能夠接納的請求數(shù)量時有限的，一是從需求上沒那么多用戶，二是創(chuàng)業(yè)公司資源限制，服務(wù)器的內(nèi)存、CPU配置是有限的。

單體應(yīng)用的視圖層、控制層、持久層全都在一個應(yīng)用里面，調(diào)用方便、響應(yīng)快速。服務(wù)間沒有遠程調(diào)用RPC，響應(yīng)速度更快一些，具體到某個服務(wù)請求的響應(yīng)結(jié)果更快。

開發(fā)簡單、上手快、三五個人團隊好管好用。老板決定不干了，隨時可以掉頭，基本不太肉疼。

還是要祝賀老板娘啊，生財有道，還會總結(jié)經(jīng)驗！

三、開飯館與負載均衡

前一段時間就已經(jīng)有人愿意為了吃他們夫妻做的燒烤排隊了，這夫妻倆一想，我們這倆人也干不過來啊，怎么辦？招人吧、擴大規(guī)模吧。

招什么人？當然是廚師啊、端菜收銀的妻子自己還能干得過來，主要是丈夫的活挺不住了，對，那就招廚師。

不能讓多出來的客人站著吃吧？租一個附近的門市、添置更多的桌椅板凳。

同樣的道理，軟件應(yīng)用中的單體應(yīng)用服務(wù)扛不住用戶需求了怎么辦，加服務(wù)器啊，多部署幾個服務(wù)啊，負載均衡啊。

說說客戶端負載均衡與服務(wù)端負載均衡

小夫妻兩一口氣為飯館配置了三個廚師（含丈夫），這下可夠用了。妻子將單號訂單給張廚師、雙號訂單給李廚師，兩人都干不過來了，再將訂單給丈夫。反正外人不用白不用，自己家人能歇會就歇會。她說給誰就給誰，她有自己的一套算法。這種模式就是“客戶端負載均衡”，妻子作為客戶端調(diào)用“廚師”服務(wù)，會記得總共有幾個廚師，然后按照自己的算法將用戶請求轉(zhuǎn)發(fā)給其中一個廚師。我們常見的Spring Cloud每個服務(wù)請求其他微服務(wù)的時候，都在其內(nèi)部維護一個微服務(wù)列表，然后根據(jù)請求目標及算法從微服務(wù)中選擇一個服務(wù)進行遠程服務(wù)調(diào)用。

有一天這倆廚師提出意見：這么干太累了沒有閑著時候，要么丈夫多出力，要么漲工資。夫妻倆一合計現(xiàn)在實力也不是很雄厚，還是丈夫多出力吧。那妻子也就沒有必要記住“訂單的單雙號”了，就使用一款app輸入顧客訂單，該app可以實現(xiàn)訂單的均衡分配給廚師。“這種模式就是“服務(wù)端負載均衡””。對于軟件架構(gòu)而言該app就是負載均衡器，常用的軟件負載均衡器有nginx、haproxy等。還有一些硬件的負載均衡器，性能上要更好一些，當然收費也更“好”。架構(gòu)如下圖所示：

利與弊：

“利”就是應(yīng)用的處理能力增加了，能夠處理更多的訂單。

“弊”就是溝通成本增加了，原來吼一嗓子解決的問題，現(xiàn)在需要靠app轉(zhuǎn)發(fā)了（負載均衡器）。無論是遠程服務(wù)調(diào)用，還是請求轉(zhuǎn)發(fā)轉(zhuǎn)發(fā)都是耗時的。

也就是說：飯店(應(yīng)用服務(wù))現(xiàn)在處理請求吞吐量上的能力增強了，但是在單個請求的處理速度上實際上是下降了。實際上這就是服務(wù)拆分的結(jié)果，服務(wù)拆分就是在 “用時間換空間” 。各位細品！

四、飯后溝通

吃完烤串之后，我將上面的一套理論將給了小娜，她很感興趣：“軟件架構(gòu)真是脫離不開實際生活啊，到處都是活生生的例子”。我趁勢吹起了牛逼：“這才哪到哪，下回帶你去個大飯店見見世面，有微服務(wù)的大飯店！”。

以上就是從小飯館客流量變大論云原生負載均衡的詳細內(nèi)容，更多關(guān)于論云原生負載均衡的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論