建站
咨詢
售后
建站咨詢
新聞中心
作者 | Martin Fowler
當聽說有團隊在使用微服務架構(gòu)時候，我注意到了一些規(guī)律：
- 幾乎所有成功應用微服務的系統(tǒng)，都來自于一個過大單體項目拆分而來。
- 幾乎所有我聽到過一開始就選擇使用微服務架構(gòu)的系統(tǒng)，并從 0 構(gòu)建，最終的結(jié)果都有一系列嚴重的麻煩。
這些規(guī)律在我同事中產(chǎn)生了長期的討論：你不應該在新項目之初就采用微服務架構(gòu)，即使你堅信該應用未來會因業(yè)務演進而變得巨大無比。
微服務是一種有用的架構(gòu)，但是即使是這種架構(gòu)的擁躉也不得不承認，使用這種架構(gòu)需要付出額外的成本，這意味者只有更復雜的系統(tǒng)值得使用這種架構(gòu)。這種代價的本質(zhì)是管理這些服務所帶來的基本開銷。所以這就是單體優(yōu)先架構(gòu)策略的依據(jù)， 架構(gòu)師應在構(gòu)建新系統(tǒng)時先采用單體架構(gòu)做設(shè)計，即便在項目后期使用微服務架構(gòu)更有價值。
第一個原因是經(jīng)典的 Yagni 原則 (譯者注："You Aren't Gonna Need It" 的縮寫，意在避免過度設(shè)計)。當你開始一個新的應用程序時，你如何確定這個應用的特性是用戶有價值的？一個成功的軟件可能背后的設(shè)計很糟糕，很難拓展，但是總比一個設(shè)計卓越但是沒有價值的系統(tǒng)好。正如我們現(xiàn)在所認識到的，通常判斷一個軟件和想法是否有用的最好方法，是構(gòu)建一個簡單的版本，看看它的跑起來效果如何。在第一個階段，你需要優(yōu)先考慮速度(以及反饋的周期時間)，因此微服務的成本是一個累贅，應該被避免。
從微服務開始的第二個問題是，它們只有在服務之間建立良好、穩(wěn)定的邊界時才能正常工作——這本質(zhì)上是厘清正確的限界上下文?的任務。因為任何服務之間的功能重構(gòu)都比在一個龐然大物的單體中要困難得多。不幸的是，即使是在熟悉的領(lǐng)域工作的經(jīng)驗豐富的架構(gòu)師，也很難在一開始就確定邊界。通過先構(gòu)建一個單體應用，你可以在微服務設(shè)計刷上一層糖漿之前(譯者注：比喻微服務的一些額外設(shè)施)，找出正確的邊界是什么。它還為你提供了緩沖時間來開發(fā)細粒度服務所需的基礎(chǔ)設(shè)施。
據(jù)我所知，踐行單一優(yōu)先策略有不同的方式。比如，仔細的從邏輯上設(shè)計為一個類似單體系統(tǒng)的整體，注意內(nèi)部的模塊化設(shè)計，包括 API 邊界和數(shù)據(jù)的存儲方式。做好這一點，再來開發(fā)微服務的系統(tǒng)。然而，如果我聽過很多這樣的成功案例，我會覺得這種方法更合適，實際很難做到。
一種更常見的方法是從一個龐然大物開始，然后逐漸從邊緣剝離微服務。這種方法可能會在微服務體系結(jié)構(gòu)的核心留下一塊巨大的龐然大物，但是大多數(shù)新開發(fā)都是在微服務中進行的，只是這一塊龐然大物是相對不變的。
另一種常見的方法是先開發(fā)一個單體系統(tǒng)，再用一套新的微服務系統(tǒng)完全替換單體結(jié)構(gòu)。很少會有人認同這種辦法，然而建造作為獻祭架構(gòu)的單體系統(tǒng)是有好處的（譯者注：一種設(shè)計方法，先做簡單的原型系統(tǒng)，再用新的系統(tǒng)代替，其實就是重寫）。不要害怕建造一個你會丟棄的龐然大物，特別是如果一個龐然大物可以讓你很快地進入市場。
還有，我遇到的其他方法是從幾個粗粒度的服務開始，這些服務要比你預期的要大。使用這些粗粒度的服務來習慣處理多個服務，同時享受這樣一個事實：粗粒度減少了你必須不得已進行服務間重構(gòu)的數(shù)量。然后，隨著邊界穩(wěn)定下來，就會分解為更細粒度的服務。
雖然我接觸的大多數(shù)人傾向于“單體優(yōu)先”的策略，但這不是絕對的。相反的觀點認為，從微服務開始構(gòu)建新的系統(tǒng)，可以讓你適應在微服務環(huán)境中開發(fā)的節(jié)奏。要以足夠模塊化的方式構(gòu)建單體系統(tǒng)，以便將其輕松分解為微服務，需要花費很多甚至太多的編程規(guī)則。從微服務開始，你可以讓每個人從一開始就習慣在獨立的小團隊中進行開發(fā)，并且在需要的時候，通過服務邊界將團隊分開可以更容易地擴大開發(fā)工作。對于那些更有可能盡早獲得足夠穩(wěn)定邊界的系統(tǒng)來說，這尤其可行。盡管證據(jù)不多，但我覺得你不應該從微服務開始，除非你有在團隊中構(gòu)建微服務系統(tǒng)的大量經(jīng)驗。
我覺得我還沒有足夠的例子來明確如何決定是否使用“單體優(yōu)先”策略。畢竟，這是微服務的早期階段(譯者注：這篇文章發(fā)布在2015)，可供學習的業(yè)界案例相對較少。因此，任何人在這些問題上的建議都需要保持開放性，無論觀點的提出者如何信誓旦旦。
網(wǎng)頁名稱：單體優(yōu)先的微服務架構(gòu)
網(wǎng)站網(wǎng)址：http://www.dlmjj.cn/article/djsoeos.html
