[[341109]]

本文轉載自微信公眾號「SH的全棧筆記」，作者leonhlh 。轉載本文請聯系SH的全棧筆記公眾號。

這篇博客的本意是希望看到這篇文章的讀者能夠很輕松的理解我想表達的意思。但程序向的分享經常會不經意間就貼上了代碼，很可能就會讓人看的很懵。而且我認為分享一個東西，只有對方真正明白了其中的邏輯，才是有意義的分享。所以接下來我會嘗試用大家都能理解的語言來聊一聊”微服務“。

【寫在前面】

那么，什么是微服務呢?你不一定知道微服務，但是你一定知道麥某勞，而且知道麥某勞有個甜品站。你可能會問，甜品站和微服務有什么關聯呢?

讓我們先假設不把甜品站獨立出來，而是普通的麥某勞店。經營一段時間你會發現，這個地方雖然人流量很大，也有顧客，但是顧客的需求80-90%都集中在甜品，導致甜品供不應求，而其余的菜品則沒多少人購買。但是把這個店關了嗎?那也不行，始終是有流量的。

所以綜合考慮下來，方案就是把甜品這個“模塊”從整個店中獨立出來，單獨對外提供服務。這樣既能保住流量，也能避免浪費。

微服務也是一樣的，比如電商的服務，假設里面耦合了商品、庫存、訂單、用戶的服務，但是訂單這個模塊可能會訪問的特別頻繁，而用戶和商品被訪問的頻率沒有那么高，如果為了同時給更多用戶提供服務，而再部署一個包含了商品、庫存、訂單和用戶的服務，有兩個模塊的資源其實沒有被充分利用到。

跟甜品站的思路是一樣的，如果把商品、庫存、訂單和用戶分成四個服務模塊，每個服務只負責處理的自己的事情，就像甜品站只賣甜點一樣，如果訂單的訪問量大， 那也只需要再部署一個訂單的模塊，而不會造成資源利用不充分、耦合性強的情況。

最開始的“整家麥某勞”店對應的概念就是單體應用，后面獨立出的“甜品站”就是從單體應用中抽離出的“微服務”。不知道什么是單體應用和微服務是什么沒關系，不知道單體應用為什么、以及如何轉變成微服務的也沒關系，讓我們通過一個故事來完整的理解這個概念。

假設正在閱讀這篇文章的你，擁有一家飯店。

0.【夢開始的地方】

你盤下了一個店面想賣炸雞和甜品，于是你簡單的把店裝修了一下，購置了相關的設備，然后雇了廚師、服務員等相關的工作人員，就開始掛上招牌對外營業了，

0.1 店面

就是我們平常去使用的各種C端產品，如果你沒有一個概念，那么可以直接把它理解成釘釘、微信這樣一個我們日常都在用的APP就好，它們就是C端產品。

店的招牌(比如肯打雞和麥某勞)就可以理解為我們平常APP里所能看到的，所能使用的東西，我們叫它客戶端。

整個實體店就可以理解為開篇提到的“單體應用”，為客戶提供實際的服務。

0.2 裝修和購置設備

對應的是我們的開發團隊，從產品經理接到客戶的需求開始，根據需求整理好原型圖，不停的跟客戶溝通交流細節，反復的修改原型圖，最終定下來的需求。

然后我們的UI同學介入，根據原型圖出UI圖，并最終確定下來。然后就是前端和后端的開發同學根據原型圖中的邏輯，和UI圖的樣式細節開始迭代開發，并最終將產品上線。

0.3 炸雞和甜品

有了前面麥某勞的例子，這個應該很好理解。炸雞和甜品其實就是作為一個C端產品，提供給用戶的不同種類的服務。

例如我們日常在用的釘釘，可以用來聊天、開視頻會議和預定會議室。

1.【漸入佳境】

隨著你不斷的推出新的菜品，以及分量足，性價比高，朋友之間口口相傳—“那家蒼蠅館子還可以”，也留住了大量回頭客。慢慢的，來店里吃飯的客人越來越多，后廚漸漸忙不過來了。很多慕名而來的客人由于等了太長時間仍然沒有上菜，更有甚者連座位沒有。客人對美食的渴望轉化成了失望和憤怒，于是反手就是一個超級差評。

1.1 不斷的推出新的菜品

代表我們的產品迭代，不斷的推出新功能，以此來為用戶提供更多元化的服務，吸引更多的用戶來使用我們的產品。例如疫情期間，釘釘在在線學習這塊推出了很多新的功能。

1.2 朋友間的口口相傳

則代表的是部分用戶開始代替廣告這種傳播途徑，開始了社群內的用戶自傳播。這是很多產品都想達到的目的，把產品的潛力挖掘到極致，讓產品說話，為自己代言。

比起漫天飛的廣告，這種來自朋友們的推薦，更加受到用戶的信任。

1.3 關于差評

“后廚忙不過來”是指用戶數量上漲，日常的請求數就會隨之增多，而單個服務實例在某個時間單位內能夠處理請求的數量是有限的(也就是后廚人數有限，就那么幾個廚師，能做的菜數量也有限)，這也直接導致了部分用戶請求十分緩慢，甚至直接無法訪問(后廚實在忙不過來了，有些客人就要等很久)。而用戶對于產品的耐心是十分有限的，出現這種情況會導致部分甚至大量用戶流失。

2.【蜂擁而至】

隨著差評越來越多，你漸漸坐不住了。你覺得再這么下去你可能就要涼了，于是你想，廚師不夠用那就多招幾個嘛，于是雷厲風行的你貼出了招聘啟事，然后順利的招到了人。

人的問題解決了，那還有座位的問題。之前你沒有想到會有這么人多來光顧，所以店里面的桌子和椅子擺的很寬松，但是實際上重新規劃一下，還是能夠多放好幾張桌子的，這樣一來就能夠同時容納更多人在店里用餐。

2.1 多招人

我們每個服務所能使用的資源是有限制的，例如你可以給你的JVM設置最大堆內存為1G，也可以加到2G。啊?什么是JVM?不重要，讓我們重新理解前面一句話。2個廚師一分鐘可以做5個菜，你轉手再招2個廚師，那一分鐘就可以做10個菜，這對應的概念是擴容，也就是增加服務器能夠支配的運行資源，服務器就能夠處理更多的請求，服務更多的用戶。

這里的擴容是針對CPU和內存

2.2 重新規劃桌椅擺放

剛開始開發時沒有到用戶會有這么大體量，所以大部分的API沒有做什么優化，整個服務端應用的框架也搭建的很隨意，因為上線的時間很緊，這可能會造成應用在維護性、擴展性和性能上的弊端。

通俗點來說就是，當時為了店里擺放好看，追求ins風，桌椅之間擺的太寬了，但是后來人多了，外面一堆人排隊，店里面卻熙熙攘攘，但是實際上你卻是已經“坐滿了”。

這種情況十分不利于后續的迭代的。所以對應到開發中的概念就是，對代碼和框架進行重構，優化算法，讓API盡量少占用系統資源，降低響應延遲，從而提高整個服務的服務能力。這樣一來，服務實例就能扛住更多的請求。

不過有的時候，降低延遲和少占用系統資源不可兼得。如果對響應速度要求很高，就可能會多占一些系統資源，用空間來換時間。

就像你把店里重新擺放了，店里容納的人多了(占用資源多了)，這個時候服務的響應時間可能就會變慢(上菜就會變慢)，那么用空間換時間是什么呢?就是你會提前準備很多食材、甚至是半成品的食材堆在那里，這樣以來，只需要花平時一半的時間就可以把菜做好(比如提前準備好熟油，各種輔料等等)。

3.【山窮水盡】

雖然多招了幾個廚師，也重新規劃了店里桌椅擺放，但是隨著時間的推移，每天來店里吃飯的人還是越來越多，廚師已經不能再招了，已經沒有那么多灶臺了。之前的“差評熱潮”又開始在店里上演。你想著，雖然店里火爆是好事，但是每天有那么多的人來店里看到沒有位置就走了，這不是有錢賺不了嗎?

而且很多目標用戶在第三方網站上看到了這些差評，將會直接影響到客戶是否愿意來店里，這會使你喪失大量的隱藏客戶。于是你開始了轟轟烈烈的開分店業務，在附近又開了一家店。還是一樣的配方，就是這個味～

3.1 開分店

開分店對應的概念是多實體部署，就是把一個同樣的服務再部署一個，這樣一來來自用戶的流量就從一個服務扛變成了兩個服務扛。

分店就可以把原本要把總店塞爆的流量給接過去，緩解了壓力。

4.【柳暗花明】

隨著時間的推移，分店越開越多，生意自然也是蒸蒸日上。但是你作為一個能夠不只看表面的布局者，你發現了實際上的情況并沒有表現出來的那么好。

有些區域人流量大，而有些區域雖然人流量大，但是對店感興趣的人不多，甚至分店周圍根本沒有什么人。而有些地方的分店則異常火爆。雖然熱門的店賺的錢能夠抵上冷門的店的虧損，但是追求完美的你認為這種情況必須要得到改善，因為這始終是存在對資源的浪費。

所以經過一番調研，你決定在中心區域開一個顧客中心，所有想來餐廳的人都統一的來顧客中心，由顧客中心的人根據各個分店的火爆情況來分批次的把顧客送過去。這樣一來，也就解決了有些店火爆，而有些店冷清的情況了。

4.1 人流量分布不均勻

這種情況主要發生在服務端運行了多個實例，那也就對于多個IP地址，而要調用哪個是由客戶端來決定的，如果設計的不夠好，就會出現某些時候某些實例成為熱點實例，甚至出現“差評”實例這種情況，而其余實例則沒有承擔多少來自用戶的流量。

說人話就是，我要是顧客，我去哪家店不是看我心情嗎?我想去哪家店就去哪家店。當然實際情況沒有這么夸張，客戶端會有自己的策略。

而且同時維護如此多的服務端地址也是很麻煩的一件事，如果服務端此時又增加了實例，客戶端則需要同步的更新。但是如果用戶體量大的話，因為這種問題頻繁的發包讓用戶更新，會對用戶造成不好的體驗。

4.2 顧客中心

這個比喻有些夸張，現實中有人這么干可能早破產了。“顧客中心”就是我們說的“網關”。有了網關，客戶端就不用關心服務有多少個實例，也不用去維護所有的HOST，所有的請求直接從網關走，由網關來決定將當前請求分發到哪個實例。

“客戶中心分批次根據情況送顧客”其實對應到的概念是負載均衡，什么意思呢?就是要讓客戶端產生的流量對所有實例雨露均沾。其實現的方式也有很多，大致分為隨機、輪詢、一致性哈希、加權等等。

而網關除了負載均衡，還有很多其他的特性。例如，動態的路由、限流、認證、日志、熔斷、可編程插件配置等等。

5. 【微服務的關注點】

看完了這個故事，你可能會覺得沒有什么，但是實際上你已經了解了一個應用從單體應用架構轉為微服務的架構生命周期以及過程。這其中也包括為什么需要轉為微服務架構，和轉到微服務架構的好處在哪里。如果你都沒有意識到自己理解了這個概念，可以再閱讀一遍上面的小故事。

其實實際上的微服務要比上面故事所呈現出來的復雜很多，微服務中需要關注的點要比傳統的單體應用多的多。在微服務中我們需要關注服務的發現、負載均衡，統一的配置管理，微服務集群的自愈和彈性伸縮，服務的調度和發布，微服務中的調用鏈監控，包括Metrics監控，日志監控，服務的安全考慮，API的統一管理等等。

首先把強耦合在一起的代碼有條理的拆分出來就是一件很復雜的事情，微服務的劃分粒度也是一個很大的挑戰。例如很復雜的系統，一個用戶服務的代碼可能有好幾千上萬行，但是它仍然是一個微服務，沒有再拆分用戶服務A和用戶服務B。而有的服務可能代碼量只有幾百行，這需要根據實際的業務情況來選擇劃分的粒度。

除了拆分服務的粒度，微服務本身還有很多組件。大家在故事中只了解了網關。其實還有很多組件。

服務發布就涉及到Jenkins，把我們的應用打包成Docker Image，然后通過自動化工具發布到對應的環境中。我們的應用跑在Docker中，那么我們就需要有一個容器編排工具來管理這么多容器。例如我們現在使用的就是Docker Swarm，跟業界現在流行的Kubernetes一樣，有很多人在使用。

有了容器編排工具，就有工具的可視化界面，Docker Swarm對應的Portainer，和Kubernetes對應的Rancher。除此之外我們還要使用Gitlab來做我們的代碼版本管理工具，MySQL和MongoDB作為數據存儲的解決方案。Redis作為緩存的解決方案。同時需要有一個地方來統一管理所有服務的配置，我們叫微服務的配置中心。

除此之外，服務之間要相互調用就必須要知道對方的地址，就需要一個注冊中心，來保管所有服務的地址，并及時的更新服務的狀態。

還有很多細節，例如如何去構建一個Jenkins的構建流水線，如果實現一套CI/CD的流程，如果使用ELK去做統一的日志收集，如果在集群內實現SSO啊等等，由于篇幅原因就不在此一一贅述了。