
微服務近些年可謂是發展的如火如荼,和別人談技術不聊點“微服務”,會讓自己感覺很落伍。很多人聊微服務,但真的把微服務聊的通俗、聊的通透的人并不多。
我想以一種非常通俗的方式和大家解釋一下微服務,就是以“夫妻攤位”到“五星飯店”發展的角度為例,為大家說明一下微服務及微服務所解決的問題,帶來的挑戰。
## 第一階段:夫妻攤位
小夫妻倆剛結婚,手里資金有限,就想著開一個路邊燒烤攤。丈夫負責烤串做菜、妻子負責服務收銀及上菜。這是一個典型的路邊燒烤攤的經營模式。大家仔細看這種經營模式的好處在于:
* 因為攤位的桌椅板凳的容量通常是有限的,所以食品總的需求量的上限也基本是固定的。 這種攤位很少會出現長時間的等菜的現象。
* 溝通順暢、快速,這頭點菜點串吼一嗓子、那邊就開始做上了。做好了再吼一嗓子,就上菜了。
* 短小精悍、容易掉頭。夫妻兩有可能干一陣發現這個位置客流少或者只賺辛苦不賺錢,就可以立刻停止經營、換個地方經營或者找別的營生。
這個階段就有點像一些創業公司,剛開始創業的時候,一般做的應用都是單體應用。筆者也見過一些創業公司,上來就想搞微服務,我覺得這是不太現實。企業的架構都是一步一步衍進的,不要總想著一口吃一個胖子。如果京東淘寶從第一天做應用的時候就想做成今天的樣子,他們一定活不到今天。就像一個沒開過飯店的人第一次創業就要開五星級飯店,等待他的十有八九就是失敗!
那么單體應用的特點有哪些:
* 能夠接納的請求數量時有限的,因為服務器的內存、CPU配置是有限的。
* 展現層、控制層、持久層全都在一個應用里面,調用方便、快速。單個請求的響應結果超快。
* 開發簡單、上手快、三五個人團隊好管好用。老板決定不干了,隨時可以掉頭,基本不太肉疼。

## 第二階段:門面飯館
但是,隨著小夫妻倆經營有方、待客有道,開始有人愿意為了吃他們做的燒烤排隊了。夫妻倆一想,我們這倆人也干不過來啊,怎么辦?招人吧、擴大規模吧。
* 招什么人?當然是廚師啊、端菜收銀的妻子自己還能干得過來,主要是丈夫的活挺不住了。那就招廚師。
* 不能讓人站著吃吧?租一個附近的門市、添置更多的桌椅板凳。
**客戶端負載均衡與服務端負載均衡是什么?**
* 小夫妻兩一口氣為飯館配置了三個廚師(含丈夫),這下可夠用了。妻子將單號訂單給張廚師、雙號訂單給李廚師,兩人都干不過來了,再將訂單給丈夫。反正外人不用白不用,自己家人能歇會就歇會。**這種模式就是“客戶端負載均衡”**,所有的訂單全都記在“妻子”的腦袋里,她說給誰就給誰。
* 有一天這倆廚師提出意見:太累了,要么丈夫多出力,要么漲工資。夫妻倆一合計,還是丈夫多出力吧。那妻子也就沒有必要記住“訂單的單雙號”了,所以就使用一款app,妻子輸入顧客訂單,該app可以實現訂單的均衡分配給廚師。**“這種模式就是“服務端負載均衡””**,該app就是負載均衡器,常用的軟件負載均衡器有nginx、haproxy等。還有一些硬件的負載均衡器,性能上要更好一些,當然收費也更“好”。

**利與弊**
* “利”就是應用的處理能力增加了,能夠處理更多的訂單。
* “弊”就是溝通成本增加了,原來吼一嗓子解決的問題,現在需要app轉發了(負載均衡器)
也就是說:飯店(應用)現在在處理并發請求的能力和容量上增強了,但是在單個請求的處理速度上下降了。實際上,這就是服務拆分,服務拆分就是在 **“用時間換空間”** 。你細品!
## 第三階段:核心分工精細化
為了解決上一階段遇到的問題:單個請求的處理速度下降。也就是飯店針對單個訂單做菜響應速度下降了,但是由于飯店的菜確實好吃、菜品精良,客流量又持續的增高。該店又再次面臨擴容的問題。
* 為了解決客流量持續增高,夫妻又招聘了4位廚師
* 為了解決單個訂單處理速度下降的問題,將廚師分為兩組,一組專門做燒烤,一組專門做飯菜。專業的人做專業的事情,注意力越集中,辦事越熟練、效率越高。
新的問題又出現了,有的顧客既點燒烤又點飯菜。導致后端兩組廚師之間溝通不暢,怎么組合套餐推送給前臺?廚師之間怎么調用、怎么溝通啊?誰是頭?誰是大腦?誰記得A廚師的燒烤和B廚師的飯菜是一桌的?

丈夫一看這種情況,我也別再做廚師了,那做什么?做菜品的配置管理、做訂單的服務注冊。丈夫負責主動觀察問詢各工種的工作狀態并記錄,妻子主動向丈夫問詢后端廚師的狀態,并根據丈夫的反饋分配訂單(客戶端負載均衡)。丈夫的新工作實際上就產生了微服務非常重要的組件:服務注冊中心和配置管理中心。比如:Spring Cloud Alibaba nacos、eureka、consul、zookeeper、Spring cloud config等
## 第四階段:配套管理專業化

* 需要有統一的門面了:前臺。所有的顧客進來,由前臺統一接待。比如:Spring Cloud Gateway和zuul。
* 需要有安保人員了:檔次高了、進入飯店有預約。最起碼得尊重用餐禮儀,不能是背心褲衩大跨欄,否則就不讓你進。比如:OAuth2 認證服務器和資源服務器。
* 菜品限量提供了:法式菜品、意大利菜品、日本料理。什么時間可以吃得到、可提供多少人份?這些服務都是有限制的。比如:Hytrix熔斷限流。
* 工作效率監督:工作流程中每個崗位做了什么工作、用了多長時間。哪個環節出現問題、哪個崗位需要調整。比如: Sleuth、Zipkin、日志監控ELK等。
## 第五階段:容器化、自動化
飯店的規模越來越大了、崗位分工也越來越細了。真的成了超級大飯店了,怎么管?這就需要專業的機器人服務租用公司,這種公司專門出租各種行業專用機器人。
* 服務員統一包裝:用自動點餐機、機器人。身高必須一米65,微笑必須漏出四顆牙。
* 物料統一包裝:也不用人了,流水作業,一盤菜幾塊肉、什么料全都自動化配置好。廚師就負責炒熟就行了(拜托,這例子理解就好,不要抬杠)
總之全都自動化。這時公司內部的devops團隊就出現了,制定規范、集體包裝、流程自動化。突然有一天,飯店承接了大型運動會大型展覽,怎么辦?要去招服務員么?招員工培訓么?不要,租機器人就行了,用完了就還回去。每年的雙十一、淘寶京東也都是用容器自動化擴容的方式應對暴漲的服務需求。容器化最大的好處就是:輕量級的發布于與銷毀、自動化的擴容。
* 這里的機器人公司,我們可以認為是kubernetes、mesos、swarm
* 這里的機器人,我們可以認為是docker、containerd等
- 文檔內容簡介(一定要看)
- 筆者的其他作品推薦
- vue深入淺出系列
- 手摸手教你學SpringBoot2.0
- Spring Security-JWT-OAuth2一本通
- 實戰前后端分離RBAC權限管理系統
- 模塊與代碼分支說明
- dongbb-cloud項目核心架構
- 微服務架構進化論
- SpringBoot與Cloud選型兼容
- Spring Cloud組件的選型
- 單體應用拆分微服務
- 單體應用與微服務對比
- 微服務設計拆分原則
- 新建父工程及子模塊框架
- 通用微服務初始化模塊構建
- 持久層模塊單獨拆分
- 拆分rbac權限管理微服務
- Hello-microservice
- 構建eureka服務注冊中心
- 向服務注冊中心注冊服務
- 第一個微服務調用
- 遠程服務調用
- HttpClient遠程服務調用
- RestTemplate遠程服務調用
- RestTemplate多實例負載均衡
- Ribbon調用流程源碼解析
- Ribbon負載均衡策略源碼解析
- Ribbon重試機制與饑餓加載
- Ribbon自定義負載均衡策略
- Feign與OpenFeign
- Feign設計原理源碼解析
- Feign請求壓縮與超時等配置
- 服務注冊與發現
- 白話服務注冊與發現
- DiscoveryClient服務發現
- Eureka集群環境構建(linux)
- Eureka集群多網卡環境ip設置
- Eureka集群服務注冊與安全認證
- Eureka自我保護與健康檢查
- 主流服務注冊中心對比(含nacos)
- zookeeper概念及功能簡介
- zookeeper-linux集群安裝
- zookeeper服務注冊與發現
- consul概念及功能介紹
- consul-linux集群安裝
- consul服務注冊與發現
- 通用-auatator導致401問題
- 分布式配置中心-apollo
- 服務配置中心概念及使用場景
- apollo概念功能簡介
- apollo架構詳解
- apollo分布式部署之Portal
- apollo分布式部署之環境區分
- apollo項目權限管理實戰
- apollo-java客戶端基礎
- apollo與SpringCloud服務集成
- apollo實例配置熱更新
- apollo命名空間與集群
- apollo灰度發布(日志熱更新為例)
- SpringCloudConfig配置中心
- config-git配置文件倉庫
- config配置中心搭建與測試
- config客戶端基礎
- config配置安全認證
- config客戶端配置刷新
- config配置中心高可用
- BUS消息總線
- bus消息總線簡介
- docker安裝rabbitMQ
- 基于rabbitMQ的消息總線
- bus實現批量配置刷新
- alibaba-nacos
- nacos介紹與單機部署
- nacos集群部署方式(linux)
- nacos服務注冊與發現
- nacos服務注冊中心詳解
- nacos客戶端配置加載
- nacos客戶端配置刷新
- nacos服務配置隔離與共享
- nacos配置Beta發布
- 服務熔斷降級hystrix
- 服務降級&熔斷&限流
- Hystrix集成并實現服務熔斷
- Jemter模擬觸發服務熔斷
- Hystrix服務降級fallback
- Hystrix結合Feign服務降級
- 遠程服務調用異常傳遞的問題
- Hystrix-Feign異常攔截與處理
- Hystrix-DashBoard單服務監控
- Hystrix-dashboard集群監控
- 分布式系統流量衛兵sentinel
- sentinel簡介與安裝
- 客戶端集成與實時監控
- 實戰流控規則-QPS限流
- 實戰流控規則-線程數限流
- 實戰流控規則-關聯限流
- 實戰流控規則-鏈路限流
- 實戰流控效果-WarmUp
- 實戰流控效果-勻速排隊
- BlockException處理
- 實戰熔斷降級-RT
- 實戰熔斷降級-異常數與比例
- DegradeException處理
- 注解與異常的歸納總結
- Feign降級及異常傳遞攔截
- 動態規則nacos集中存儲
- 熱點參數限流
- 系統自適應限流
- 微服務網關-GateWay
- 還有必要學習Zuul么?
- 簡介與非阻塞異步IO模型
- GateWay概念與流程
- 新建一個GateWay項目
- 通用Predicate的使用
- 自定義PredicateFactory
- 編碼方式構建靜態路由
- Filter過濾器介紹與使用
- 自定義過濾器Filter
- 網關請求轉發負載均衡
- 結合nacos實現動態路由配置
- 整合Sentinel實現資源限流
- 跨域訪問配置
- 網關層面全局異常處理
- 微服務網關安全認證-JWT篇
- Gateway-JWT認證鑒權流程
- 登錄認證JWT令牌頒發
- 全局過濾器實現JWT鑒權
- 微服務自身內部的權限管理
- 微服務安全認證-OAuth篇(撰寫中)