微服務(wù)就是個坑！

點擊上方 "大數(shù)據(jù)肌肉猿"關(guān)注,?星標一起成長

點擊下方鏈接，進入高質(zhì)量學(xué)習(xí)交流群

今日更新| 950個轉(zhuǎn)型案例分享-大數(shù)據(jù)交流群

為什么大多數(shù)公司最好要避免使用微服務(wù)呢？微服務(wù)看起來是一種很好的解決方案。從理論上講，微服務(wù)可以加快開發(fā)速度，同時允許你獨立擴展應(yīng)用程序的不同部分。但在現(xiàn)實中，微服務(wù)是有隱藏成本的。也就是說，我認為，在沒有親自構(gòu)建微服務(wù)之前，你不可能理解它們有多復(fù)雜。

下面是我在構(gòu)建微服務(wù)（有時是失敗的）時所學(xué)到的經(jīng)驗心得。

保持微服務(wù)間的數(shù)據(jù)同步可能是一項挑戰(zhàn)。

每個微服務(wù)都有一個數(shù)據(jù)庫，這是推薦的模式。它允許松散的耦合，并且可以讓特定服務(wù)團隊在無需放慢速度協(xié)作共享代碼的情況下，獨立地工作。但如果本應(yīng)同步啟動的微服務(wù)中的一個出現(xiàn)故障時，會發(fā)生什么呢？比如，其中一個微服務(wù)更新了其數(shù)據(jù)庫，而另外一個卻沒有。這種情形會導(dǎo)致數(shù)據(jù)不一致。

根據(jù)個人的經(jīng)驗，調(diào)查跨服務(wù)的數(shù)據(jù)不一致會非常痛苦。錯誤的跨服務(wù)性質(zhì)需要一個人在不同的服務(wù)中工作來修正錯誤。遺憾的是，這就導(dǎo)致了微服務(wù)的優(yōu)勢，即專門針對團隊的服務(wù)，無法發(fā)揮作用。

在一個單體應(yīng)用中，只要把兩個數(shù)據(jù)庫調(diào)用合并到一個原子事務(wù)中，就能很容易地避免這種情況，因此，所有的插入都會成功，或者都不會成功。非常的簡單。但是，松散的藕合會使微服務(wù)變得更為難以實現(xiàn)。

構(gòu)建一個微服務(wù)架構(gòu)所花費的時間要比將相同的特性整合到一個單體應(yīng)用中要多得多。盡管單個服務(wù)是非常簡單的，但是交互的服務(wù)集合要遠比單一的單體更加復(fù)雜。在一個單體中，一個函數(shù)可以調(diào)用任何其他公共函數(shù)。但是，微服務(wù)中的函數(shù)僅限于調(diào)用同一個微服務(wù)中的函數(shù)。這就需要服務(wù)之間的通信。構(gòu)建 API 或者消息傳遞來促進這一點并不容易。而且，跨微服務(wù)的代碼重復(fù)也是不可避免的。當(dāng)一個單體應(yīng)用可以一次定義一個模塊并多次導(dǎo)入，而微服務(wù)是它自己的應(yīng)用：在每一個模塊都必須定義模塊和庫。

將微服務(wù)分派到各個團隊的奢侈做法是留給大型工程部門。盡管這對這個架構(gòu)來說是一個很大的優(yōu)勢，但是如果你擁有足夠的工程師來為每一項服務(wù)指定一些工程師，那么這才是可行的。減少代碼范圍，可以讓開發(fā)人員對代碼有更好的理解，加快開發(fā)的速度。但是，大部分的初創(chuàng)公司都沒有這樣的奢侈。在一個創(chuàng)業(yè)早期的公司，由于缺乏足夠的資源，有些工程師必須在所有的服務(wù)之間工作。遺憾的是，這樣做會降低工作效率，因為在不同的應(yīng)用中跳躍，可能會導(dǎo)致環(huán)境的變化。我發(fā)現(xiàn)，在我已經(jīng)很久沒有關(guān)注的微服務(wù)中調(diào)查 Bug，是一件非常令人筋疲力盡的事情。

選擇微服務(wù)最有說服力的一個原因就是可以在不同類型的服務(wù)器上運行不同的服務(wù)。這是為什么呢？React 前端的內(nèi)存、CPU 和啟動時間的需求與訓(xùn)練機器學(xué)習(xí)模型的服務(wù)大相徑庭。為每一項服務(wù)選擇適當(dāng)?shù)幕A(chǔ)架構(gòu)類型，可以極大地減少費用。但是，這也給自己帶來了一個挑戰(zhàn)。

舉個例子，在我的職業(yè)生涯初期，由于忘記重啟一個更新過代碼的服務(wù)，導(dǎo)致我丟失了大量的生產(chǎn)數(shù)據(jù)。過期的代碼會通過 API 來接收數(shù)據(jù)，卻沒有把數(shù)據(jù)存入數(shù)據(jù)庫，反而消無聲息地失敗。這樣的數(shù)據(jù)就會永遠丟失了。

我之所以提出這一點，是想要表明，配置、維護和監(jiān)控多個微服務(wù)，要比單一的單體應(yīng)用要復(fù)雜得多。擁有多個應(yīng)用程序，還為駭客增加了多個攻擊面。

從理論上講，“松散耦合”的服務(wù)允許每個服務(wù)在其他服務(wù)失敗時繼續(xù)工作。但這只是一廂情愿的想法：對于有客戶的復(fù)雜業(yè)務(wù)來說，很難實現(xiàn)真正的松散耦合。

最終，你的應(yīng)用程序架構(gòu)的可靠程度取決于最薄弱的部分。移動的碎片越多，出錯的可能性就越大。

許多公司使用微服務(wù)并不是真正需要它們，而且盡管微服務(wù)現(xiàn)在很流行，但它們并不適合初學(xué)者。大多數(shù)公司最好的做法是構(gòu)建一個單體，然后在絕對必要的時候?qū)误w的部分拆分到微服務(wù)中。

把從頭開始的微服務(wù)架構(gòu)的機會留給那些財力雄厚的大型科技公司。

你的早期階段的創(chuàng)業(yè)公司也許還沒有準備好。我的公司就沒有準備好，結(jié)果，讓我們付出了大量的時間和精力。

掃描下方二維碼
添加好友，備注【交流】
可私聊交流，也可進資源豐富學(xué)習(xí)群

更文不易，點個“在看”支持一下??