小強(qiáng)開飯店-從單體應(yīng)用到微服務(wù)

shengguo 發(fā)布于2019-08-16 18:07 / 950人閱讀

摘要：本篇博客通過小強(qiáng)開飯店的通俗易懂的故事，帶你了解后端服務(wù)是如果從單體應(yīng)用演變到微服務(wù)的。小強(qiáng)開飯店有一天，小強(qiáng)為了早日奔赴小康生活，打算開一個(gè)飯店來(lái)幫他快速的實(shí)現(xiàn)這個(gè)目標(biāo)。于是小強(qiáng)開始給服務(wù)盡量的無(wú)狀態(tài)化，然后在一個(gè)服務(wù)器上啟動(dòng)了幾個(gè)實(shí)例。

本篇博客通過小強(qiáng)開飯店的通俗易懂的故事，帶你了解后端服務(wù)是如果從單體應(yīng)用演變到微服務(wù)的。如果有說(shuō)的不對(duì)的地方，歡迎各位大佬強(qiáng)勢(shì)懟。

小強(qiáng)開飯店

有一天，小強(qiáng)為了早日奔赴小康生活，打算開一個(gè)飯店來(lái)幫他快速的實(shí)現(xiàn)這個(gè)目標(biāo)。

飯店開業(yè)了

于是他盤下了一個(gè)店面，一頓裝修之后，雇了一個(gè)廚師，便開業(yè)了。

飯店生意變好了

剛剛開業(yè)那段時(shí)間還好，店里的人雖然多，但是都還能應(yīng)付的過來(lái)。

小強(qiáng)請(qǐng)的廚師手藝很好，再加上小強(qiáng)經(jīng)營(yíng)得當(dāng)，宣傳的也不錯(cuò)，慢慢的店里的生意越來(lái)越好。

慢慢的，顧客越來(lái)越多。很多時(shí)候廚師都忙不過來(lái)，大家只有排隊(duì)在外面等著。漸漸的有些顧客變得十分不耐煩，等不下去了就走了，然后給了這家店差評(píng)。這種情況愈演愈烈，小強(qiáng)看到這不是個(gè)辦法啊，得做點(diǎn)什么。

招聘廚師

小強(qiáng)下了血本，又另外聘請(qǐng)了幾位廚藝很好的廚師。

有了這些廚師的加盟，雖然客人很多，飯店的經(jīng)營(yíng)也還是能夠勉強(qiáng)的應(yīng)付的來(lái)。口碑也慢慢的由差變好。隨著口碑的變好，慕名而來(lái)的也隨之越來(lái)越多。

生意火爆

隨著顧客越來(lái)越多，即使廚房的廚師已經(jīng)招聘滿了，都還是應(yīng)付不過來(lái)。

于是廚師也變成了暴躁的廚師。有的時(shí)候因?yàn)樘α诉€罷工不干了。還得小強(qiáng)去苦口婆心的勸。小強(qiáng)心想這也不是個(gè)辦法，再這么下去口碑又得下去。于是小強(qiáng)搖身一變，變成了強(qiáng)老板。

強(qiáng)老板開了分店

強(qiáng)老板拿著開飯店賺的錢，在城里的很多地方開了分店，十分的膨脹。這樣一來(lái)，客人不用大老遠(yuǎn)的跑到那一家店去了，可以選擇離自己近的店。很快，原來(lái)的那家生意也漸漸的恢復(fù)正常，各個(gè)分店的業(yè)績(jī)也有所提高。

但是隨著強(qiáng)老板的強(qiáng)勢(shì)宣傳，以及顧客之間的自傳播，這個(gè)參考被越來(lái)越多的人知道了。但是由于顧客分散，每家店的火爆程度都不同。有的店甚至陷入了跟最開始的店一樣的境地，大量的顧客排隊(duì)。但是有的店的生意卻又十分冷清。

強(qiáng)老板心想，這肯定不行啊，這樣下去早晚得血虧。于是強(qiáng)老板搖身一變，變成了強(qiáng)總。

強(qiáng)總開了個(gè)顧客中心

所有想去餐館用餐的顧客都來(lái)這里，由強(qiáng)老板統(tǒng)一安排的大巴再送至各個(gè)分店。每輛車輪流的送至每一家分店。這樣一來(lái)，就不存在某一家分店生意十分火爆而另外的店生意慘淡的情況了。

強(qiáng)總已達(dá)成奔赴小康的目標(biāo)

讀后感

其實(shí)這個(gè)想法是很久以前不知道在哪兒看博客的時(shí)候，看到一位大佬的類比，確實(shí)是忘了。而最近剛好在準(zhǔn)備分享，所以就打算詳細(xì)的以圖文和故事的方式來(lái)讓沒有了解過這方面的人快速的了解一下。

其實(shí)我也糾結(jié)過要不要將里面類比概念的解釋穿插到故事里，但是后面想了一下，這樣應(yīng)該會(huì)干擾到大家對(duì)故事本身的理解，從而達(dá)不到通俗易懂的效果。所以我將解釋多帶帶放在了最后面。

單個(gè)飯店

最開始的單個(gè)飯店其實(shí)就是一個(gè)App或者一個(gè)網(wǎng)站，來(lái)給用戶提供服務(wù)。可以理解為前端，或者客戶端。

單個(gè)飯店的廚師

而單個(gè)飯店中的廚師，其實(shí)就是后端，提供數(shù)據(jù)，提供服務(wù)。一個(gè)廚師就對(duì)應(yīng)著一個(gè)后端服務(wù)的實(shí)例。

隨著App的訪問量越來(lái)越大，最初的單體應(yīng)用已經(jīng)無(wú)法扛住這么大的壓力了。導(dǎo)致其他的用戶進(jìn)入系統(tǒng)時(shí)，系統(tǒng)無(wú)法正常的服務(wù)。就跟我們現(xiàn)在打開一個(gè)網(wǎng)站一樣，凡是超過2-3秒沒有反應(yīng)就直接宣告它的死刑了，直接退出-卸載二連。

單個(gè)飯店的多個(gè)廚師

多個(gè)廚師則是相應(yīng)的后端服務(wù)啟動(dòng)了多個(gè)實(shí)例，每個(gè)實(shí)例都是完全一樣的，只不過是運(yùn)行在不同的機(jī)器上或者不同的端口上。

每次的請(qǐng)求由這些實(shí)例來(lái)均攤，這樣也的確能夠暫時(shí)解決訪問量大的問題。但是維護(hù)起來(lái)十分的麻煩，部署的流程也很繁瑣。每次部署你得更新所有的實(shí)例，萬(wàn)一數(shù)量多，又在不同的機(jī)器上，很有可能因?yàn)椴僮魇д`引發(fā)線上的事故。而且有可能讓老版本的服務(wù)兼容新版的前端或者客戶端，造成不必要的BUG。

再退一萬(wàn)步，就算所有的實(shí)例都在同一個(gè)服務(wù)器上，萬(wàn)一真的訪問量到了一定的量級(jí)，你得維護(hù)多少個(gè)實(shí)例啊。人工成本巨大。而且一不小心，一覺起來(lái)，本身沒有問題的服務(wù)，因?yàn)橐煌砩习l(fā)生了事件引發(fā)了熱點(diǎn)，導(dǎo)致你的應(yīng)用訪問量劇增，增到超過你的所有實(shí)例能夠承受的極限，服務(wù)掛了。

再退一萬(wàn)萬(wàn)步，就算你自己維護(hù)沒有煩死，前端的兄弟可能早就收拾你了。你沒有做請(qǐng)求分發(fā)的話，所有的服務(wù)器地址得由前端去維護(hù)。

分店

這里的分店指微服務(wù)中的一個(gè)服務(wù)的多個(gè)實(shí)例。與之前人工維護(hù)的多個(gè)實(shí)例不同，這個(gè)是由工具幫我們維護(hù)。

這里我拿Docker Swarm舉個(gè)例子。在Portainer中，你新建了一個(gè)服務(wù)之后可以選擇設(shè)置Replicas，也就是實(shí)例的數(shù)量，當(dāng)然默認(rèn)是一個(gè)。你可以起10個(gè)，20個(gè)，但是這里得考慮到你的服務(wù)是否支持這樣做。如果你的服務(wù)不是無(wú)狀態(tài)應(yīng)用，就很難做到可以自動(dòng)的做橫向擴(kuò)展。

分店的生意火爆

其實(shí)也是一樣的，即使有很多個(gè)實(shí)例，你如果不能控制請(qǐng)求打到哪個(gè)服務(wù)上的話，某些實(shí)例承受的壓力大了一樣的會(huì)掛。

強(qiáng)總的顧客中心

顧客中心大家可以理解為網(wǎng)關(guān)。更具體點(diǎn)可以理解為Zuul。

你的服務(wù)有了網(wǎng)關(guān)之后，所有的請(qǐng)求都從網(wǎng)關(guān)走。根據(jù)以及配置的路由，網(wǎng)關(guān)可以判斷到你想具體到哪個(gè)服務(wù)去。

然后就會(huì)從自己的服務(wù)集群中找到對(duì)應(yīng)的服務(wù)，獲取到所有的服務(wù)實(shí)例的服務(wù)器IP以及端口。前面說(shuō)到有可能請(qǐng)求會(huì)集中到某幾個(gè)實(shí)例上。而我們可以使用工具來(lái)解決這個(gè)問題。例如，使用Spring Cloud的核心組件Ribbon。

這個(gè)組件的作用是做負(fù)載均衡，它可以使所有到某個(gè)服務(wù)的請(qǐng)求，平均的分發(fā)到該服務(wù)的每個(gè)實(shí)例上去。從而避免某幾個(gè)服務(wù)的請(qǐng)求超過其能承受的闕值。當(dāng)然，Ribbon需要和Spring Cloud的其他核心組件相互協(xié)作的。

另外一個(gè)版本的故事

小強(qiáng)搞了個(gè)新聞App，用Spring Boot搭了一個(gè)后端，找人用React Native寫了個(gè)App，就這樣上線了。因?yàn)槠鋬?nèi)容和推廣都還不錯(cuò)，所以受到了用戶的喜愛。

但是隨著訪問量越來(lái)越大，服務(wù)器漸漸扛不住壓力。有的用戶進(jìn)App之后甚至要5-6秒才有反應(yīng)，而且慢的出奇。于是小強(qiáng)開始給服務(wù)盡量的無(wú)狀態(tài)化，然后在一個(gè)服務(wù)器上啟動(dòng)了幾個(gè)實(shí)例。

一段時(shí)間之后，訪問量又增大了。小強(qiáng)只好硬著頭皮，繼續(xù)加實(shí)例數(shù)量，你強(qiáng)任你強(qiáng)，加實(shí)例我在行。

有一天，小強(qiáng)一覺起來(lái)，發(fā)現(xiàn)服務(wù)炸了...啊不是，是掛了。因?yàn)榘l(fā)生了一些事情引發(fā)了巨大的社會(huì)輿論，App的訪問量劇增。導(dǎo)致新加的實(shí)例也沒能扛住。

就這樣，小強(qiáng)老實(shí)的開始了重構(gòu)。使用Spring Cloud搭建了一個(gè)微服務(wù)集群，把服務(wù)拆分之后，給每個(gè)服務(wù)啟動(dòng)了幾個(gè)實(shí)例。同時(shí)使用Eureka和Feign來(lái)進(jìn)行服務(wù)之間的通信，使用Ribbon來(lái)做負(fù)載均衡。

就這樣，這個(gè)App暫時(shí)穩(wěn)定了下來(lái)。不過還有很多事情可以繼續(xù)去做。

參考：
拜托！面試請(qǐng)不要再問我Spring Cloud底層原理
往期文章：

什么？你竟然還沒有用這幾個(gè)chrome插件？
手把手教你從零開始搭建SpringBoot后端項(xiàng)目框架
用go-module作為包管理器搭建go的web服務(wù)器
WebAssembly完全入門——了解wasm的前世今身

相關(guān)：

個(gè)人網(wǎng)站：       Lunhao Hu

微信公眾號(hào)：   SH的全棧筆記（或直接在添加公眾號(hào)界面搜索微信號(hào)LunhaoHu）