資訊專欄INFORMATION COLUMN
摘要：本篇博客通過小強開飯店的通俗易懂的故事，帶你了解后端服務是如果從單體應用演變到微服務的。小強開飯店有一天，小強為了早日奔赴小康生活，打算開一個飯店來幫他快速的實現這個目標。于是小強開始給服務盡量的無狀態化，然后在一個服務器上啟動了幾個實例。
本篇博客通過小強開飯店的通俗易懂的故事，帶你了解后端服務是如果從單體應用演變到微服務的。如果有說的不對的地方，歡迎各位大佬強勢懟。
小強開飯店有一天，小強為了早日奔赴小康生活，打算開一個飯店來幫他快速的實現這個目標。
飯店開業了于是他盤下了一個店面，一頓裝修之后，雇了一個廚師，便開業了。
飯店生意變好了剛剛開業那段時間還好，店里的人雖然多，但是都還能應付的過來。
小強請的廚師手藝很好，再加上小強經營得當，宣傳的也不錯，慢慢的店里的生意越來越好。
慢慢的，顧客越來越多。很多時候廚師都忙不過來，大家只有排隊在外面等著。漸漸的有些顧客變得十分不耐煩，等不下去了就走了，然后給了這家店差評。這種情況愈演愈烈，小強看到這不是個辦法啊，得做點什么。
招聘廚師小強下了血本，又另外聘請了幾位廚藝很好的廚師。
有了這些廚師的加盟，雖然客人很多，飯店的經營也還是能夠勉強的應付的來。口碑也慢慢的由差變好。隨著口碑的變好，慕名而來的也隨之越來越多。
生意火爆隨著顧客越來越多，即使廚房的廚師已經招聘滿了，都還是應付不過來。
于是廚師也變成了暴躁的廚師。有的時候因為太忙了還罷工不干了。還得小強去苦口婆心的勸。小強心想這也不是個辦法，再這么下去口碑又得下去。于是小強搖身一變，變成了強老板。
強老板開了分店強老板拿著開飯店賺的錢，在城里的很多地方開了分店，十分的膨脹。這樣一來，客人不用大老遠的跑到那一家店去了，可以選擇離自己近的店。很快，原來的那家生意也漸漸的恢復正常，各個分店的業績也有所提高。
但是隨著強老板的強勢宣傳，以及顧客之間的自傳播，這個參考被越來越多的人知道了。但是由于顧客分散，每家店的火爆程度都不同。有的店甚至陷入了跟最開始的店一樣的境地，大量的顧客排隊。但是有的店的生意卻又十分冷清。
強老板心想，這肯定不行啊，這樣下去早晚得血虧。于是強老板搖身一變，變成了強總。
強總開了個顧客中心所有想去餐館用餐的顧客都來這里，由強老板統一安排的大巴再送至各個分店。每輛車輪流的送至每一家分店。這樣一來，就不存在某一家分店生意十分火爆而另外的店生意慘淡的情況了。
強總已達成奔赴小康的目標 讀后感其實這個想法是很久以前不知道在哪兒看博客的時候，看到一位大佬的類比，確實是忘了。而最近剛好在準備分享，所以就打算詳細的以圖文和故事的方式來讓沒有了解過這方面的人快速的了解一下。
其實我也糾結過要不要將里面類比概念的解釋穿插到故事里，但是后面想了一下，這樣應該會干擾到大家對故事本身的理解，從而達不到通俗易懂的效果。所以我將解釋多帶帶放在了最后面。
單個飯店最開始的單個飯店其實就是一個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）
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/74964.html
摘要：本篇博客主要介紹了自動化工具這個概念，在微服務集群當中的作用，算拋磚引玉，歡迎大家提出自己的見解。而在微服務中，單個服務重新部署的代價明顯要小的多。 本篇博客主要介紹了自動化工具這個概念，在微服務集群當中的作用，算拋磚引玉，歡迎大家提出自己的見解。 寫在前面 在了解自動化工具的概念之前，我們先了解一下微服務和集群的概念。 什么是微服務 這個概念其實有些廣泛，而我的知識廣度也有限，我會盡...
摘要：用來標示該輪冒泡排序中，數組是否是有序的。適用情況當冒泡算法運行到后半段的時候，如果此時數組已經有序了，需要提前結束冒泡排序。當第一輪冒泡排序結束后，元素會被移動到下標的位置。 這篇文章包含了你一定知道的，和你不一定知道的冒泡排序。 gif看不了可以點擊【原文】查看gif。 源碼: 【地址】 1. 什么是冒泡排序 可能對于大多數的人來說比如我，接觸的第一個算法就是冒泡排序。 我看過的很...
摘要：抽象了數據中心的硬件基礎設施，使得對外暴露的只是一個巨大的資源池。圖單體應用中的組件與獨立的微服務每個微服務都是獨立的，可以獨立開發和部署。 簡介 P2Kubernetes 能自動調度、配置、監管和故障處理，使開發者可以自主部署應用，并且控制部署的頻率，完全脫離運維團隊的幫助。 Kubernetes 同時能讓運維團隊監控整...
摘要：相反，它由單體中的適配器和使用一個或多個進程間通信機制的服務組成。因為微服務架構的本質是一組圍繞業務功能組織的松耦合服務。如果你嘗試將此類功能實現為服務，則通常會發現，由于過多的進程間通信而導致性能下降。這是快速展示微服務架構價值的好方法。你很有可能正在處理大型復雜的單體應用程序，每天開發和部署應用程序的經歷都很緩慢而且很痛苦。微服務看起來非常適合你的應用程序，但它也更像是一項遙不可及的必殺...
摘要：然而，悲傷的是，她已不再是國民媳婦了事后，于是網絡上就有人報怨微博的技術能力了，還說同時支持八個，一個明星結婚就頂不住了。關于微博能同時支持八個明星并發出軌，現在都成了一個埂，成就了一個個段子在博主朋友圈刷屏。。 showImg(https://segmentfault.com/img/remote/1460000016709618?w=870&h=601); 是的，大家可能都知道了，...
閱讀 1855·2021-11-25 09:43
閱讀 1497·2021-09-02 15:21
閱讀 3461·2019-08-30 15:52
閱讀 1507·2019-08-30 12:48
閱讀 1304·2019-08-30 10:57
閱讀 2934·2019-08-26 17:41
閱讀 684·2019-08-26 11:59
閱讀 1374·2019-08-26 10:41
