作者 | Martin Fowler

當(dāng)聽說有團(tuán)隊(duì)在使用微服務(wù)架構(gòu)時(shí)候，我注意到了一些規(guī)律：

• 幾乎所有成功應(yīng)用微服務(wù)的系統(tǒng)，都來自于一個(gè)過大單體項(xiàng)目拆分而來。
• 幾乎所有我聽到過一開始就選擇使用微服務(wù)架構(gòu)的系統(tǒng)，并從 0 構(gòu)建，最終的結(jié)果都有一系列嚴(yán)重的麻煩。

這些規(guī)律在我同事中產(chǎn)生了長(zhǎng)期的討論：你不應(yīng)該在新項(xiàng)目之初就采用微服務(wù)架構(gòu)，即使你堅(jiān)信該應(yīng)用未來會(huì)因業(yè)務(wù)演進(jìn)而變得巨大無比。

微服務(wù)是一種有用的架構(gòu)，但是即使是這種架構(gòu)的擁躉也不得不承認(rèn)，使用這種架構(gòu)需要付出額外的成本，這意味者只有更復(fù)雜的系統(tǒng)值得使用這種架構(gòu)。這種代價(jià)的本質(zhì)是管理這些服務(wù)所帶來的基本開銷。所以這就是單體優(yōu)先架構(gòu)策略的依據(jù)， 架構(gòu)師應(yīng)在構(gòu)建新系統(tǒng)時(shí)先采用單體架構(gòu)做設(shè)計(jì)，即便在項(xiàng)目后期使用微服務(wù)架構(gòu)更有價(jià)值。

第一個(gè)原因是經(jīng)典的 Yagni 原則 (譯者注："You Aren't Gonna Need It" 的縮寫，意在避免過度設(shè)計(jì))。當(dāng)你開始一個(gè)新的應(yīng)用程序時(shí)，你如何確定這個(gè)應(yīng)用的特性是用戶有價(jià)值的？一個(gè)成功的軟件可能背后的設(shè)計(jì)很糟糕，很難拓展，但是總比一個(gè)設(shè)計(jì)卓越但是沒有價(jià)值的系統(tǒng)好。正如我們現(xiàn)在所認(rèn)識(shí)到的，通常判斷一個(gè)軟件和想法是否有用的最好方法，是構(gòu)建一個(gè)簡(jiǎn)單的版本，看看它的跑起來效果如何。在第一個(gè)階段，你需要優(yōu)先考慮速度(以及反饋的周期時(shí)間)，因此微服務(wù)的成本是一個(gè)累贅，應(yīng)該被避免。

從微服務(wù)開始的第二個(gè)問題是，它們只有在服務(wù)之間建立良好、穩(wěn)定的邊界時(shí)才能正常工作——這本質(zhì)上是厘清正確的限界上下文?的任務(wù)。因?yàn)槿魏畏?wù)之間的功能重構(gòu)都比在一個(gè)龐然大物的單體中要困難得多。不幸的是，即使是在熟悉的領(lǐng)域工作的經(jīng)驗(yàn)豐富的架構(gòu)師，也很難在一開始就確定邊界。通過先構(gòu)建一個(gè)單體應(yīng)用，你可以在微服務(wù)設(shè)計(jì)刷上一層糖漿之前(譯者注：比喻微服務(wù)的一些額外設(shè)施)，找出正確的邊界是什么。它還為你提供了緩沖時(shí)間來開發(fā)細(xì)粒度服務(wù)所需的基礎(chǔ)設(shè)施。

據(jù)我所知，踐行單一優(yōu)先策略有不同的方式。比如，仔細(xì)的從邏輯上設(shè)計(jì)為一個(gè)類似單體系統(tǒng)的整體，注意內(nèi)部的模塊化設(shè)計(jì)，包括 API 邊界和數(shù)據(jù)的存儲(chǔ)方式。做好這一點(diǎn)，再來開發(fā)微服務(wù)的系統(tǒng)。然而，如果我聽過很多這樣的成功案例，我會(huì)覺得這種方法更合適，實(shí)際很難做到。

一種更常見的方法是從一個(gè)龐然大物開始，然后逐漸從邊緣剝離微服務(wù)。這種方法可能會(huì)在微服務(wù)體系結(jié)構(gòu)的核心留下一塊巨大的龐然大物，但是大多數(shù)新開發(fā)都是在微服務(wù)中進(jìn)行的，只是這一塊龐然大物是相對(duì)不變的。

另一種常見的方法是先開發(fā)一個(gè)單體系統(tǒng)，再用一套新的微服務(wù)系統(tǒng)完全替換單體結(jié)構(gòu)。很少會(huì)有人認(rèn)同這種辦法，然而建造作為獻(xiàn)祭架構(gòu)的單體系統(tǒng)是有好處的（譯者注：一種設(shè)計(jì)方法，先做簡(jiǎn)單的原型系統(tǒng)，再用新的系統(tǒng)代替，其實(shí)就是重寫）。不要害怕建造一個(gè)你會(huì)丟棄的龐然大物，特別是如果一個(gè)龐然大物可以讓你很快地進(jìn)入市場(chǎng)。

還有，我遇到的其他方法是從幾個(gè)粗粒度的服務(wù)開始，這些服務(wù)要比你預(yù)期的要大。使用這些粗粒度的服務(wù)來習(xí)慣處理多個(gè)服務(wù)，同時(shí)享受這樣一個(gè)事實(shí)：粗粒度減少了你必須不得已進(jìn)行服務(wù)間重構(gòu)的數(shù)量。然后，隨著邊界穩(wěn)定下來，就會(huì)分解為更細(xì)粒度的服務(wù)。

雖然我接觸的大多數(shù)人傾向于“單體優(yōu)先”的策略，但這不是絕對(duì)的。相反的觀點(diǎn)認(rèn)為，從微服務(wù)開始構(gòu)建新的系統(tǒng)，可以讓你適應(yīng)在微服務(wù)環(huán)境中開發(fā)的節(jié)奏。要以足夠模塊化的方式構(gòu)建單體系統(tǒng)，以便將其輕松分解為微服務(wù)，需要花費(fèi)很多甚至太多的編程規(guī)則。從微服務(wù)開始，你可以讓每個(gè)人從一開始就習(xí)慣在獨(dú)立的小團(tuán)隊(duì)中進(jìn)行開發(fā)，并且在需要的時(shí)候，通過服務(wù)邊界將團(tuán)隊(duì)分開可以更容易地?cái)U(kuò)大開發(fā)工作。對(duì)于那些更有可能盡早獲得足夠穩(wěn)定邊界的系統(tǒng)來說，這尤其可行。盡管證據(jù)不多，但我覺得你不應(yīng)該從微服務(wù)開始，除非你有在團(tuán)隊(duì)中構(gòu)建微服務(wù)系統(tǒng)的大量經(jīng)驗(yàn)。

我覺得我還沒有足夠的例子來明確如何決定是否使用“單體優(yōu)先”策略。畢竟，這是微服務(wù)的早期階段(譯者注：這篇文章發(fā)布在2015)，可供學(xué)習(xí)的業(yè)界案例相對(duì)較少。因此，任何人在這些問題上的建議都需要保持開放性，無論觀點(diǎn)的提出者如何信誓旦旦。