面對微服務(wù)如火如荼的發(fā)展,，很多人都在了解，學(xué)習(xí)希望能在自己的項(xiàng)目中幫得上忙,，當(dāng)你對微服務(wù)的廬山真面目有所了解后,，接下來就是說服自己了，到底如何評估微服務(wù),，什么時(shí)候使用微服務(wù),，什么時(shí)間點(diǎn)最合適，需要哪些技術(shù)儲備和資源投入等等,，這些都是你需要面對和解決的,。

本文從單體架構(gòu)，微服務(wù)架構(gòu),，微服務(wù)風(fēng)險(xiǎn)評估,，微服務(wù)落地條件等幾個(gè)方面探討微服務(wù)的落地過程，希望對你有所啟發(fā),。

講解微服務(wù)之前,，我們先簡單了解下單體架構(gòu)。

一,、單體架構(gòu)

單體架構(gòu)的優(yōu)點(diǎn)：

• 快速開發(fā)和驗(yàn)證想法,，證明產(chǎn)品思路是否可行

• 投入資源和成本，包括人力和物力相對比較節(jié)約

單體架構(gòu)的缺點(diǎn)：

隨著業(yè)務(wù)的復(fù)雜度增加,，單體的靈活度會(huì)逐漸下降,，比如：

• IDE過載：隨著代碼量增加，代碼整體編譯效率下降,。

• 規(guī)?；簾o法滿足團(tuán)隊(duì)規(guī)模化高效開發(fā),。

• 系統(tǒng)開發(fā),、測試、部署的沖突和效率低下等問題

• 只能關(guān)注一套技術(shù)棧

• 應(yīng)用擴(kuò)展性比較差

• 海量用戶高并發(fā)訪問數(shù)量有限

單體適用場景：

架構(gòu)設(shè)計(jì)的三大原則告訴我們,，架構(gòu)需要的是簡單,、適度、演化,。

對于項(xiàng)目起步階段,，單體是最高效也是最節(jié)省成本的方式。因?yàn)槌跗陔A段,，由于人力,，成本，業(yè)務(wù)熟悉程度,，微服務(wù)技術(shù)積累等因素,，如何過度設(shè)計(jì)可能工期和復(fù)雜度會(huì)急劇上升，造成交付困難,，問題百出,，從而錯(cuò)過了時(shí)間窗口。最合適,，簡單的方式還是單體優(yōu)先,，這是創(chuàng)業(yè)公司的特點(diǎn)決定的。當(dāng)然設(shè)計(jì)面向微服務(wù)的單體架構(gòu)也是一種聰明的方法,，這遵守了系統(tǒng)演化的法則,。

單體分層目的：

無論采取何種維度的架構(gòu)分層，分層的最核心目的是保證各層之間的差異足夠清晰,，邊界足夠明顯,，為將來可能產(chǎn)生的變化提供最容易、最小化的修改,。比如客戶端要從安卓替換為IOS,，底層無須任何改動(dòng)，就像替換積木一樣,。又比如,，設(shè)備需要接入新的設(shè)備或協(xié)議，其他層也不需要做任何變化,，可以無縫平滑接入任何設(shè)備,。

建議

如果前期在業(yè)務(wù)不十分清晰，求的是驗(yàn)證想法,，證明產(chǎn)品思路是否可行性,，并且業(yè)務(wù)量不大，僅限于省級范圍,，建議只要對當(dāng)前架構(gòu)稍加改良升級就可以了,，這樣改動(dòng)量相對較小，且至少能支撐一定時(shí)間段的業(yè)務(wù)增長,。

二,、微服務(wù)架構(gòu)

微服務(wù)的優(yōu)勢

支撐的業(yè)務(wù)更加龐大，可以支撐海量用戶高并發(fā)和海量設(shè)備接入,，支持分布式多機(jī)房,，多區(qū)域部署,，支持服務(wù)器無限擴(kuò)容。支持私有云,，公有云,，混合云等部署方式。所以微服務(wù)是大多數(shù)互聯(lián)網(wǎng)公司的首選,。

微服務(wù)的代價(jià)

• 技術(shù)門檻高：微服務(wù)包括,，服務(wù)描述，注冊中心,，服務(wù)框架,，服務(wù)監(jiān)控，服務(wù)追蹤,，服務(wù)治理等幾大基本組件,，以上每個(gè)組件缺一不可，每個(gè)組件展開又包括很多技術(shù)門檻,，比如,，容器技術(shù)，持續(xù)部署,，DevOps等相關(guān)概念,。

• 復(fù)雜性增加：相對單體架構(gòu)將所有功能打包部署在一起，集中地進(jìn)行開發(fā),、測試和運(yùn)維,，微服務(wù)會(huì)將這些單體的服務(wù)進(jìn)行拆分部署，業(yè)務(wù)拆分粒度是一個(gè)難點(diǎn),，拆分后服務(wù)聚合也是一個(gè)麻煩,。因?yàn)榉?wù)粒度增加后，相互調(diào)用,，相互依存,，所以問題排查難度會(huì)增加，就需要一套完整的服務(wù)監(jiān)控,，服務(wù)跟蹤和治理的系統(tǒng),。

• 觀念變化：微服務(wù)不僅僅是技術(shù)的升級，更是開發(fā)方式,、組織架構(gòu),、開發(fā)觀念的轉(zhuǎn)變。

• 前期投入成本較高

微服務(wù)架構(gòu)圖

微服務(wù)架構(gòu)圖譜谷歌或Bing下,，可以看到各種各樣的架構(gòu)圖,，源于業(yè)務(wù)和架構(gòu)師自身的喜好或者粗細(xì)粒度，但是每個(gè)架構(gòu)圖的基本組件和架構(gòu)分層都差別不大,，只是有的細(xì)一些,，有的粗一下,。比如有客戶端層，容器層(K8S),，API Gateway,，微服務(wù)集群層，EventBus層是必須要有的,，至于服務(wù)監(jiān)控和服務(wù)跟蹤、服務(wù)治理本身就是一個(gè)完整的系統(tǒng),，粒度就沒有細(xì)了,。基于這些概念,，我把架構(gòu)圖稍微細(xì)化一下,，這里省去服務(wù)監(jiān)控跟蹤和治理的部分，后續(xù)單獨(dú)抽離出來分析,。

這邊的架構(gòu)圖譜相對之前的架構(gòu)圖,，更加貼近業(yè)務(wù)，粒度也更細(xì),，雖然個(gè)別組件有所省略,，比如跟蹤和治理部分。

以上架構(gòu)圖主要分4層,，每個(gè)層次遵循架構(gòu)分層的核心思想：關(guān)注點(diǎn)分離,，職責(zé)各異，邊界清晰,。

第1層：客戶端：理論上包含一切可以聯(lián)網(wǎng)的設(shè)備,，包括移動(dòng)設(shè)備，Android,、IoS,、Pad、微信,、微博,、QQ、Web,、各自瀏覽器,、物聯(lián)網(wǎng)設(shè)備等等……

第2層：API網(wǎng)關(guān)：包括服務(wù)注冊，發(fā)現(xiàn),，認(rèn)證授權(quán),，單點(diǎn)登錄，熔斷,，限流……網(wǎng)關(guān)的知識點(diǎn)豐富,，是微服務(wù)的核心之一,。

• 假如網(wǎng)關(guān)對外提供統(tǒng)一的地址：www.jackyfei.com

第3層：微服務(wù)集群：包括各種具體的microservice，比如縱向劃分的業(yè)務(wù)服務(wù)(用戶服務(wù),，訂單服務(wù),，……)，橫向劃分的基礎(chǔ)或公共服務(wù)(元數(shù)據(jù)服務(wù),，公共服務(wù)……)

其他微服務(wù)的地址可能是這樣的：

• 用戶服務(wù)：1.user.jackyfei.com

• 訂單服務(wù)：2.order.jackyfei.com

• 元數(shù)據(jù)服務(wù)：3.base.jackyfei.com

• 消息服務(wù)：4.msg.jackyfei.com

第4層：事件總線：Event Bus 目的是消息解耦,，不要讓服務(wù)之間直接的鏈接。不同與SOA的服務(wù)總線,，事件總線相對比較輕量,，經(jīng)常基于消息隊(duì)列引擎進(jìn)行解耦,，目的是為了讓服務(wù)之間的關(guān)聯(lián)弱化,，不直接進(jìn)行關(guān)聯(lián)。很多時(shí)候用的是相對穩(wěn)定,、可靠,、企業(yè)級的RabbitMQ。

微服務(wù)的架構(gòu)其實(shí)不難,，根據(jù)以上的架構(gòu),，每種業(yè)務(wù)都可以進(jìn)行套用，這里的難點(diǎn)在于服務(wù)的劃分和粒度控制,，另外如何管理膨脹的服務(wù)是一個(gè)麻煩事,。

三、何時(shí)采用微服務(wù)?

1,、楊波說

這里引用架構(gòu)師楊波(前Ebay架構(gòu)師,，目前任職拍拍貸研發(fā)部總監(jiān)，資深技術(shù)架構(gòu)師,，微服務(wù)技術(shù)專家)的一些觀點(diǎn)：

“企業(yè)一開始不推薦直接使用微服務(wù),，因?yàn)槲⒎?wù)需要前期基礎(chǔ)設(shè)施的投資，復(fù)雜性很高,，如果對問題領(lǐng)域并不是很理解,，一開始用微服務(wù)，你很難去劃分服務(wù)的邊界,，你的生產(chǎn)力反而會(huì)比較低,，而且你花了很大精力進(jìn)行開發(fā)，你的產(chǎn)品并沒有被市場驗(yàn)證過,，有可能會(huì)失敗,，所以這個(gè)選項(xiàng)風(fēng)險(xiǎn)會(huì)比較高。所以我們推薦的是單塊優(yōu)先，先從單塊運(yùn)用做起,，這樣成本低,，團(tuán)隊(duì)成員也比較少，無須太多研發(fā)投入,，就可以交付一些基本的功能給客戶使用,。

隨著應(yīng)用越來越成功，客戶增加,，你的系統(tǒng)復(fù)雜度會(huì)越來越高,，就會(huì)出現(xiàn)單塊應(yīng)用和團(tuán)隊(duì)規(guī)模之間的矛盾，生產(chǎn)力會(huì)隨著業(yè)務(wù)復(fù)雜度逐漸降低,。所以在一些初創(chuàng)型公司,，你更多看到的是單塊應(yīng)用，只有一些中大型的公司會(huì)看到微服務(wù)架構(gòu),?！?/span>  

“交叉點(diǎn)表明,，業(yè)務(wù)已經(jīng)到達(dá)了一定的復(fù)雜性,，單塊應(yīng)用已經(jīng)無法滿足業(yè)務(wù)增長的需要，研發(fā)效率開始下降了,，而微服務(wù)可以提升研發(fā)和交付的效率,。這個(gè)點(diǎn)需要架構(gòu)師去綜合，權(quán)衡,。個(gè)人經(jīng)驗(yàn),，一般團(tuán)隊(duì)需要達(dá)到百人規(guī)模，才去考慮微服務(wù),?！?/span>

以上的觀點(diǎn)講的很中肯，給我的啟發(fā)和幫助非常大,。這里的交叉點(diǎn)怎么來確定和評估是重點(diǎn),，比如我們上線一個(gè)社交姑且叫抖信，初期為了快速上線,，驗(yàn)證可行性,，可以只開發(fā)首頁聊天、通訊錄,、評論等基本功能,。產(chǎn)品上線后，經(jīng)過一段時(shí)間的運(yùn)營,，用戶開始逐步增多,，可行性驗(yàn)證通過，下一階段就需要進(jìn)一步增加更多的新特性來吸引更多的目標(biāo)用戶，比如再給這個(gè)社交抖信添加朋友圈,、消息通知,、游戲、電商等等功能,。

“一般情況下,，這個(gè)時(shí)候就需要大規(guī)模地?cái)U(kuò)張開發(fā)人員，以支撐多個(gè)功能的開發(fā),。如果這個(gè)時(shí)候繼續(xù)采用單體應(yīng)用架構(gòu),，多個(gè)功能模塊混雜在一起開發(fā)、測試和部署的話,，就會(huì)導(dǎo)致不同功能之間相互影響,，一次打包部署需要所有的功能都測試 OK 才能上線。

不僅如此,，多個(gè)功能模塊混部在一起,，對線上服務(wù)的穩(wěn)定性也是個(gè)巨大的挑戰(zhàn)。比如 A 開發(fā)的一個(gè)功能由于代碼編寫考慮不夠全面,，上線后產(chǎn)生了內(nèi)存泄漏,，運(yùn)行一段時(shí)間后進(jìn)程異常退出，那么部署在這個(gè)服務(wù)池中的所有功能都不可訪問,。

根據(jù)我的實(shí)際項(xiàng)目經(jīng)驗(yàn),，一旦單體應(yīng)用同時(shí)進(jìn)行開發(fā)的人員超過 10 人，就會(huì)遇到上面的問題,，這個(gè)時(shí)候就該考慮進(jìn)行服務(wù)化拆分了,。”---胡忠想(微博微服務(wù)技術(shù)專家)

至此,，我們何時(shí)采用微服務(wù)已經(jīng)十分明確了,，關(guān)鍵是業(yè)務(wù)復(fù)雜度和團(tuán)隊(duì)規(guī)模兩大要點(diǎn)，而業(yè)務(wù)復(fù)雜度和市場窗口是權(quán)衡和抉擇的首要因素,。

2,、微服務(wù)落地條件評估

一般情況下，業(yè)務(wù)系統(tǒng)引入新技術(shù)就必然會(huì)帶來架構(gòu)的復(fù)雜度提升,，在具體決策前,，你先要認(rèn)識到新架構(gòu)會(huì)帶來哪些新的問題，這些問題你和你的團(tuán)隊(duì)是否能夠解決,？如何解決,？是自己投入人力建設(shè)，還是采用業(yè)界開源方案,？假如你和我一樣都是微服務(wù)的旁觀者或者學(xué)習(xí)者,，那么下面的評估也許對你又所參考,。

• ① 落地方式選擇

  不同的落地方式?jīng)Q定不同的資源配置。

  方式一：借力外部架構(gòu)咨詢公司提供架構(gòu)DEMO和培訓(xùn)服務(wù)助推內(nèi)部團(tuán)隊(duì)技術(shù)轉(zhuǎn)型升級,。

  方式二：招聘相關(guān)經(jīng)驗(yàn)豐富的人員進(jìn)來,，自行研究和搭建架構(gòu)并做內(nèi)部培訓(xùn)，推動(dòng)團(tuán)隊(duì)技術(shù)升級,。

  建議：如果比較緊急,，采用第一種方式，因?yàn)檎衅钙ヅ涞娜瞬疟容^困難,，等不起,。但是不管是那種方式，對于團(tuán)隊(duì)來說都需要一定的技術(shù)人才儲備方便后續(xù)交接和運(yùn)維,。

• ② 人才儲備

  這里分成兩類人員,，一類是研究型，一類是應(yīng)用型,。研究型主要是以技術(shù)攻堅(jiān)為主,，負(fù)責(zé)微服務(wù)的核心組件的研究和開發(fā)，比如服務(wù)發(fā)布和訂閱,，服務(wù)跟蹤和監(jiān)控,，服務(wù)的治理；應(yīng)用型主要是負(fù)責(zé)技術(shù)理解應(yīng)用為主,。

• ③ 技術(shù)儲備

  微服務(wù)相關(guān)技術(shù)棧和微服務(wù)周邊技術(shù)棧,。周邊技術(shù)棧包括領(lǐng)域驅(qū)動(dòng)涉及,，持續(xù)交付,，分布式至少，負(fù)載均衡,，CAP理論,，緩存原理，DevOps和容器化技術(shù),。

• ④ 團(tuán)隊(duì)規(guī)模評估

  楊波在給微服務(wù)的開發(fā)團(tuán)隊(duì)規(guī)劃時(shí)候給了一個(gè)百人左右的大概預(yù)估,，至于到底需要多少開發(fā)人員就沒有細(xì)說，可能作者本身呆過的公司都是大廠,，對人力成本控制沒有那么大的包袱,，對于中小企業(yè)，人力是最貴的成本,。如果要一定要上微服務(wù),，該怎么辦？

  對于微服務(wù)的團(tuán)隊(duì)規(guī)模眾說紛紜,，有的說要百來號人,；有的說需要精兵10人左右；有的說和人數(shù)沒有關(guān)系，只和業(yè)務(wù)有關(guān),；有的說一個(gè)懂微服務(wù)的架構(gòu)師也能搞定,。這些說法都比較籠統(tǒng)，如果你想上微服務(wù),，人力評估包括人力,、能力、人數(shù)等等,，這些因素還是非常重要的,，畢竟成本才是商業(yè)的本質(zhì)，有可能不客觀的規(guī)劃會(huì)導(dǎo)致項(xiàng)目的潰敗,。 

  對于微服務(wù)的團(tuán)隊(duì)規(guī)模是哪些方面決定的呢,？我覺得至少要從以下兩個(gè)維度來評估：

  業(yè)務(wù)規(guī)模：如果你們的業(yè)務(wù)架構(gòu)非常復(fù)雜，有倉儲系統(tǒng)開發(fā),，ERP系統(tǒng),，OA系統(tǒng)，訂單系統(tǒng)等等,，業(yè)務(wù)越多,，需求人數(shù)越多(這里人數(shù)指的都是后臺開發(fā)人數(shù))。

  技術(shù)能力：另外,，別忘了非功能性的開發(fā),，比如API網(wǎng)關(guān)，服務(wù)跟蹤,、治理等也是需要人去開發(fā)和維護(hù)的,，這些非功能性的核心組件需要多少人，由于沒有完整的開發(fā)經(jīng)驗(yàn),，加上個(gè)別組件,，比如跟蹤系統(tǒng)，開發(fā)的程度可深可淺,，開發(fā)周期可長可短,，以目前個(gè)人的經(jīng)驗(yàn)還無法給與合理的建議?？赡芘Ｈ?個(gè)人兩周就夠了,，也可能高級開發(fā)2個(gè)人，一人分工三個(gè)核心組件,，兩周也夠用,。或者架構(gòu)外包,，只要交接的人能跟上,，也是一種解決方案,。

  總結(jié)：1個(gè)精通微服務(wù)落地經(jīng)驗(yàn)的架構(gòu)師是必不可少的，圍繞架構(gòu)師周邊一幫高級開發(fā),，按根據(jù)實(shí)際業(yè)務(wù)來確定,，一般一個(gè)開發(fā)負(fù)責(zé)2-3個(gè)核心模塊，不宜太多,，比如目前核心模塊有8個(gè),，對應(yīng)人數(shù)配置大概在3-4個(gè)左右。

3,、轉(zhuǎn)微服務(wù)風(fēng)險(xiǎn)評估

• ① 重寫面廣

  由于是架構(gòu)級別的調(diào)整,，之前能保留下來的大部分是解耦比較好的代碼，比如前端代碼,，采集服務(wù)代碼,，部分業(yè)務(wù)邏輯代碼，所以對現(xiàn)有框架沖擊面比較大,。

• ② 復(fù)雜度高

  因?yàn)槲⒎?wù)是一種觀念和思想,，又是新近技術(shù)，本身就有各種架構(gòu)實(shí)現(xiàn)方式和技術(shù)解決方案,。所以對技術(shù)人員來說,，對比選型本身就是一個(gè)考驗(yàn)。加上本身涉及的技術(shù)面就比較廣,，所以復(fù)雜度和門檻相對比較高,。

  但是該技術(shù)發(fā)源于亞馬遜，經(jīng)過近些年的發(fā)展,，雖然還在發(fā)展,，但是已經(jīng)相對成熟。

• ③ 人員配置

  微服務(wù)架構(gòu)工作量主要集中在后端,，對后端開發(fā)人員的技術(shù)級別有較高的要求,，主要是對微服務(wù)原理和開源組件的熟悉上,，同時(shí)需要具備整體的微服務(wù)的意識,。暫時(shí)不具備整體微服務(wù)開發(fā)意識和經(jīng)驗(yàn)，需要通過培訓(xùn)后進(jìn)行轉(zhuǎn)型升級,。

• ④ 合作方式

  如果采用借助外部架構(gòu)力量來助推架構(gòu)升級,，和架構(gòu)單位的合作就不是簡單的外包，涉及的面會(huì)變得比較廣,，在完全交接過來之前,，周期會(huì)比較長。包括對我們業(yè)務(wù)架構(gòu)的深入了解,，然后根據(jù)業(yè)務(wù)架構(gòu)繪制可靠技術(shù)架構(gòu)藍(lán)圖,，再根據(jù)技術(shù)藍(lán)圖進(jìn)行落地實(shí)施(不建議只提供架構(gòu)方案而由其他單位實(shí)施落地),，包括新系統(tǒng)的開發(fā)，舊系統(tǒng)的升級,，當(dāng)然這種升級是平滑過度的,，對業(yè)務(wù)窗口并不會(huì)產(chǎn)生影響。

4,、合理的拆分姿勢

如何正確拆分,？這里正確指的是合理，因?yàn)闆]有絕對的標(biāo)準(zhǔn),。按照前人的經(jīng)驗(yàn)可以分為縱向和橫向兩種劃分方法：

• ① 縱向拆分

  是從業(yè)務(wù)維度進(jìn)行拆分,。標(biāo)準(zhǔn)是按照業(yè)務(wù)的關(guān)聯(lián)程度來決定，關(guān)聯(lián)比較密切的業(yè)務(wù)適合拆分為一個(gè)微服務(wù),，而功能相對比較獨(dú)立的業(yè)務(wù)適合單獨(dú)拆分為一個(gè)微服務(wù),，比如上圖中的訂單服務(wù)，用戶服務(wù),。另外粒度太小,，服務(wù)聚合是一個(gè)坑，粒度太大,，分和沒分一個(gè)樣,。

• ② 橫向拆分

  是從公共且獨(dú)立功能維度拆分。標(biāo)準(zhǔn)是按照是否有公共的被多個(gè)其他服務(wù)調(diào)用,，且依賴的資源獨(dú)立不與其他業(yè)務(wù)耦合,。比如上圖中的元數(shù)據(jù)服務(wù)和消息服務(wù)。

• ③ 總結(jié)

  借用《微服務(wù)設(shè)計(jì)》中的一句話：“你越不了解一個(gè)領(lǐng)域,，為服務(wù)找到合適的界限上下文就越難……服務(wù)的界限劃分錯(cuò)誤,，可能會(huì)導(dǎo)致不得不頻繁地更改服務(wù)間的協(xié)作，而這種更改成本更高……”

四,、SOA和微服務(wù)

由于SOA和微服務(wù)有千絲萬縷的關(guān)系,，這里簡單羅列雙方的對比圖，算是一個(gè)小知識點(diǎn)：

兩種架構(gòu)背后的意圖是不同的：SOA嘗試將應(yīng)用集成,，一般采用中央管理模式來確保各應(yīng)用能夠交互運(yùn)作,。微服務(wù)嘗試部署新功能，快速有效地?cái)U(kuò)展開發(fā)團(tuán)隊(duì),。它著重于分散管理,、代碼再利用與自動(dòng)化執(zhí)行。

五,、總結(jié)

最后讓我們回顧一下前人經(jīng)典的話語：

• 分布式第一定律是“盡量不要使用分布式”,。

• 軟件行業(yè)從業(yè)者，尤其是那些已經(jīng)不寫代碼的從業(yè)者,，總會(huì)期望有銀彈,，但銀彈終究是沒有的,。

• 微服務(wù)依賴于“基礎(chǔ)設(shè)施自動(dòng)化”。微服務(wù)不是“銀彈”,。

還是回到我們架構(gòu)設(shè)計(jì)的原則上,，遵循簡單，適用,，演化的原則,，那么你的抉擇也許會(huì)變得沒有那么令人糾纏。