小強開飯店-從單體應用到微服務

本篇博客經過小強開飯店的通俗易懂的故事，帶你瞭解後端服務是若是從單體應用演變到微服務的。若是有說的不對的地方，歡迎各位大佬強勢懟。

小強開飯店

有一天，小強爲了早日奔赴小康生活，打算開一個飯店來幫他快速的實現這個目標。

飯店開業了

因而他盤下了一個店面，一頓裝修以後，僱了一個廚師，便開業了。

飯店生意變好了

剛剛開業那段時間還好，店裏的人雖然多，可是都還能應付的過來。

小強請的廚師手藝很好，再加上小強經營得當，宣傳的也不錯，慢慢的店裏的生意愈來愈好。

慢慢的，顧客愈來愈多。不少時候廚師都忙不過來，你們只有排隊在外面等着。漸漸的有些顧客變得十分不耐煩，等不下去了就走了，而後給了這家店差評。這種狀況愈演愈烈，小強看到這不是個辦法啊，得作點什麼。

招聘廚師

小強下了血本，又另外聘請了幾位廚藝很好的廚師。

有了這些廚師的加盟，雖然客人不少，飯店的經營也仍是可以勉強的應付的來。口碑也慢慢的由差變好。隨着口碑的變好，慕名而來的也隨之愈來愈多。

生意火爆

隨着顧客愈來愈多，即便廚房的廚師已經招聘滿了，都仍是應付不過來。

因而廚師也變成了暴躁的廚師。有的時候由於太忙了還罷工不幹了。還得小強去苦口婆心的勸。小強心想這也不是個辦法，再這麼下去口碑又得下去。因而小強搖身一變，變成了強老闆。

強老闆開了分店

強老闆拿着開飯店賺的錢，在城裏的不少地方開了分店，十分的膨脹。這樣一來，客人不用大老遠的跑到那一家店去了，能夠選擇離本身近的店。很快，原來的那家生意也漸漸的恢復正常，各個分店的業績也有所提升。

可是隨着強老闆的強勢宣傳，以及顧客之間的自傳播，這個參考被愈來愈多的人知道了。可是因爲顧客分散，每家店的火爆程度都不一樣。有的店甚至陷入了跟最開始的店同樣的境地，大量的顧客排隊。可是有的店的生意卻又十分冷清。

強老闆心想，這確定不行啊，這樣下去遲早得血虧。因而強老闆搖身一變，變成了強總。

強總開了個顧客中心

全部想去餐館用餐的顧客都來這裏，由強老闆統一安排的大巴再送至各個分店。每輛車輪流的送至每一家分店。這樣一來，就不存在某一家分店生意十分火爆而另外的店生意慘淡的狀況了。

強總已達成奔赴小康的目標

讀後感

其實這個想法是好久之前不知道在哪兒看博客的時候，看到一位大佬的類比，確實是忘了。而最近恰好在準備分享，因此就打算詳細的以圖文和故事的方式來讓沒有了解過這方面的人快速的瞭解一下。

其實我也糾結過要不要將裏面類比概念的解釋穿插到故事裏，可是後面想了一下，這樣應該會干擾到你們對故事自己的理解，從而達不到通俗易懂的效果。因此我將解釋單獨放在了最後面。

單個飯店

最開始的單個飯店其實就是一個App或者一個網站，來給用戶提供服務。能夠理解爲前端，或者客戶端。

單個飯店的廚師

而單個飯店中的廚師，其實就是後端，提供數據，提供服務。一個廚師就對應着一個後端服務的實例。

隨着App的訪問量愈來愈大，最初的單體應用已經沒法扛住這麼大的壓力了。致使其餘的用戶進入系統時，系統沒法正常的服務。就跟咱們如今打開一個網站同樣，凡是超過2-3秒沒有反應就直接宣告它的死刑了，直接退出-卸載二連。

單個飯店的多個廚師

多個廚師則是相應的後端服務啓動了多個實例，每一個實例都是徹底同樣的，只不過是運行在不一樣的機器上或者不一樣的端口上。

每次的請求由這些實例來均攤，這樣也的確可以暫時解決訪問量大的問題。可是維護起來十分的麻煩，部署的流程也很繁瑣。每次部署你得更新全部的實例，萬一數量多，又在不一樣的機器上，頗有可能由於操做失誤引起線上的事故。並且有可能讓老版本的服務兼容新版的前端或者客戶端，形成沒必要要的BUG。

再退一萬步，就算全部的實例都在同一個服務器上，萬一真的訪問量到了必定的量級，你得維護多少個實例啊。人工成本巨大。並且一不當心，一覺起來，自己沒有問題的服務，由於一夜發生了事件引起了熱點，致使你的應用訪問量劇增，增到超過你的全部實例可以承受的極限，服務掛了。

再退一萬萬步，就算你本身維護沒有煩死，前端的兄弟可能早就收拾你了。你沒有作請求分發的話，全部的服務器地址得由前端去維護。

分店

這裏的分店指微服務中的一個服務的多個實例。與以前人工維護的多個實例不一樣，這個是由工具幫咱們維護。

這裏我拿Docker Swarm舉個例子。在Portainer中，你新建了一個服務以後能夠選擇設置Replicas，也就是實例的數量，固然默認是一個。你能夠起10個，20個，可是這裏得考慮到你的服務是否支持這樣作。若是你的服務不是無狀態應用，就很難作到能夠自動的作橫向擴展。

分店的生意火爆

其實也是同樣的，即便有不少個實例，你若是不能控制請求打到哪一個服務上的話，某些實例承受的壓力大了同樣的會掛。

強總的顧客中心

顧客中心你們能夠理解爲網關。更具體點能夠理解爲Zuul。

你的服務有了網關以後，全部的請求都從網關走。根據以及配置的路由，網關能夠判斷到你想具體到哪一個服務去。

而後就會從本身的服務集羣中找到對應的服務，獲取到全部的服務實例的服務器IP以及端口。前面說到有可能請求會集中到某幾個實例上。而咱們可使用工具來解決這個問題。例如，使用Spring Cloud的核心組件Ribbon。

這個組件的做用是作負載均衡，它可使全部到某個服務的請求，平均的分發到該服務的每一個實例上去。從而避免某幾個服務的請求超過其能承受的闕值。固然，Ribbon須要和Spring Cloud的其餘核心組件相互協做的。

另一個版本的故事

小強搞了個新聞App，用Spring Boot搭了一個後端，找人用React Native寫了個App，就這樣上線了。由於其內容和推廣都還不錯，因此受到了用戶的喜好。

可是隨着訪問量愈來愈大，服務器漸漸扛不住壓力。有的用戶進App以後甚至要5-6秒纔有反應，並且慢的出奇。因而小強開始給服務儘可能的無狀態化，而後在一個服務器上啓動了幾個實例。

一段時間以後，訪問量又增大了。小強只好硬着頭皮，繼續加實例數量，你強任你強，加實例我在行。

有一天，小強一覺起來，發現服務炸了...啊不是，是掛了。由於發生了一些事情引起了巨大的社會輿論，App的訪問量劇增。致使新加的實例也沒能扛住。

就這樣，小強老實的開始了重構。使用Spring Cloud搭建了一個微服務集羣，把服務拆分以後，給每一個服務啓動了幾個實例。同時使用Eureka和Feign來進行服務之間的通訊，使用Ribbon來作負載均衡。

就這樣，這個App暫時穩定了下來。不過還有不少事情能夠繼續去作。

參考：

• 拜託！面試請不要再問我Spring Cloud底層原理

往期文章：

• 什麼？你居然尚未用這幾個chrome插件？
• 手把手教你從零開始搭建SpringBoot後端項目框架
• 用go-module做爲包管理器搭建go的web服務器
• WebAssembly徹底入門——瞭解wasm的前世今身

相關：

• 我的網站： Lunhao Hu
• 微信公衆號： SH的全棧筆記（或直接在添加公衆號界面搜索微信號LunhaoHu）