2.1 微服務(wù)使用場(chǎng)景

2.1.1 項(xiàng)目復(fù)雜度

微服務(wù)架構(gòu)主要解決的問(wèn)題是通過(guò)對(duì)龐大的單體架構(gòu)進(jìn)行服務(wù)拆分，使得服務(wù)更加容易理解和控制。當(dāng)你的業(yè)務(wù)應(yīng)用邏輯本身復(fù)雜度不是很高時(shí)，微服務(wù)架構(gòu)的威力是很難發(fā)揮的，所謂“殺雞焉用宰牛刀”。

下圖揭示了微服務(wù)架構(gòu)與單體架構(gòu)的復(fù)雜度與生產(chǎn)力的關(guān)系。

在項(xiàng)目復(fù)雜度較小時(shí)，采用單體架構(gòu)的生產(chǎn)力更高；復(fù)雜度到了一定規(guī)模時(shí)，單體架構(gòu)的生產(chǎn)力開(kāi)始急劇下降，這時(shí)對(duì)其進(jìn)行微服務(wù)化的拆分才是合算的。復(fù)雜度和生產(chǎn)力雖然存在拐點(diǎn)，但并沒(méi)有量化復(fù)雜度的拐點(diǎn)，或者說(shuō)沒(méi)有明確系統(tǒng)或代碼庫(kù)的規(guī)模達(dá)到具體多大時(shí)才更加適合開(kāi)始進(jìn)行微服務(wù)化的拆分。

團(tuán)隊(duì)決定構(gòu)建一個(gè)微服務(wù)項(xiàng)目時(shí)，需要根據(jù)項(xiàng)目的復(fù)雜度判斷是否有必要采用微服務(wù)架構(gòu)，因?yàn)槲⒎?wù)本身也會(huì)給系統(tǒng)帶來(lái)非業(yè)務(wù)功能的復(fù)雜性，所以在轉(zhuǎn)型微服務(wù)時(shí)要慎重考慮。大多數(shù)采用微服務(wù)架構(gòu)的場(chǎng)景還是單體架構(gòu)的改造，這是業(yè)務(wù)開(kāi)發(fā)人員在巨石型應(yīng)用帶給團(tuán)隊(duì)極大困擾之后的一個(gè)自然選擇。這個(gè)項(xiàng)目階段往往就是所謂的項(xiàng)目復(fù)雜度與生產(chǎn)力的“拐點(diǎn)”時(shí)期，對(duì)單體架構(gòu)進(jìn)行合理的服務(wù)拆分是實(shí)施微服務(wù)架構(gòu)的一大前提，在后續(xù)的章節(jié)中，我們會(huì)進(jìn)一步詳細(xì)講解服務(wù)拆分的依據(jù)和策略。

Martin Fowler曾經(jīng)說(shuō)過(guò)：“……除非你的系統(tǒng)復(fù)雜到難以管理的程度，否則不要考慮采用微服務(wù)……”微服務(wù)架構(gòu)需要額外的開(kāi)銷，比如服務(wù)設(shè)計(jì)、服務(wù)通信、服務(wù)管理和系統(tǒng)資源。采用微服務(wù)是有代價(jià)的，如果一個(gè)應(yīng)用程序無(wú)法充分利用微服務(wù)的優(yōu)勢(shì)，那么采用微服務(wù)反而得不償失。所以，在我們采用微服務(wù)之前，首先需要做一個(gè)很好的權(quán)衡，需要明白使用微服務(wù)的驅(qū)動(dòng)力是否充足；業(yè)務(wù)是否復(fù)雜到需要借助微服務(wù)拆分來(lái)解決問(wèn)題，以快速響應(yīng)變化。

2.1.2 團(tuán)隊(duì)規(guī)模

微服務(wù)架構(gòu)非常適合大型項(xiàng)目團(tuán)隊(duì)。對(duì)于大型項(xiàng)目，《人月神話》中的“人月互換理論”已經(jīng)證明是失敗的，這種方式往往忽略了溝通的成本。正如著名的“兩個(gè)比薩原則”：如果兩個(gè)比薩不足以喂飽一個(gè)項(xiàng)目團(tuán)隊(duì)，那么這個(gè)團(tuán)隊(duì)可能就顯得太大了。

然而，對(duì)于小型的項(xiàng)目團(tuán)隊(duì)或者只有少數(shù)開(kāi)發(fā)人員維護(hù)的系統(tǒng)，其實(shí)是沒(méi)有必要使用微服務(wù)架構(gòu)的。單體架構(gòu)的簡(jiǎn)單性有助于簡(jiǎn)化團(tuán)隊(duì)成員的工作，并且可以將系統(tǒng)的復(fù)雜度控制在一定范圍內(nèi)。使用微服務(wù)架構(gòu)會(huì)增加組織的溝通成本，模塊之間的跨網(wǎng)絡(luò)交互也會(huì)給開(kāi)發(fā)和運(yùn)維帶來(lái)額外的成本，將本來(lái)簡(jiǎn)單的事情復(fù)雜化。

所以，在實(shí)施微服務(wù)架構(gòu)前，首先請(qǐng)關(guān)注你的團(tuán)隊(duì)規(guī)模。在人力資源有限的情況下，其實(shí)并不推薦使用微服務(wù)架構(gòu)，因?yàn)槿绻愕墓緵](méi)有像亞馬遜、Netflix這樣的技術(shù)儲(chǔ)備和平臺(tái)儲(chǔ)備，微服務(wù)架構(gòu)反而會(huì)增加系統(tǒng)的復(fù)雜度，進(jìn)而帶來(lái)一系列問(wèn)題，讓你懷念單體架構(gòu)帶給你的簡(jiǎn)單性。

2.1.3 變更頻率

2016年，Gartner發(fā)布了關(guān)于應(yīng)用變化速度的報(bào)告“Pace-Layered Application Strategy”，該報(bào)告以變化速度為標(biāo)準(zhǔn)將業(yè)務(wù)應(yīng)用分為三層。

● SOI（Systems of Innovation，敏態(tài)業(yè)務(wù)）：比如互聯(lián)網(wǎng)業(yè)務(wù)，需求變更快，要求快速迭代、快速交付。

● SOR（Systems of Record，穩(wěn)態(tài)業(yè)務(wù)）：比如傳統(tǒng)業(yè)務(wù)，變更周期長(zhǎng)、變化頻率低、變化成本高、變化風(fēng)險(xiǎn)高。

● SOD（Systems of Differentiation，中臺(tái)業(yè)務(wù)）：解決前后端的開(kāi)發(fā)速度匹配失衡問(wèn)題，中臺(tái)為前臺(tái)與后臺(tái)之間添加的一組“變速齒輪”。

對(duì)于新興行業(yè)中的敏態(tài)業(yè)務(wù)，它們需要有更加動(dòng)態(tài)化和更快的響應(yīng)，服務(wù)往往需要更快的交付速度和更加頻繁的版本發(fā)布。微服務(wù)架構(gòu)的一個(gè)顯著優(yōu)勢(shì)，就是對(duì)變化的快速響應(yīng)。微服務(wù)架構(gòu)相比單體架構(gòu)更加獨(dú)立，所以在快速開(kāi)發(fā)、持續(xù)集成、持續(xù)交付上有更明顯的優(yōu)勢(shì)。另外，微服務(wù)架構(gòu)強(qiáng)調(diào)使用標(biāo)準(zhǔn)、輕量級(jí)的通信協(xié)議進(jìn)行服務(wù)交互，契合中臺(tái)作為集成前、后臺(tái)資源的業(yè)務(wù)形態(tài)。所以從業(yè)務(wù)形態(tài)和服務(wù)的交付頻率上說(shuō)，微服務(wù)比較適合在SOI和SOD的場(chǎng)景中應(yīng)用。

傳統(tǒng)的穩(wěn)態(tài)業(yè)務(wù)，比如大型的電信項(xiàng)目、銀行項(xiàng)目，本身周期比較長(zhǎng)，變化頻率相對(duì)較低，我們不需要遷移到微服務(wù)架構(gòu)，而是最好保持它目前的運(yùn)行狀態(tài)。

我們可以借助工具來(lái)檢查哪些項(xiàng)目的變更頻率比較快，可以利用GitLab這樣的工具統(tǒng)計(jì)項(xiàng)目代碼的提交次數(shù)和構(gòu)建頻率，以便決定哪些項(xiàng)目需要進(jìn)行微服化改造。還可以使用源代碼管理系統(tǒng)來(lái)查看代碼的活躍度。以Git存儲(chǔ)庫(kù)為例，可以使用常用的Linux工具，通過(guò)幾個(gè)命令行選項(xiàng)來(lái)運(yùn)行Git日志。例如，我們可以使用命令生成提交次數(shù)最多的“前十個(gè)代碼文件列表”。此外，也可以利用全新的“代碼鑒定”工具（比如CodeScene）深入了解項(xiàng)目，CodeScene可以識(shí)別代碼中的熱點(diǎn)，幫助我們找出代碼活躍區(qū)域。

2.1.4 項(xiàng)目類型

從來(lái)沒(méi)有一種架構(gòu)模式適用于所有業(yè)務(wù)形態(tài)。目前企業(yè)內(nèi)部還有很多對(duì)性能有嚴(yán)苛要求的系統(tǒng)運(yùn)行在單體架構(gòu)之上。雖然單體架構(gòu)存在諸多缺點(diǎn)，但是單體架構(gòu)內(nèi)的各個(gè)組件之間的交互更加簡(jiǎn)單，內(nèi)部的方法調(diào)用更加高效。對(duì)I/O性能要求比較高的實(shí)時(shí)計(jì)算系統(tǒng)或者嵌入式系統(tǒng)，往往關(guān)注服務(wù)的延遲和服務(wù)的吞吐性能。

相比單體架構(gòu)，在完成相同功能的情況下，微服務(wù)架構(gòu)可能需要經(jīng)過(guò)更多的網(wǎng)絡(luò)交互調(diào)用，而遠(yuǎn)程調(diào)用勢(shì)必增加系統(tǒng)在網(wǎng)絡(luò)上的I/O延遲和花費(fèi)在網(wǎng)絡(luò)上的數(shù)據(jù)傳輸處理時(shí)間。所以，對(duì)性能敏感的項(xiàng)目，微服務(wù)架構(gòu)對(duì)系統(tǒng)造成的性能影響顯然是無(wú)法被接受的。

另外，微服務(wù)架構(gòu)更適合處理OLTP（On-Line Transaction Processing，聯(lián)機(jī)事務(wù)處理）類型的項(xiàng)目，而不擅長(zhǎng)處理OLAP（On-Line Analytical Processing，聯(lián)機(jī)數(shù)據(jù)處理）類型的項(xiàng)目。大數(shù)據(jù)處理中使用比較廣泛的架構(gòu)是Lambda和Kappa等，以及Hadoop技術(shù)。

2.1.5 遺留系統(tǒng)遷移

在生產(chǎn)環(huán)境中，我們有大量的遺留系統(tǒng)。我們可以通過(guò)逐漸改進(jìn)和演變的方式實(shí)現(xiàn)遺留系統(tǒng)向微服務(wù)架構(gòu)的遷移。

遺留系統(tǒng)是否要遷移到微服務(wù)架構(gòu)是一個(gè)戰(zhàn)略問(wèn)題，你需要甄別遺留系統(tǒng)是否適合采用微服務(wù)架構(gòu)。

在戰(zhàn)術(shù)層面，你需要制定詳細(xì)的改造遷移策略，如功能剝離、灰度替換、數(shù)據(jù)解耦、數(shù)據(jù)同步、滾動(dòng)發(fā)布等。如果你正在面對(duì)一個(gè)遺留系統(tǒng)的微服務(wù)改造項(xiàng)目，那么無(wú)論它的原始設(shè)計(jì)多么隨意，無(wú)論它現(xiàn)在變得多么糟糕，在把它重構(gòu)成微服務(wù)之前，都要認(rèn)真仔細(xì)地思考一下，它正處在軟件生命周期的什么階段？它是一個(gè)任務(wù)關(guān)鍵型系統(tǒng)嗎（比如包含了一個(gè)不可替代的遺留數(shù)據(jù)庫(kù)）？你需要多長(zhǎng)時(shí)間來(lái)替換整個(gè)系統(tǒng)？更新或者替換過(guò)程需要一個(gè)長(zhǎng)期詳盡的計(jì)劃嗎？

微服務(wù)架構(gòu)在更新或替換遺留系統(tǒng)方面扮演著重要的角色，沒(méi)有策略指引的遷移很可能會(huì)造成災(zāi)難性的后果。在后續(xù)的微服務(wù)構(gòu)建相關(guān)章節(jié)中，我們會(huì)講解常見(jiàn)的微服務(wù)改造模式。