立刻停止盲目使用微服務(wù)!
點(diǎn)擊“開發(fā)者技術(shù)前線”，選擇“星標(biāo)”讓一部分開發(fā)者看到未來
譯者 | Sambodhi 策劃 | 辛?xí)粤?
為什么大多數(shù)公司最好要避免使用微服務(wù)呢？微服務(wù)看起來是一種很好的解決方案。從理論上講，微服務(wù)可以加快開發(fā)速度，同時(shí)允許你獨(dú)立擴(kuò)展應(yīng)用程序的不同部分。但在現(xiàn)實(shí)中，微服務(wù)是有隱藏成本的。也就是說，我認(rèn)為，在沒有親自構(gòu)建微服務(wù)之前，你不可能理解它們有多復(fù)雜。
下面是我在構(gòu)建微服務(wù)（有時(shí)是失敗的）時(shí)所學(xué)到的經(jīng)驗(yàn)心得。
管理數(shù)據(jù)是一場(chǎng)噩夢(mèng)保持微服務(wù)間的數(shù)據(jù)同步可能是一項(xiàng)挑戰(zhàn)。
每個(gè)微服務(wù)都有一個(gè)數(shù)據(jù)庫(kù)，這是推薦的模式。它允許松散的耦合，并且可以讓特定服務(wù)團(tuán)隊(duì)在無需放慢速度協(xié)作共享代碼的情況下，獨(dú)立地工作。但如果本應(yīng)同步啟動(dòng)的微服務(wù)中的一個(gè)出現(xiàn)故障時(shí)，會(huì)發(fā)生什么呢？比如，其中一個(gè)微服務(wù)更新了其數(shù)據(jù)庫(kù)，而另外一個(gè)卻沒有。這種情形會(huì)導(dǎo)致數(shù)據(jù)不一致。
根據(jù)個(gè)人的經(jīng)驗(yàn)，調(diào)查跨服務(wù)的數(shù)據(jù)不一致會(huì)非常痛苦。錯(cuò)誤的跨服務(wù)性質(zhì)需要一個(gè)人在不同的服務(wù)中工作來修正錯(cuò)誤。遺憾的是，這就導(dǎo)致了微服務(wù)的優(yōu)勢(shì)，即專門針對(duì)團(tuán)隊(duì)的服務(wù)，無法發(fā)揮作用。
在一個(gè)單體應(yīng)用中，只要把兩個(gè)數(shù)據(jù)庫(kù)調(diào)用合并到一個(gè)原子事務(wù)中，就能很容易地避免這種情況，因此，所有的插入都會(huì)成功，或者都不會(huì)成功。非常的簡(jiǎn)單。但是，松散的藕合會(huì)使微服務(wù)變得更為難以實(shí)現(xiàn)。
設(shè)置時(shí)間更長(zhǎng)構(gòu)建一個(gè)微服務(wù)架構(gòu)所花費(fèi)的時(shí)間要比將相同的特性整合到一個(gè)單體應(yīng)用中要多得多。盡管單個(gè)服務(wù)是非常簡(jiǎn)單的，但是交互的服務(wù)集合要遠(yuǎn)比單一的單體更加復(fù)雜。在一個(gè)單體中，一個(gè)函數(shù)可以調(diào)用任何其他公共函數(shù)。但是，微服務(wù)中的函數(shù)僅限于調(diào)用同一個(gè)微服務(wù)中的函數(shù)。這就需要服務(wù)之間的通信。構(gòu)建 API 或者消息傳遞來促進(jìn)這一點(diǎn)并不容易。而且，跨微服務(wù)的代碼重復(fù)也是不可避免的。當(dāng)一個(gè)單體應(yīng)用可以一次定義一個(gè)模塊并多次導(dǎo)入，而微服務(wù)是它自己的應(yīng)用：在每一個(gè)模塊都必須定義模塊和庫(kù)。
微服務(wù)最適合大型團(tuán)隊(duì)將微服務(wù)分派到各個(gè)團(tuán)隊(duì)的奢侈做法是留給大型工程部門。盡管這對(duì)這個(gè)架構(gòu)來說是一個(gè)很大的優(yōu)勢(shì)，但是如果你擁有足夠的工程師來為每一項(xiàng)服務(wù)指定一些工程師，那么這才是可行的。減少代碼范圍，可以讓開發(fā)人員對(duì)代碼有更好的理解，加快開發(fā)的速度。但是，大部分的初創(chuàng)公司都沒有這樣的奢侈。在一個(gè)創(chuàng)業(yè)早期的公司，由于缺乏足夠的資源，有些工程師必須在所有的服務(wù)之間工作。遺憾的是，這樣做會(huì)降低工作效率，因?yàn)樵诓煌膽?yīng)用中跳躍，可能會(huì)導(dǎo)致環(huán)境的變化。我發(fā)現(xiàn)，在我已經(jīng)很久沒有關(guān)注的微服務(wù)中調(diào)查 Bug，是一件非常令人筋疲力盡的事情。
DevOps 更復(fù)雜選擇微服務(wù)最有說服力的一個(gè)原因就是可以在不同類型的服務(wù)器上運(yùn)行不同的服務(wù)。這是為什么呢？React 前端的內(nèi)存、CPU 和啟動(dòng)時(shí)間的需求與訓(xùn)練機(jī)器學(xué)習(xí)模型的服務(wù)大相徑庭。為每一項(xiàng)服務(wù)選擇適當(dāng)?shù)幕A(chǔ)架構(gòu)類型，可以極大地減少費(fèi)用。但是，這也給自己帶來了一個(gè)挑戰(zhàn)。
舉個(gè)例子，在我的職業(yè)生涯初期，由于忘記重啟一個(gè)更新過代碼的服務(wù)，導(dǎo)致我丟失了大量的生產(chǎn)數(shù)據(jù)。過期的代碼會(huì)通過 API 來接收數(shù)據(jù)，卻沒有把數(shù)據(jù)存入數(shù)據(jù)庫(kù)，反而消無聲息地失敗。這樣的數(shù)據(jù)就會(huì)永遠(yuǎn)丟失了。
我之所以提出這一點(diǎn)，是想要表明，配置、維護(hù)和監(jiān)控多個(gè)微服務(wù)，要比單一的單體應(yīng)用要復(fù)雜得多。擁有多個(gè)應(yīng)用程序，還為駭客增加了多個(gè)攻擊面。
從理論上講，“松散耦合”的服務(wù)允許每個(gè)服務(wù)在其他服務(wù)失敗時(shí)繼續(xù)工作。但這只是一廂情愿的想法：對(duì)于有客戶的復(fù)雜業(yè)務(wù)來說，很難實(shí)現(xiàn)真正的松散耦合。
最終，你的應(yīng)用程序架構(gòu)的可靠程度取決于最薄弱的部分。移動(dòng)的碎片越多，出錯(cuò)的可能性就越大。
總? ? 結(jié)許多公司使用微服務(wù)并不是真正需要它們，而且盡管微服務(wù)現(xiàn)在很流行，但它們并不適合初學(xué)者。大多數(shù)公司最好的做法是構(gòu)建一個(gè)單體，然后在絕對(duì)必要的時(shí)候?qū)误w的部分拆分到微服務(wù)中。
把從頭開始的微服務(wù)架構(gòu)的機(jī)會(huì)留給那些財(cái)力雄厚的大型科技公司。
你的早期階段的創(chuàng)業(yè)公司也許還沒有準(zhǔn)備好。我的公司就沒有準(zhǔn)備好，結(jié)果，讓我們付出了大量的時(shí)間和精力。
作者介紹：
GreekDataGuy，開發(fā)者。
原文鏈接：
https://betterprogramming.pub/stop-using-microservices-build-monoliths-instead-9eac180ac908
—?完?—
點(diǎn)這里??關(guān)注我，記得標(biāo)星呀～
前線推出學(xué)習(xí)交流一定要備注：
研究/工作方向+地點(diǎn)+學(xué)校/公司+昵稱（如JAVA+上海
END
后臺(tái)回復(fù)“電子書”?“資料”?領(lǐng)取一份干貨，數(shù)百面試手冊(cè)等歷史推薦
好文點(diǎn)個(gè)在看吧！