看到最近“微服務(wù)架構(gòu)”這個(gè)概念這么火，作為一個(gè)積極上進(jìn)的程序猿，

成小胖忍不住想要學(xué)習(xí)學(xué)習(xí)。

而架構(gòu)師老王（不是隔壁老王）

最近剛好在做公司基礎(chǔ)服務(wù)的微服務(wù)化研究和落地，對此深有研究。

于是成小胖馬上屁顛屁顛的跑過去向老王請教：

“王哥，我看微服務(wù)架構(gòu)這么火，我也想學(xué)，您給我講講啥是微服務(wù)架構(gòu)唄？”

老王笑了笑說：

“要想知道什么是微服務(wù)架構(gòu)，你得先知道什么系統(tǒng)架構(gòu)設(shè)計(jì)?！?/p>

成小胖的理想是成為一名架構(gòu)師，平時(shí)積累了不少知識(shí)，因此對“系統(tǒng)架構(gòu)設(shè)計(jì)”這個(gè)概念還是很熟悉的，因此他馬上就給出了答案【1】：

系統(tǒng)架構(gòu)設(shè)計(jì)描述了在應(yīng)用系統(tǒng)的內(nèi)部，如何根據(jù)業(yè)務(wù)、技術(shù)、組織、靈活性、可擴(kuò)展性以及可維護(hù)性等多種因素，將應(yīng)用系統(tǒng)劃分成不同的部分，并使這些部分彼此之間相互分工、相互協(xié)作，從而為用戶提供某種特定的價(jià)值的方式。

老王滿意的點(diǎn)點(diǎn)頭，繼續(xù)問：

“你看最近我在做微服務(wù)的研究和落地，你知道為什么要做這個(gè)事情嗎？”

“因?yàn)槟壳暗娜龑蛹軜?gòu)存在很多弊端，不滿足業(yè)務(wù)發(fā)展的需求了唄?！?/p>

“對的，我看你對公司目前的架構(gòu)也非常熟悉了，你來仔細(xì)說說現(xiàn)在的三層架構(gòu)吧?！?/p>

于是成小胖拿了一張A4紙，圖文并茂地給老王講了他對三層架構(gòu)的理解：

三層架構(gòu)是指在業(yè)務(wù)和技術(shù)的發(fā)展過程中，系統(tǒng)中不同職責(zé)的部分被定義在不同的層次，每一層負(fù)責(zé)的功能更加具體化。三層架構(gòu)通常包括表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層，層與層之間互相連接、互相協(xié)作，構(gòu)成一個(gè)整體，并且層的內(nèi)部可以被替換成其他可以工作的部分，但對整體的影響不大。

以 Web 應(yīng)用程序?yàn)槔缙谑菍⑺械谋硎具壿?、業(yè)務(wù)邏輯和數(shù)據(jù)訪問邏輯放在一起，這就是一層架構(gòu)。

后來隨著 java、.NET 等高級(jí)語言的發(fā)展，提供了越來越方便的數(shù)據(jù)訪問機(jī)制，如 java 的 JDBC 和 .NET 的 ADO.NET。這時(shí)數(shù)據(jù)訪問部分被分離開來，形成了二層架構(gòu)。

再后來，隨著面向?qū)ο笤O(shè)計(jì)、企業(yè)架構(gòu)模式等理念的不斷發(fā)展，表示邏輯和業(yè)務(wù)邏輯也被分離開來，形成了現(xiàn)在的三層架構(gòu)。

三層架構(gòu)的具體內(nèi)容如下

表示層：用戶使用應(yīng)用程序時(shí)，看到的、聽見的、輸入的或者交互的部分。

業(yè)務(wù)邏輯層：根據(jù)用戶輸入的信息，進(jìn)行邏輯計(jì)算或者業(yè)務(wù)處理的部分。

數(shù)據(jù)訪問層：關(guān)注有效地操作原始數(shù)據(jù)的部分，如將數(shù)據(jù)存儲(chǔ)到存儲(chǔ)介質(zhì)（如數(shù)據(jù)庫、文件系統(tǒng)）及從存儲(chǔ)介質(zhì)中讀取數(shù)據(jù)等。

老王對這個(gè)解釋非常滿意，作了進(jìn)一步的補(bǔ)充：

“你看雖然現(xiàn)在程序被分成了三層，但只是邏輯上的分層，并不是物理上的分層。也就是說，對不同層的代碼而言，經(jīng)過編譯、打包和部署后，所有的代碼最終還是運(yùn)行在同一個(gè)進(jìn)程中。而這，就是所謂的單塊架構(gòu)?！?/p>

成小胖撓了撓頭：“原來單塊架構(gòu)是這個(gè)意思啊~~”

“嗯。根據(jù)你的實(shí)際工作經(jīng)驗(yàn)，你再總結(jié)下單塊架構(gòu)的優(yōu)缺點(diǎn)吧。”

平時(shí)勤于總結(jié)的成小胖很快便列出了單塊架構(gòu)的優(yōu)缺點(diǎn)：

優(yōu)點(diǎn)

1易于開發(fā)：

開發(fā)方式簡單，IDE 支持好，方便運(yùn)行和調(diào)試。

2易于測試：

所有功能運(yùn)行在一個(gè)進(jìn)程中，一旦進(jìn)程啟動(dòng)，便可以進(jìn)行系統(tǒng)測試。

3易于部署：

只需要將打好的一個(gè)軟件包發(fā)布到服務(wù)器即可。

4易于水平伸縮：

只需要?jiǎng)?chuàng)建一個(gè)服務(wù)器節(jié)點(diǎn)，配置好運(yùn)行時(shí)環(huán)境，再將軟件包發(fā)布到新服務(wù)器節(jié)點(diǎn)即可運(yùn)行程序（當(dāng)然也需要采取分發(fā)策略保證請求能有效地分發(fā)到新節(jié)點(diǎn)）。

缺點(diǎn)

1維護(hù)成本大：

當(dāng)應(yīng)用程序的功能越來越多、團(tuán)隊(duì)越來越大時(shí)，溝通成本、管理成本顯著增加。當(dāng)出現(xiàn) bug 時(shí)，可能引起 bug 的原因組合越來越多，導(dǎo)致分析、定位和修復(fù)的成本增加；并且在對全局功能缺乏深度理解的情況下，容易在修復(fù) bug 時(shí)引入新的 bug。

2持續(xù)交付周期長：

構(gòu)建和部署時(shí)間會(huì)隨著功能的增多而增加，任何細(xì)微的修改都會(huì)觸發(fā)部署流水線。

3新人培養(yǎng)周期長：

新成員了解背景、熟悉業(yè)務(wù)和配置環(huán)境的時(shí)間越來越長。

4技術(shù)選型成本高：

單塊架構(gòu)傾向于采用統(tǒng)一的技術(shù)平臺(tái)或方案來解決所有問題，如果后續(xù)想引入新的技術(shù)或框架，成本和風(fēng)險(xiǎn)都很大。

5可擴(kuò)展性差：

隨著功能的增加，垂直擴(kuò)展的成本將會(huì)越來越大；而對于水平擴(kuò)展而言，因?yàn)樗写a都運(yùn)行在同一個(gè)進(jìn)程，沒辦法做到針對應(yīng)用程序的部分功能做獨(dú)立的擴(kuò)展。

2

2

老王拍了拍成小胖的肩膀，眼睛瞇成了一條縫：

“小伙子總結(jié)的很不錯(cuò)！既然你已經(jīng)對目前的單塊架構(gòu)的優(yōu)缺點(diǎn)有了很好的理解，那現(xiàn)在咱們就可以開始來學(xué)習(xí)微服務(wù)架構(gòu)了。”

老王先從網(wǎng)上搜索“微服務(wù)架構(gòu)”關(guān)鍵字，出來這么一段話：

微服務(wù)架構(gòu)是一種架構(gòu)模式，它提倡將單一應(yīng)用程序劃分成一組小的服務(wù)，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供最終價(jià)值。每個(gè)服務(wù)運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)于服務(wù)間采用輕量級(jí)的通信機(jī)制互相溝通（通常是基于 HTTP 的 RESTful API）。每個(gè)服務(wù)都圍繞著具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立地部署到生產(chǎn)環(huán)境、類生產(chǎn)環(huán)境等。另外，應(yīng)盡量避免統(tǒng)一的、集中式的服務(wù)管理機(jī)制，對具體的一個(gè)服務(wù)而言，應(yīng)根據(jù)業(yè)務(wù)上下文，選擇合適的語言、工具對其進(jìn)行構(gòu)建。

成小胖看完了這段話，說：

“看著有點(diǎn)暈，云里霧里的感覺……”

老王嘿嘿一笑：

“莫慌，現(xiàn)在就給你詳細(xì)講講微服務(wù)架構(gòu)的特性?！?/p>

1. 單一職責(zé)

微服務(wù)架構(gòu)中的每個(gè)服務(wù)，都是具有業(yè)務(wù)邏輯的，符合高內(nèi)聚、低耦合原則以及單一職責(zé)原則的單元，不同的服務(wù)通過“管道”的方式靈活組合，從而構(gòu)建出龐大的系統(tǒng)。

2. 輕量級(jí)通信

服務(wù)之間通過輕量級(jí)的通信機(jī)制實(shí)現(xiàn)互通互聯(lián)，而所謂的輕量級(jí)，通常指語言無關(guān)、平臺(tái)無關(guān)的交互方式。

對于輕量級(jí)通信的格式而言，我們熟悉的 XML 和 JSON，它們是語言無關(guān)、平臺(tái)無關(guān)的；對于通信的協(xié)議而言，通?；?HTTP，能讓服務(wù)間的通信變得標(biāo)準(zhǔn)化、無狀態(tài)化。目前大家熟悉的 REST（Representational State Transfer）是實(shí)現(xiàn)服務(wù)間互相協(xié)作的輕量級(jí)通信機(jī)制之一。使用輕量級(jí)通信機(jī)制，可以讓團(tuán)隊(duì)選擇更適合的語言、工具或者平臺(tái)來開發(fā)服務(wù)本身。

3. 獨(dú)立性

每個(gè)服務(wù)在應(yīng)用交付過程中，獨(dú)立地開發(fā)、測試和部署。

在單塊架構(gòu)中所有功能都在同一個(gè)代碼庫，功能的開發(fā)不具有獨(dú)立性；當(dāng)不同小組完成多個(gè)功能后，需要經(jīng)過集成和回歸測試，測試過程也不具有獨(dú)立性；當(dāng)測試完成后，應(yīng)用被構(gòu)建成一個(gè)包，如果某個(gè)功能存在 bug，將導(dǎo)致整個(gè)部署失敗或者回滾。

在微服務(wù)架構(gòu)中，每個(gè)服務(wù)都是獨(dú)立的業(yè)務(wù)單元，與其他服務(wù)高度解耦，只需要改變當(dāng)前服務(wù)本身，就可以完成獨(dú)立的開發(fā)、測試和部署。

4. 進(jìn)程隔離

單塊架構(gòu)中，整個(gè)系統(tǒng)運(yùn)行在同一個(gè)進(jìn)程中，當(dāng)應(yīng)用進(jìn)行部署時(shí)，必須停掉當(dāng)前正在運(yùn)行的應(yīng)用，部署完成后再重啟進(jìn)程，無法做到獨(dú)立部署。

有時(shí)候我們會(huì)將重復(fù)的代碼抽取出來封裝成組件，在單塊架構(gòu)中，組件通常的形態(tài)叫做共享庫（如 jar 包或者 DLL），但是當(dāng)程序運(yùn)行時(shí)，所有組件最終也會(huì)被加載到同一進(jìn)程中運(yùn)行。

在微服務(wù)架構(gòu)中，應(yīng)用程序由多個(gè)服務(wù)組成，每個(gè)服務(wù)都是高度自治的獨(dú)立業(yè)務(wù)實(shí)體，可以運(yùn)行在獨(dú)立的進(jìn)程中，不同的服務(wù)能非常容易地部署到不同的主機(jī)上。

理論上所有服務(wù)可以部署在同一個(gè)服務(wù)器節(jié)點(diǎn)，但是并不推薦這么做，因?yàn)槲⒎?wù)架構(gòu)的主旨就是高度自治和高度隔離。

“王哥你真厲害，您這么一說我的思維清晰了很多！”成小胖激動(dòng)的幾乎要叫起來。

“我之前了解過 SOA，好像跟微服務(wù)架構(gòu)的思想很像啊，您能幫我區(qū)分一下嗎？”

成小胖追問到。

老王嘿嘿一笑，拿起成小胖手上的A4紙，翻到另外一面畫了個(gè)表格：

接著老王又畫了一張圖：

成小胖看了之后說：

“您這么一畫我倒是大概明白了，但是圖里面的 DevOps 這個(gè)概念我不懂誒……”

“這個(gè) DevOps 就說來話長了，有時(shí)間你自己先去查查資料了解下吧?！?/p>

“好的。現(xiàn)在我對微服務(wù)架構(gòu)的概念有了了解，您能再深入剖析下它的本質(zhì)嗎？”

“好，你可仔細(xì)聽好了哈！”

1. 服務(wù)作為組件

微服務(wù)也可以被認(rèn)為是一種組件，但是跟傳統(tǒng)組件的區(qū)別在于它可以獨(dú)立部署，因此它的一個(gè)顯著的優(yōu)勢。另外一個(gè)優(yōu)點(diǎn)是，它在組件與組件之間定義了清晰的、語言無關(guān)、平臺(tái)無關(guān)的規(guī)范接口，耦合度低，靈活性非常高。但它的不足之處是，分布式調(diào)用嚴(yán)重依賴于網(wǎng)絡(luò)的可靠性和穩(wěn)定性。

2. 圍繞業(yè)務(wù)組織團(tuán)隊(duì)

在單塊架構(gòu)中，企業(yè)一般會(huì)根據(jù)技能劃分團(tuán)隊(duì)，在這種組織架構(gòu)下，即便是簡單的需求變更都有可能需要跨團(tuán)隊(duì)協(xié)作，溝通成本很高。而在微服務(wù)架構(gòu)中，它提倡以業(yè)務(wù)為核心，按照業(yè)務(wù)能力來組織團(tuán)隊(duì)，團(tuán)隊(duì)中的成員具有多樣性的技能。

3. 關(guān)注產(chǎn)品而非項(xiàng)目

在單塊架構(gòu)中，應(yīng)用基本上是基于“項(xiàng)目模式”構(gòu)建的，即項(xiàng)目啟動(dòng)時(shí)從不同技能資源池中抽取相關(guān)資源組成團(tuán)隊(duì)，項(xiàng)目結(jié)束后釋放所有資源。這種情況下團(tuán)隊(duì)成員缺乏主人翁意識(shí)和產(chǎn)品成就感。

在微服務(wù)架構(gòu)中，提倡采用“產(chǎn)品模式”構(gòu)建，即更傾向于讓團(tuán)隊(duì)負(fù)責(zé)整個(gè)服務(wù)的生命周期，以便提供更優(yōu)質(zhì)的服務(wù)。

4. 技術(shù)多樣性

微服務(wù)架構(gòu)中，提倡針對不同的業(yè)務(wù)特征選擇合適的技術(shù)方案，有針對性的解決具體業(yè)務(wù)問題，而不是像單塊架構(gòu)中采用統(tǒng)一的平臺(tái)或技術(shù)來解決所有問題。

5. 業(yè)務(wù)數(shù)據(jù)獨(dú)立

微服務(wù)架構(gòu)提供自主管理其相關(guān)的業(yè)務(wù)數(shù)據(jù)，這樣可以隨著業(yè)務(wù)的發(fā)展提供數(shù)據(jù)接口集成，而不是以數(shù)據(jù)庫的方式同其他服務(wù)集成。另外，隨著業(yè)務(wù)的發(fā)展，可以方便地選擇更合的工具管理或者遷移業(yè)務(wù)數(shù)據(jù)。

6. 基礎(chǔ)設(shè)施自動(dòng)化

在微服務(wù)架構(gòu)的實(shí)踐過程中，對持續(xù)交付和部署流水線的要求很高，將促進(jìn)企業(yè)不斷尋找更高效的方式完成基礎(chǔ)設(shè)施的自動(dòng)化及 DevOps 運(yùn)維能力的提升。

3

聽完成小胖忍不住表達(dá)了敬佩之意：

“老司機(jī)就是老司機(jī)，噢說錯(cuò)了……架構(gòu)師就是架構(gòu)師，總結(jié)得這么簡潔又深刻！”

“咳咳，低調(diào)低調(diào)……”

“聽您講解了這么多，我覺得微服務(wù)架構(gòu)解決了很多當(dāng)前三層架構(gòu)的痛點(diǎn)。不過我覺得沒有任何一項(xiàng)技術(shù)或架構(gòu)是完美的。”

“非常正確。進(jìn)行微服務(wù)架構(gòu)的落地是存在很多挑戰(zhàn)的?！?/p>

1. 分布式系統(tǒng)的復(fù)雜性

微服務(wù)架構(gòu)是基于分布式的系統(tǒng)，而構(gòu)建分布式系統(tǒng)必然會(huì)帶來額外的開銷。

性能：分布式系統(tǒng)是跨進(jìn)程、跨網(wǎng)絡(luò)的調(diào)用，受網(wǎng)絡(luò)延遲和帶寬的影響。

可靠性：由于高度依賴于網(wǎng)絡(luò)狀況，任何一次的遠(yuǎn)程調(diào)用都有可能失敗，隨著服務(wù)的增多還會(huì)出現(xiàn)更多的潛在故障點(diǎn)。因此，如何提高系統(tǒng)的可靠性、降低因網(wǎng)絡(luò)引起的故障率，是系統(tǒng)構(gòu)建的一大挑戰(zhàn)。

異步：異步通信大大增加了功能實(shí)現(xiàn)的復(fù)雜度，并且伴隨著定位難、調(diào)試難等問題。

數(shù)據(jù)一致性：要保證分布式系統(tǒng)的數(shù)據(jù)強(qiáng)一致性，成本是非常高的，需要在 C（一致性）A（可用性）P（分區(qū)容錯(cuò)性） 三者之間做出權(quán)衡。

2. 運(yùn)維成本

運(yùn)維主要包括配置、部署、監(jiān)控與告警和日志收集四大方面。微服務(wù)架構(gòu)中，每個(gè)服務(wù)都需要獨(dú)立地配置、部署、監(jiān)控和收集日志，成本呈指數(shù)級(jí)增長。

3. 自動(dòng)化部署

在微服務(wù)架構(gòu)中，每個(gè)服務(wù)都獨(dú)立部署，交付周期短且頻率高，人工部署已經(jīng)無法適應(yīng)業(yè)務(wù)的快速變化。因此如何有效地構(gòu)建自動(dòng)化部署體系，是微服務(wù)面臨的另一個(gè)挑戰(zhàn)。

4. DevOps 與組織架構(gòu)

在微服務(wù)架構(gòu)的實(shí)施過程中，開發(fā)人員和運(yùn)維人員的角色發(fā)生了變化，開發(fā)者將承擔(dān)起整個(gè)服務(wù)的生命周期的責(zé)任，包括部署和監(jiān)控；而運(yùn)維則更傾向于顧問式的角色，盡早考慮服務(wù)如何部署。因此，按需調(diào)整組織架構(gòu)、構(gòu)建全功能的團(tuán)隊(duì)，也是一個(gè)不小的挑戰(zhàn)。

5. 服務(wù)間的依賴測試

單塊架構(gòu)中，通常使用集成測試來驗(yàn)證依賴是否正常。而在微服務(wù)架構(gòu)中，服務(wù)數(shù)量眾多，每個(gè)服務(wù)都是獨(dú)立的業(yè)務(wù)單元，服務(wù)主要通過接口進(jìn)行交互，如何保證依賴的正常，是測試面臨的主要挑戰(zhàn)。

6. 服務(wù)間的依賴管理

微服務(wù)架構(gòu)中，服務(wù)數(shù)量眾多，如何清晰有效地展示服務(wù)間的依賴關(guān)系也是個(gè)不小的挑戰(zhàn)。

“微服務(wù)的落地需要經(jīng)過全面的考察和完善的試驗(yàn)，并不是每個(gè)場景都適合使用微服務(wù)架構(gòu)，也不是每個(gè)企業(yè)都有能力或者精力去面對這些挑戰(zhàn)。”

老王最后語重心長的說。

“嗯嗯，每件事都有兩面性，最合適的才是最好的！對了王哥，您已經(jīng)給我上完理論課了，啥時(shí)候帶我實(shí)踐下唄？”

“你先好好消化完今天講的這些，下次再說吧……”

“好吧，很期待我們的下一次交流……”