從小飯館客流量變大論云原生負(fù)載均衡
一、前言
這是《大話云原生》系列的第二篇,第一篇《煮餃子與docker、kubernetes之間的關(guān)系》推出之后受到大家的歡迎,很多朋友聯(lián)系到我給我加油打氣,還得到了CSDN頭部博主哪吒大佬的支持,感謝!我會繼續(xù)寫下去!
書接上回介紹了《煮餃子與docker、kubernetes之間的關(guān)系》之后,小娜同學(xué)(我老婆)問:為什么不把服務(wù)統(tǒng)一開發(fā)成一個應(yīng)用?搞什么分布式?這樣感覺很龐大,很復(fù)雜???為什么要這么搞?所以大話云原生第二篇-負(fù)載均衡篇,現(xiàn)在開始!
二、從路邊攤說起
周五晚上加了班,下班的時候已經(jīng)很晚了,打電話給小娜打算去吃燒烤,就去我們經(jīng)常去的那家“夫妻攤位”燒烤。到了之后才發(fā)現(xiàn)“夫妻攤位”升級了,現(xiàn)在變成了“夫妻飯館”。由于已經(jīng)比較晚了,店里人并不多,就和老板娘聊了起來。聊聊小飯館的昨天、今天和明天!
老板娘介紹到:“以前路邊攤的時候我倆剛結(jié)婚,手里資金有限,就想著開一個路邊燒烤攤。我老公負(fù)責(zé)烤串做菜,我呢、負(fù)責(zé)服務(wù)收銀及上菜。掙點(diǎn)小錢!”。老板娘謙虛,等我年紀(jì)大了沒準(zhǔn)也搞個烤串的營生,誰讓我愛吃呢!老板娘說之所以能走到今天,主要是因?yàn)橐韵聨c(diǎn):
她的攤位很少會出現(xiàn)長時間的等菜的現(xiàn)象。因?yàn)閿偽坏淖酪伟宓实娜萘客ǔJ怯邢薜?,通常也沒那么多客人,食品總的需求量的上限也基本是固定的,相對好協(xié)調(diào)。
溝通順暢、快速,這頭點(diǎn)菜點(diǎn)串吼一嗓子、那邊就開始做上了。做好了再吼一嗓子,就上菜了。
短小精悍、容易掉頭。夫妻倆之所以選擇從路邊攤開始,是因?yàn)榇『玫纛^。有可能干一陣發(fā)現(xiàn)這個位置客流少,就可以立刻停止經(jīng)營或者換個地方經(jīng)營。
哎,別說,夫妻倆這個階段就有點(diǎn)像一些軟件服務(wù)創(chuàng)業(yè)公司,剛開始創(chuàng)業(yè)的時候,一般做的應(yīng)用服務(wù)都是單體應(yīng)用。筆者也見過一些小型創(chuàng)業(yè)公司上來就想搞微服務(wù)云原生,我覺得這不太現(xiàn)實(shí)。企業(yè)的架構(gòu)都是一步一步衍進(jìn)的,不要總想著一口吃一個胖子。如果京東淘寶從第一天做應(yīng)用服務(wù)的時候就想做成今天的樣子,他們一定活不到今天。就像一個沒開過飯店的人第一次創(chuàng)業(yè)就要開五星級飯店,等待他的十有八九就是失敗!
這里我所說的單體應(yīng)用的特點(diǎn),其實(shí)和路邊攤的特點(diǎn)是差不多的:
能夠接納的請求數(shù)量時有限的,一是從需求上沒那么多用戶,二是創(chuàng)業(yè)公司資源限制,服務(wù)器的內(nèi)存、CPU配置是有限的。
單體應(yīng)用的視圖層、控制層、持久層全都在一個應(yīng)用里面,調(diào)用方便、響應(yīng)快速。服務(wù)間沒有遠(yuǎn)程調(diào)用RPC,響應(yīng)速度更快一些,具體到某個服務(wù)請求的響應(yīng)結(jié)果更快。
開發(fā)簡單、上手快、三五個人團(tuán)隊(duì)好管好用。老板決定不干了,隨時可以掉頭,基本不太肉疼。
還是要祝賀老板娘啊,生財(cái)有道,還會總結(jié)經(jīng)驗(yàn)!
三、開飯館與負(fù)載均衡
前一段時間就已經(jīng)有人愿意為了吃他們夫妻做的燒烤排隊(duì)了,這夫妻倆一想,我們這倆人也干不過來啊,怎么辦?招人吧、擴(kuò)大規(guī)模吧。
招什么人?當(dāng)然是廚師啊、端菜收銀的妻子自己還能干得過來,主要是丈夫的活挺不住了,對,那就招廚師。
不能讓多出來的客人站著吃吧?租一個附近的門市、添置更多的桌椅板凳。
同樣的道理,軟件應(yīng)用中的單體應(yīng)用服務(wù)扛不住用戶需求了怎么辦,加服務(wù)器啊,多部署幾個服務(wù)啊,負(fù)載均衡啊。
說說客戶端負(fù)載均衡與服務(wù)端負(fù)載均衡
小夫妻兩一口氣為飯館配置了三個廚師(含丈夫),這下可夠用了。妻子將單號訂單給張廚師、雙號訂單給李廚師,兩人都干不過來了,再將訂單給丈夫。反正外人不用白不用,自己家人能歇會就歇會。她說給誰就給誰,她有自己的一套算法。這種模式就是“客戶端負(fù)載均衡”,妻子作為客戶端調(diào)用“廚師”服務(wù),會記得總共有幾個廚師,然后按照自己的算法將用戶請求轉(zhuǎn)發(fā)給其中一個廚師。我們常見的Spring Cloud每個服務(wù)請求其他微服務(wù)的時候,都在其內(nèi)部維護(hù)一個微服務(wù)列表,然后根據(jù)請求目標(biāo)及算法從微服務(wù)中選擇一個服務(wù)進(jìn)行遠(yuǎn)程服務(wù)調(diào)用。
有一天這倆廚師提出意見:這么干太累了沒有閑著時候,要么丈夫多出力,要么漲工資。夫妻倆一合計(jì)現(xiàn)在實(shí)力也不是很雄厚,還是丈夫多出力吧。那妻子也就沒有必要記住“訂單的單雙號”了,就使用一款app輸入顧客訂單,該app可以實(shí)現(xiàn)訂單的均衡分配給廚師。“這種模式就是“服務(wù)端負(fù)載均衡””。對于軟件架構(gòu)而言該app就是負(fù)載均衡器,常用的軟件負(fù)載均衡器有nginx、haproxy等。還有一些硬件的負(fù)載均衡器,性能上要更好一些,當(dāng)然收費(fèi)也更“好”。架構(gòu)如下圖所示:
利與弊:
“利”就是應(yīng)用的處理能力增加了,能夠處理更多的訂單。
“弊”就是溝通成本增加了,原來吼一嗓子解決的問題,現(xiàn)在需要靠app轉(zhuǎn)發(fā)了(負(fù)載均衡器)。無論是遠(yuǎn)程服務(wù)調(diào)用,還是請求轉(zhuǎn)發(fā)轉(zhuǎn)發(fā)都是耗時的。
也就是說:飯店(應(yīng)用服務(wù))現(xiàn)在處理請求吞吐量上的能力增強(qiáng)了,但是在單個請求的處理速度上實(shí)際上是下降了。實(shí)際上這就是服務(wù)拆分的結(jié)果,服務(wù)拆分就是在 “用時間換空間” 。各位細(xì)品!
四、飯后溝通
吃完烤串之后,我將上面的一套理論將給了小娜,她很感興趣:“軟件架構(gòu)真是脫離不開實(shí)際生活啊,到處都是活生生的例子”。我趁勢吹起了牛逼:“這才哪到哪,下回帶你去個大飯店見見世面,有微服務(wù)的大飯店!”。
以上就是從小飯館客流量變大論云原生負(fù)載均衡的詳細(xì)內(nèi)容,更多關(guān)于論云原生負(fù)載均衡的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Rainbond云原生部署開源社區(qū)Discourse的配置過程
這篇文章主要為大家介紹了Rainbond云原生部署開源社區(qū)Discourse配置過程,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-04-04k8s?pod和service網(wǎng)絡(luò)暴露詳解
這篇文章主要介紹了借助iptables的路由轉(zhuǎn)發(fā)功能,打通k8s集群內(nèi)的pod和service網(wǎng)絡(luò),與外部網(wǎng)絡(luò)聯(lián)通,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2023-11-11關(guān)于k8s?使用?Service?控制器對外暴露服務(wù)的問題
這篇文章主要介紹了k8s使用Service控制器對外暴露服務(wù),包括部署deploy,部署?service及查看?service?和?pod?的關(guān)系,本文給大家介紹的非常詳細(xì),需要的朋友可以參考下2022-03-03Kubekey安裝Kubernetes-1.24.8的詳細(xì)過程
這篇文章主要介紹了Kubekey安裝Kubernetes-1.24.8的詳細(xì)過程,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價值,需要的朋友可以參考下2023-05-05Kubernetes有狀態(tài)應(yīng)用管理StatefulSet使用詳解
這篇文章主要為大家介紹了Kubernetes有狀態(tài)應(yīng)用管理StatefulSet使用詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進(jìn)步,早日升職加薪2022-11-11K8S內(nèi)部pod之間相互調(diào)用案例以及詳解
這篇文章主要給大家介紹了關(guān)于K8S內(nèi)部pod之間相互調(diào)用案例的相關(guān)資料,Pod是Kubernetes中最小的可部署單元,它是一個或多個容器的集合,它們共享網(wǎng)絡(luò)和存儲資源,并在同一節(jié)點(diǎn)上運(yùn)行,需要的朋友可以參考下2023-08-08