一、前言 這是《大話雲原生》系列的第二篇，第一篇《煮餃子與docker、kubernetes之間的關係》推出之後受到大家的歡迎，很多朋友聯繫到我給我加油打氣，感謝！我會繼續寫下去！ 書接上回介紹了《煮餃子與docker、kubernetes之間的關係》之後，小娜同學（我老婆）問：為什麼不把服務統一開 ...
一、前言
這是《大話雲原生》系列的第二篇，第一篇《煮餃子與docker、kubernetes之間的關係》推出之後受到大家的歡迎，很多朋友聯繫到我給我加油打氣，感謝！我會繼續寫下去！
書接上回介紹了《煮餃子與docker、kubernetes之間的關係》之後，小娜同學（我老婆）問：為什麼不把服務統一開發成一個應用？搞什麼分散式？這樣感覺很龐大，很複雜啊？為什麼要這麼搞？所以大話雲原生第二篇-負載均衡篇，現在開始！
二、從路邊攤說起
周五晚上加了班，下班的時候已經很晚了，打電話給小娜打算去吃燒烤，就去我們經常去的那家“夫妻攤位”燒烤。到了之後才發現“夫妻攤位”升級了，現在變成了“夫妻飯館”。由於已經比較晚了，店裡人並不多，就和老闆娘聊了起來。聊聊小飯館的昨天、今天和明天！
老闆娘介紹到：“以前路邊攤的時候我倆剛結婚，手裡資金有限，就想著開一個路邊燒烤攤。我老公負責烤串做菜，我呢、負責服務收銀及上菜。掙點小錢！”。老闆娘謙虛，等我年紀大了沒準也搞個烤串的營生，誰讓我愛吃呢！老闆娘說之所以能走到今天，主要是因為以下幾點：
- 她的攤位很少會出現長時間的等菜的現象。因為攤位的桌椅板凳的容量通常是有限的，通常也沒那麼多客人，食品總的需求量的上限也基本是固定的，相對好協調。
- 溝通順暢、快速，這頭點菜點串吼一嗓子、那邊就開始做上了。做好了再吼一嗓子，就上菜了。
- 短小精悍、容易掉頭。夫妻倆之所以選擇從路邊攤開始，是因為船小好掉頭。有可能幹一陣發現這個位置客流少，就可以立刻停止經營或者換個地方經營。
哎，別說，夫妻倆這個階段就有點像一些軟體服務創業公司，剛開始創業的時候，一般做的應用服務都是單體應用。筆者也見過一些小型創業公司上來就想搞微服務雲原生，我覺得這不太現實。企業的架構都是一步一步衍進的，不要總想著一口吃一個胖子。如果京東淘寶從第一天做應用服務的時候就想做成今天的樣子，他們一定活不到今天。就像一個沒開過飯店的人第一次創業就要開五星級飯店，等待他的十有八九就是失敗！
這裡我所說的單體應用的特點，其實和路邊攤的特點是差不多的：
- 能夠接納的請求數量時有限的，一是從需求上沒那麼多用戶，二是創業公司資源限制，伺服器的記憶體、CPU配置是有限的。
- 單體應用的視圖層、控制層、持久層全都在一個應用裡面，調用方便、響應快速。服務間沒有遠程調用RPC，響應速度更快一些，具體到某個服務請求的響應結果更快。
- 開發簡單、上手快、三五個人團隊好管好用。老闆決定不幹了，隨時可以掉頭，基本不太肉疼。
還是要祝賀老闆娘啊，生財有道，還會總結經驗！
三、開飯館與負載均衡
前一段時間就已經有人願意為了吃他們夫妻做的燒烤排隊了，這夫妻倆一想，我們這倆人也乾不過來啊，怎麼辦？招人吧、擴大規模吧。
- 招什麼人？當然是廚師啊、端菜收銀的妻子自己還能幹得過來，主要是丈夫的活挺不住了，對，那就招廚師。
- 不能讓多出來的客人站著吃吧？租一個附近的門市、添置更多的桌椅板凳。
同樣的道理，軟體應用中的單體應用服務扛不住用戶需求了怎麼辦，加伺服器啊，多部署幾個服務啊，負載均衡啊。
說說客戶端負載均衡與服務端負載均衡
- 小夫妻兩一口氣為飯館配置了三個廚師（含丈夫），這下可夠用了。妻子將單號訂單給張廚師、雙號訂單給李廚師，兩人都乾不過來了，再將訂單給丈夫。反正外人不用白不用，自己家人能歇會就歇會。她說給誰就給誰，她有自己的一套演算法。這種模式就是“客戶端負載均衡”，妻子作為客戶端調用“廚師”服務，會記得總共有幾個廚師，然後按照自己的演算法將用戶請求轉發給其中一個廚師。我們常見的Spring Cloud每個服務請求其他微服務的時候，都在其內部維護一個微服務列表，然後根據請求目標及演算法從微服務中選擇一個服務進行遠程服務調用。
- 有一天這倆廚師提出意見：這麼乾太累了沒有閑著時候，要麼丈夫多出力，要麼漲工資。夫妻倆一合計現在實力也不是很雄厚，還是丈夫多出力吧。那妻子也就沒有必要記住“訂單的單雙號”了，就使用一款app輸入顧客訂單，該app可以實現訂單的均衡分配給廚師。“這種模式就是“服務端負載均衡””。對於軟體架構而言該app就是負載均衡器，常用的軟體負載均衡器有nginx、haproxy等。還有一些硬體的負載均衡器，性能上要更好一些，當然收費也更“好”。架構如下圖所示：
利與弊：
- “利”就是應用的處理能力增加了，能夠處理更多的訂單。
- “弊”就是溝通成本增加了，原來吼一嗓子解決的問題，現在需要靠app轉發了（負載均衡器）。無論是遠程服務調用，還是請求轉發轉發都是耗時的。
也就是說：飯店(應用服務)現在處理請求吞吐量上的能力增強了，但是在單個請求的處理速度上實際上是下降了。實際上這就是服務拆分的結果，服務拆分就是在 “用時間換空間” 。各位細品！
四、飯後溝通
吃完烤串之後，我將上面的一套理論將給了小娜，她很感興趣：“軟體架構真是脫離不開實際生活啊，到處都是活生生的例子”。我趁勢吹起了牛逼：“這才哪到哪，下回帶你去個大飯店見見世面，有微服務的大飯店！”。
歡迎關註我的博客，更多精品知識合集
本文轉載註明出處（必須帶連接，不能只轉文字）：字母哥博客 - zimug.com
覺得對您有幫助的話，幫我點贊、分享！您的支持是我不竭的創作動力！。另外，筆者最近一段時間輸出瞭如下的精品內容，期待您的關註。
- 《kafka修煉之道》
- 《手摸手教你學Spring Boot2.0》
- 《Spring Security-JWT-OAuth2一本通》
- 《實戰前後端分離RBAC許可權管理系統》
- 《實戰SpringCloud微服務從青銅到王者》
