軟件產(chǎn)品架構(gòu)是不斷迭代演化的，從單體服務(wù)架構(gòu)發(fā)展到現(xiàn)在的服務(wù)化、微服務(wù)的架構(gòu)。

單體架構(gòu)

單體架構(gòu)就是所有的業(yè)務(wù)模塊都是耦合在一個(gè)項(xiàng)目中，開發(fā)、部署都在一起；如果其中一個(gè)模塊需要上線升級(jí)，那么所有模塊都要一起啟停；

在早期，單體架構(gòu)的項(xiàng)目團(tuán)隊(duì)成員需要是“全棧”，因?yàn)榍岸?、后端、?shù)據(jù)庫都是一波人負(fù)責(zé)，后來開始進(jìn)行了邏輯分層，團(tuán)隊(duì)也分成了前端 UI 團(tuán)隊(duì)、后端和 DBA 團(tuán)隊(duì)，每個(gè)團(tuán)隊(duì)都有自己負(fù)責(zé)的職責(zé)。

然而隨著業(yè)務(wù)邏輯越來越復(fù)雜，模塊和模塊之間的耦合度越來越高；另外隨著用戶和數(shù)據(jù)量的增多，單體架構(gòu)也不再能夠支撐高并發(fā)和大數(shù)據(jù)。

SOA 架構(gòu)

為了解決上面的問題，SOA 出現(xiàn)了。

SOA 代表了面向服務(wù)的架構(gòu)，SOA 將應(yīng)用程序的業(yè)務(wù)模塊進(jìn)行拆分，形成獨(dú)立的應(yīng)用系統(tǒng)，系統(tǒng)和系統(tǒng)之間通過明確的接口串聯(lián)起來；

每個(gè)系統(tǒng)內(nèi)部結(jié)構(gòu)和邏輯發(fā)生改變，并不影響對(duì)外提供的服務(wù)，只要保持接口不變，服務(wù)內(nèi)部對(duì)外是透明的；

SOA 架構(gòu)中，服務(wù)定義標(biāo)注的接口，可以提供給多個(gè)調(diào)用方使用，增加了服務(wù)的重用性。

SOA 架構(gòu)時(shí)代有兩個(gè)很重要技術(shù)實(shí)現(xiàn)方式：Web Service 和 ESB ：前者提供了標(biāo)準(zhǔn)的數(shù)據(jù)傳輸協(xié)議，后者實(shí)現(xiàn)了服務(wù)編排和協(xié)議轉(zhuǎn)換。

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

但是隨著用戶和數(shù)據(jù)量的進(jìn)一步增長，SOA 也暴露出來一些缺點(diǎn)，比如 SOAP 協(xié)議、XML較重；服務(wù)管理不完善；ESB本身就比較重，而且它本身算是一個(gè)單點(diǎn)，在軟件架構(gòu)中，單點(diǎn)意味著風(fēng)險(xiǎn)。

在微服務(wù)的架構(gòu)中，各個(gè)微服務(wù)可以獨(dú)立開發(fā)，獨(dú)立部署；微服務(wù)之間通常使用Restful風(fēng)格的API通信，傳輸格式也通常選擇JSON；

微服務(wù)是SOA架構(gòu)的延續(xù)，它們和單體應(yīng)用相比，大大提高了系統(tǒng)的負(fù)載能力，解決了應(yīng)用高并發(fā)的需求；

服務(wù)和服務(wù)之間的耦合度也被降低，并且項(xiàng)目團(tuán)隊(duì)可以被拆分成多個(gè)小團(tuán)隊(duì)，每個(gè)微服務(wù)都可以進(jìn)行敏捷開發(fā)部署；

每個(gè)團(tuán)隊(duì)的技術(shù)棧也可以不相同，只要遵守接口協(xié)議即可。

至于微服務(wù)和 SOA 架構(gòu)的區(qū)別，我是這樣理解的：SOA 架構(gòu)和微服務(wù)架構(gòu)都屬于分布式架構(gòu)，分布式的思想就是把不同的業(yè)務(wù)模塊，部署在不同的服務(wù)器上，以應(yīng)對(duì)高并發(fā)的問題；SOA 是一種分布式架構(gòu)，把業(yè)務(wù)系統(tǒng)分成多個(gè)子系統(tǒng)，提供不同的服務(wù)，再通過服務(wù)組合、編排實(shí)現(xiàn)業(yè)務(wù)流程；微服務(wù)是SOA的升華，如果非要說點(diǎn)兒不同的，那么微服務(wù)更加強(qiáng)調(diào)服務(wù)的細(xì)分和專業(yè)，去ESB總線、去中心化，部署粒度更細(xì)，服務(wù)擴(kuò)展更靈活。

當(dāng)然SOA、微服務(wù)的出現(xiàn)，在解決一些問題的時(shí)候，也帶來了另外一部分的問題，比如增加了網(wǎng)絡(luò)開銷、服務(wù)依賴性、增加了測(cè)試運(yùn)維難度、數(shù)據(jù)一致性問題等等。

我將持續(xù)分享Java開發(fā)、架構(gòu)設(shè)計(jì)、程序員職業(yè)發(fā)展等方面的見解，希望能得到你的關(guān)注。

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

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

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

一、單體架構(gòu)

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

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

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

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

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

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

• 規(guī)?；簾o法滿足團(tuán)隊(duì)規(guī)?；咝ч_發(fā)。

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

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

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

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

單體適用場(chǎng)景：

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

　　對(duì)于項(xiàng)目起步階段，單體是最高效也是最節(jié)省成本的方式。因?yàn)槌跗陔A段，由于人力，成本，業(yè)務(wù)熟悉程度，微服務(wù)技術(shù)積累等因素，如何過度設(shè)計(jì)可能工期和復(fù)雜度會(huì)急劇上升，造成交付困難，問題百出，從而錯(cuò)過了時(shí)間窗口。最合適，簡(jiǎn)單的方式還是單體優(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ù)量不大，僅限于省級(jí)范圍，建議只要對(duì)當(dāng)前架構(gòu)稍加改良升級(jí)就可以了，這樣改動(dòng)量相對(duì)較小，且至少能支撐一定時(shí)間段的業(yè)務(wù)增長。

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

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

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

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

• 技術(shù)門檻高：微服務(wù)包括，服務(wù)描述，注冊(cè)中心，服務(wù)框架，服務(wù)監(jiān)控，服務(wù)追蹤，服務(wù)治理等幾大基本組件，以上每個(gè)組件缺一不可，每個(gè)組件展開又包括很多技術(shù)門檻，比如，容器技術(shù)，持續(xù)部署，DevOps等相關(guān)概念。
• 復(fù)雜性增加：相對(duì)單體架構(gòu)將所有功能打包部署在一起，集中地進(jìn)行開發(fā)、測(cè)試和運(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ù)的升級(jí)，更是開發(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ù)多帶帶抽離出來分析。

　　這邊的架構(gòu)圖譜相對(duì)之前的架構(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ù)注冊(cè)，發(fā)現(xiàn)，認(rèn)證授權(quán)，單點(diǎn)登錄，熔斷，限流……網(wǎng)關(guān)的知識(shí)點(diǎn)豐富，是微服務(wù)的核心之一。

• 假如網(wǎng)關(guān)對(duì)外提供統(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ù)總線，事件總線相對(duì)比較輕量，經(jīng)?；谙㈥?duì)列引擎進(jìn)行解耦，目的是為了讓服務(wù)之間的關(guān)聯(lián)弱化，不直接進(jìn)行關(guān)聯(lián)。很多時(shí)候用的是相對(duì)穩(wěn)定、可靠、企業(yè)級(jí)的RabbitMQ。

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

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

3.1楊波說

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

　　“企業(yè)一開始不推薦直接使用微服務(wù)，因?yàn)槲⒎?wù)需要前期基礎(chǔ)設(shè)施的投資，復(fù)雜性很高，如果對(duì)問題領(lǐng)域并不是很理解，一開始用微服務(wù)，你很難去劃分服務(wù)的邊界，你的生產(chǎn)力反而會(huì)比較低，而且你花了很大精力進(jìn)行開發(fā)，你的產(chǎn)品并沒有被市場(chǎng)驗(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)?！?/p>

　　“交叉點(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ù)?！?/p>

　　以上的觀點(diǎn)講的很中肯，給我的啟發(fā)和幫助非常大。這里的交叉點(diǎn)怎么來確定和評(píng)估是重點(diǎn)，比如我們上線一個(gè)社交姑且叫抖信，初期為了快速上線，驗(yàn)證可行性，可以只開發(fā)首頁聊天、通訊錄、評(píng)論等基本功能。產(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ā)、測(cè)試和部署的話，就會(huì)導(dǎo)致不同功能之間相互影響，一次打包部署需要所有的功能都測(cè)試 OK 才能上線。

　　不僅如此，多個(gè)功能模塊混部在一起，對(duì)線上服務(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ù)雜度和市場(chǎng)窗口是權(quán)衡和抉擇的首要因素。

3.2微服務(wù)落地條件評(píng)估

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

3.2.1落地方式選擇

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

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

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

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

3.2.2人才儲(chǔ)備

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

3.2.3技術(shù)儲(chǔ)備

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

3.2.4團(tuán)隊(duì)規(guī)模評(píng)估

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

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

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

　　業(yè)務(wù)規(guī)模：如果你們的業(yè)務(wù)架構(gòu)非常復(fù)雜，有倉儲(chǔ)系統(tǒng)開發(fā)，ERP系統(tǒng)，OA系統(tǒng)，訂單系統(tǒng)等等，業(yè)務(wù)越多，需求人數(shù)越多(這里人數(shù)指的都是后臺(tái)開發(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è)人兩周就夠了，也可能高級(jí)開發(fā)2個(gè)人，一人分工三個(gè)核心組件，兩周也夠用。或者架構(gòu)外包，只要交接的人能跟上，也是一種解決方案。

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

3.3轉(zhuǎn)微服務(wù)風(fēng)險(xiǎn)評(píng)估

3.3.1重寫面廣

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

3.3.2復(fù)雜度高

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

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

3.3.3人員配置

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

3.3.4合作方式

　　如果采用借助外部架構(gòu)力量來助推架構(gòu)升級(jí)，和架構(gòu)單位的合作就不是簡(jiǎn)單的外包，涉及的面會(huì)變得比較廣，在完全交接過來之前，周期會(huì)比較長。包括對(duì)我們業(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)的升級(jí)，當(dāng)然這種升級(jí)是平滑過度的，對(duì)業(yè)務(wù)窗口并不會(huì)產(chǎn)生影響。

3.4合理的拆分姿勢(shì)

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

3.4.1縱向拆分

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

3.4.2橫向拆分

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

3.4.3總結(jié)

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

四、SOA和微服務(wù)

　　由于SOA和微服務(wù)有千絲萬縷的關(guān)系，這里簡(jiǎn)單羅列雙方的對(duì)比圖，算是一個(gè)小知識(shí)點(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ì)的原則上，遵循簡(jiǎn)單，適用，演化的原則，那么你的抉擇也許會(huì)變得沒有那么令人糾纏。

文章引用

• 從單體式架構(gòu)遷移到微服務(wù)架構(gòu)
• 《微服務(wù)設(shè)計(jì)》作者: [英] Sam Newman 出版社: 人民郵電出版社
• 4 Challenges You Need to Address with Microservices Adoption
• 為什么使用微服務(wù)？

單體架構(gòu)

在傳統(tǒng)IT行業(yè)的軟件系統(tǒng)設(shè)計(jì)大多都是各種獨(dú)立子系統(tǒng)的堆砌，這也就是所說的單體架構(gòu)，其本身擴(kuò)展性差，可靠性低，維護(hù)成本高。單體架構(gòu)在初期系統(tǒng)規(guī)模比較小的情況下尚且能夠較好的支撐，但是隨著系統(tǒng)規(guī)模的擴(kuò)大，它暴露出來的問題也越來越多，主要有以下幾點(diǎn)：

• 復(fù)雜性逐漸變高，問題修復(fù)和新功能開發(fā)難度和成本高，引入新問題的可能性變大。同時(shí)，任意模塊的缺陷都可能會(huì)影響整個(gè)系統(tǒng)，可靠性低。
  
• 隨著人員流動(dòng)，加之復(fù)雜性高，新的問題很難被發(fā)現(xiàn)和解決，久而久之，問題逐漸變多，變難、變大，技術(shù)債務(wù)逐漸上升。
  
• 隨著模塊不斷集成，部署速度逐漸變慢
  
• 想進(jìn)行整體的技術(shù)創(chuàng)新基本不可能，阻礙技術(shù)創(chuàng)新
  
• 垂直和水平的可擴(kuò)展性差
  

SOA架構(gòu)

隨后，引入了SOA服務(wù)化（面向服務(wù)的架構(gòu)，它將應(yīng)用程序的不同功能單元（服務(wù)）進(jìn)行拆分，并通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來)。但是，由于 SOA 早期均使用了ESB總線模式，這種總線模式與某種技術(shù)棧是強(qiáng)綁定的，如，J2EE。這又使得很多企業(yè)的遺留系統(tǒng)很難對(duì)接，切換時(shí)間太長，對(duì)接成本太高，新系統(tǒng)穩(wěn)定性的收斂也需要一些時(shí)間。最終 SOA 看起來很美，但卻成為了企業(yè)級(jí)奢侈品，中小公司都望而生畏。

SOA服務(wù)化思想下的微服務(wù)架構(gòu)

微服務(wù)是在 SOA 上做的升華，微服務(wù)最早由Martin Fowler與James Lewis于2014年共同提出，微服務(wù)架構(gòu)風(fēng)格是一種使用一套小服務(wù)來開發(fā)單個(gè)應(yīng)用的方式途徑，每個(gè)服務(wù)運(yùn)行在自己的進(jìn)程中，并使用輕量級(jí)機(jī)制通信，通常是HTTP Rest API的方式（告別ESB服務(wù)總線），這些服務(wù)基于業(yè)務(wù)能力構(gòu)建，并能夠通過自動(dòng)化部署機(jī)制來獨(dú)立部署，這些服務(wù)使用不同的編程語言實(shí)現(xiàn)，以及不同數(shù)據(jù)存儲(chǔ)技術(shù)，并保持最低限度的集中式管理。

簡(jiǎn)單講，微服務(wù)不再強(qiáng)調(diào)傳統(tǒng)SOA架構(gòu)里面比較重的ESB服務(wù)總線，同時(shí)將SOA的思想延伸到單個(gè)業(yè)務(wù)系統(tǒng)內(nèi)部實(shí)現(xiàn)真正的組件化。微服務(wù)架構(gòu)強(qiáng)調(diào)的一個(gè)重點(diǎn)是“業(yè)務(wù)需要徹底的組件化和服務(wù)化”。

從微服務(wù)的概念可以看出它有如下好處：

• 每個(gè)服務(wù)可以獨(dú)立開發(fā)，易于開發(fā)，提高開發(fā)人員的生產(chǎn)效率
  
• 局部修改容易部署
  
• 技術(shù)棧不受限
  
• 單個(gè)服務(wù)支持獨(dú)立部署和發(fā)布，可以進(jìn)行快速迭代部署，更快的交付時(shí)間
  
• 更有利于業(yè)務(wù)的擴(kuò)展，可伸縮性強(qiáng)

轉(zhuǎn)自 @軟件測(cè)試開發(fā)技術(shù)棧 ，希望對(duì)您有所幫助。

單體架構(gòu)：

單體機(jī)構(gòu)是指在軟件設(shè)計(jì)中使用經(jīng)典的 3 層模型，即表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層。雖然在設(shè)計(jì)中劃分了 3 層模型，但是對(duì)業(yè)務(wù)場(chǎng)景沒有劃分。一個(gè)典型的單體應(yīng)用就是將所有的業(yè)務(wù)場(chǎng)景的表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層放在一個(gè)工程中，最終經(jīng)過編譯、打包，部署在一臺(tái)服務(wù)器上。

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

1. 易于開發(fā): 單體應(yīng)用程序開發(fā)相對(duì)簡(jiǎn)單，容易理解，單個(gè)程序員可以完成業(yè)務(wù)接口到數(shù)據(jù)庫的整個(gè)流程。
2. 部署簡(jiǎn)單: 由于是完整的結(jié)構(gòu)體，可以直接部署在一個(gè)服務(wù)器上即可。
3. 技術(shù)單一: 項(xiàng)目不需要復(fù)雜的技術(shù)棧，往往一套熟悉的技術(shù)棧就可以完成開發(fā)。

缺點(diǎn)：

1. 開發(fā)成本高：代碼重復(fù)率高，需求變更困難，無法滿足新業(yè)務(wù)快速上線和敏捷交付。
2. 系統(tǒng)穩(wěn)定性差：任何一個(gè)模塊的錯(cuò)誤均可能造成整個(gè)系統(tǒng)的宕機(jī);
3. 擴(kuò)展能力受限：系統(tǒng)的擴(kuò)容只能只對(duì)這個(gè)應(yīng)用進(jìn)行擴(kuò)容，不能做到對(duì)某個(gè)功能點(diǎn)進(jìn)行擴(kuò)容，關(guān)鍵性的代碼改動(dòng)一處多處會(huì)受影響。

SOA架構(gòu):

SOA架構(gòu)即面向服務(wù)架構(gòu)，是一種粗粒度、松耦合服務(wù)架構(gòu)?；赟OA服務(wù)思想進(jìn)行功能的抽取，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來，以服務(wù)為中心各個(gè)系統(tǒng)之間依靠ESB企業(yè)服務(wù)總線進(jìn)行調(diào)用，這使得構(gòu)件在各種各樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進(jìn)行交互。

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

1. 敏捷性：可以直接利用現(xiàn)有的資源進(jìn)行組合，讓后在按照自己的客戶需求，進(jìn)行進(jìn)一步的開發(fā)。
2. 擴(kuò)展性：可以更具不同的需求，進(jìn)行重新的組合和構(gòu)造。
3. 易維護(hù)：服務(wù)的提供者和使用者是松耦合關(guān)系，開放標(biāo)準(zhǔn)接口的采用，使其具有很好的維護(hù)性和可用性。

缺點(diǎn)：

1. 開發(fā)難度: 架構(gòu)設(shè)計(jì)、服務(wù)抽取、接口設(shè)計(jì)等問題，考驗(yàn)著領(lǐng)導(dǎo)者和開發(fā)人員過硬的技術(shù)能力。
2. 數(shù)據(jù)統(tǒng)一：存在“臟數(shù)據(jù)”相關(guān)問題，處理一致性是設(shè)計(jì)服務(wù)接口面臨的巨大挑戰(zhàn)之一。

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

微服務(wù)架構(gòu)是把一個(gè)大型的單個(gè)應(yīng)用程序和服務(wù)拆分為多個(gè)的微服務(wù)，每個(gè)微服務(wù)僅關(guān)注并很好的完成一件任務(wù)。它的主要作用是將功能分解到離散的各個(gè)服務(wù)當(dāng)中，從而降低系統(tǒng)的耦合性，并提供更加靈活的服務(wù)支持。

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

1. 獨(dú)立性：是每個(gè)微服務(wù)組件都是簡(jiǎn)單靈活的，能夠獨(dú)立部署。
2. 可擴(kuò)展性：微服務(wù)之間是松耦合的，微服務(wù)內(nèi)部是高內(nèi)聚的，每個(gè)微服務(wù)很容易按需擴(kuò)展，產(chǎn)品迭代周期更短。
3. 隔離性：每個(gè)微服務(wù)都是獨(dú)立的運(yùn)行，任何一個(gè)或者多個(gè)微服務(wù)的失敗只影響自己或者少量其他微服務(wù)，而不會(huì)大面積地波及整個(gè)服務(wù)運(yùn)行體系。

缺點(diǎn)：

1. 復(fù)雜性：開發(fā)的復(fù)雜性增加，因?yàn)橐粋€(gè)業(yè)務(wù)流程需要多個(gè)微服務(wù)通過網(wǎng)絡(luò)交互來完成。
2. 服務(wù)治理：微服務(wù)過多，服務(wù)治理成本高，不利于系統(tǒng)維護(hù)。

其實(shí)，這三者到現(xiàn)在來說未必是那樣經(jīng)緯分明、非此即彼，很多基于微服務(wù)的單體架構(gòu)應(yīng)用、結(jié)合分布式的SOA云服務(wù)總線來實(shí)現(xiàn)線上線下集成、內(nèi)部跟外部集成、構(gòu)建柔韌的企業(yè)IT架構(gòu)、滿足業(yè)務(wù)的變化、推動(dòng)業(yè)務(wù)創(chuàng)新和變革，是軟件架構(gòu)不斷優(yōu)化、變遷、提升的源動(dòng)力。

數(shù)通暢聯(lián)專注于企業(yè)IT架構(gòu)、SOA綜合集成、數(shù)據(jù)治理分析領(lǐng)域，感謝您的閱讀與關(guān)注

一圖了解什么是單體架構(gòu)、SOA架構(gòu)、微服務(wù)架構(gòu)

分別從三個(gè)維度來展示：

1、軟件過程維度

單體架構(gòu)通常采用瀑布模型開發(fā)；

SOA架構(gòu)通常采用敏捷/XP編程模式；

微服務(wù)架構(gòu)采用DevOps，使用IT交付流水線來全自動(dòng)管理；

2、從架構(gòu)維度

單體架構(gòu)通常采用巨石結(jié)構(gòu)，不易維護(hù)；

SOA架構(gòu)通常以服務(wù)的方式對(duì)外連接，常見的支撐平臺(tái)有ESB企業(yè)服務(wù)總線進(jìn)行服務(wù)貫通；

微服務(wù)架構(gòu)采用更細(xì)的拆分模式，每個(gè)獨(dú)立的模塊有多帶帶的數(shù)據(jù)庫、運(yùn)行環(huán)境，在業(yè)務(wù)上完成一個(gè)具體的功能；

3、從部署形態(tài)維度

單體架構(gòu)早期多運(yùn)行在物理機(jī)中，當(dāng)然后期也可以運(yùn)行在虛擬化資源中；

SOA架構(gòu)多運(yùn)行在虛擬化/IAAS平臺(tái)上；

微服務(wù)架構(gòu)目前多運(yùn)行在容器平臺(tái)上（當(dāng)然也可以運(yùn)行在虛擬化資源和物理機(jī)中，這種情況享受不到容器帶來的便利性）；

單體架構(gòu)

* 一個(gè)典型的單體應(yīng)用就是將所有的業(yè)務(wù)場(chǎng)景的表示層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層放在一個(gè)工程中，最終經(jīng)過編譯、打包，部署在一臺(tái)服務(wù)器上。

`例如：典型的J2EE工程，它是將表示層的JSP、業(yè)務(wù)邏輯層的Service、Controller和數(shù)據(jù)訪問層的Dao，打成war包，部署在Tomcat、Jetty或者其他Servlet容器中運(yùn)行`

SOA架構(gòu)

* SOA架構(gòu)是面向服務(wù)的體系結(jié)構(gòu)，主要目的是為了各個(gè)系統(tǒng)更加容易地融合在一起。

`例如：以購物商城為例，由于功能模塊越來越多，系統(tǒng)非常臃腫所有對(duì)系統(tǒng)進(jìn)行橫向拆分，各個(gè)服務(wù)之間彼此相對(duì)獨(dú)立，通過服務(wù)治理框架進(jìn)行服務(wù)之間的通信以及管理，常用的服務(wù)治理框架有：dubbo、dubbox等`

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

微服務(wù)是將一個(gè)大型復(fù)雜軟件應(yīng)用由一個(gè)或多個(gè)微服務(wù)組成。系統(tǒng)中的各個(gè)微服務(wù)可被獨(dú)立部署，各個(gè)微服務(wù)之間是松耦合的。每個(gè)微服務(wù)僅關(guān)注于完成一件任務(wù)并很好地完成該任務(wù)。在所有情況下，每個(gè)任務(wù)代表著一個(gè)小的業(yè)務(wù)模塊。

我在低代碼開發(fā)平臺(tái)領(lǐng)域中接觸最多的就是微服務(wù)架構(gòu)，微服務(wù)是指開發(fā)一個(gè)單個(gè) 小型的但有業(yè)務(wù)功能的服務(wù),每個(gè)服務(wù)都有自己的處理和輕量通訊機(jī)制,可以部署在單個(gè)或多個(gè)服務(wù)器上，而且部署方式也有多種，集群部署，雙機(jī)部署，單機(jī)部署等等，天翎的myapps平臺(tái)就是一個(gè)很好的例子，可以去了解一下這個(gè)架構(gòu)，是三種架構(gòu)里面使用得比較多也比較方便的軟件產(chǎn)品架構(gòu)

表面上看這是一個(gè)大問題。

實(shí)質(zhì)有內(nèi)聯(lián)關(guān)系。

你可以把一個(gè)單體架構(gòu)的應(yīng)用看作是一大整塊豆腐。

SOA架構(gòu)就是豆腐切塊了。

微服務(wù)架構(gòu)就是豆腐切塊了之后又切成豆腐丁了。

大塊有大塊的好處，小塊有小塊的好處。

這里的利弊就是你打算怎么個(gè)做法能吃起來更可口。

應(yīng)用切分到微服務(wù)也并不是絕對(duì)的好。

技術(shù)架構(gòu)細(xì)分也是軟件細(xì)化分工的一種體現(xiàn)。

僅此而已。