噩夢般的數(shù)據(jù)管理

　　跨多個微服務(wù)保持數(shù)據(jù)同步是一個很大的難題。

　　通常人們推薦的方式是每個微服務(wù)一個數(shù)據(jù)庫。這樣不僅可以實現(xiàn)松散耦合，而且還可以讓各個服務(wù)的團隊獨立運作，同時不會影響共享代碼的協(xié)作速度。

　　然而，如果兩個微服務(wù)應(yīng)該互相同步，但其中一個發(fā)生故障，后果會怎樣？例如，其中一個微服務(wù)更新了數(shù)據(jù)庫，而另一個沒有。這樣的狀況會導(dǎo)致數(shù)據(jù)的不一致。

　　根據(jù)我的個人經(jīng)驗，跨服務(wù)調(diào)查數(shù)據(jù)的不一致會非常痛苦。由于錯誤跨多個服務(wù)，因此需要某個人跨多個服務(wù)修正錯誤。不幸的是，這導(dǎo)致微服務(wù)喪失了其優(yōu)勢之一：每項服務(wù)由一個開發(fā)團隊負責。

　　而單體應(yīng)用則可以通過一個原子事務(wù)打包兩個數(shù)據(jù)庫調(diào)用，保證兩個插入操作都成功或都失敗，從而輕松防止出現(xiàn)相同的情況。十分簡單。

　　但是對于微服務(wù)，松散耦合導(dǎo)致這些操作變得更加困難。

　　設(shè)置時間更長

　　構(gòu)建微服務(wù)架構(gòu)所需的時間比將相同的功能整合到單體應(yīng)用更長。雖然微服務(wù)的一個服務(wù)很簡單，但交互的服務(wù)集合比類似的單體應(yīng)用要復(fù)雜得多。

　　單體應(yīng)用中的函數(shù)可以調(diào)用任何其他公共函數(shù)。但是微服務(wù)中的函數(shù)僅限于調(diào)用同一個微服務(wù)中的函數(shù)。這就導(dǎo)致服務(wù)之間需要通信。而構(gòu)建通信所需的API或消息系統(tǒng)并非易事。

　　此外，微服務(wù)之間的代碼重復(fù)無法避免。單體應(yīng)用則可以定義一個模塊，并多次導(dǎo)入，而微服務(wù)本身就是應(yīng)用，所有的模塊和庫定義都在內(nèi)部。

　　微服務(wù)更適合大型團隊

　　將微服務(wù)分配給每個團隊的做法更適合大型工程團隊。

　　盡管這是該架構(gòu)的優(yōu)勢之一，但只有當工程團隊有足夠的人手，可以為每個服務(wù)分配多名工程時，這種優(yōu)勢才能發(fā)揮出來?？s小代碼的范圍，可以讓開發(fā)人員更好地理解代碼，并提高開發(fā)速度。

　　然而，大多數(shù)創(chuàng)業(yè)公司并沒有這樣奢侈的資源。創(chuàng)業(yè)早期，公司的資源往往不足，有些工程師需要負責所有的服務(wù)。不幸的是，開發(fā)人員的思維需要在多個應(yīng)用之間來回跳躍，因此會導(dǎo)致生產(chǎn)力低下。

　　此外，跨多個陌生的微服務(wù)調(diào)查 bug 真心累。

　　開發(fā)運維更加復(fù)雜

　　絕大多數(shù)人選擇微服務(wù)的主要原因之一就在于，能夠在多個不同類型的服務(wù)器上運行不同的服務(wù)。

　　為什么？React 前端的需求完全不同于訓(xùn)練機器學(xué)習(xí)模型的服務(wù)，比如內(nèi)存、CPU 和正常運行的時間等。針對每個服務(wù)選擇正確的基礎(chǔ)設(shè)施可以大大降低成本。但同時也會帶來挑戰(zhàn)。舉個例子，在職業(yè)生涯的早期，我曾經(jīng)造成了大量生產(chǎn)數(shù)據(jù)丟失，因為在更新完某個服務(wù)的代碼后，我忘了重啟服務(wù)，舊代碼通過API請求接收數(shù)據(jù)，然后出錯了，未能成功地將這些數(shù)據(jù)保存到數(shù)據(jù)庫，也沒有報錯。所以，數(shù)據(jù)永久地丟失了。

　　我舉這個例子是為了說明與單體應(yīng)用相比，配置、維護和監(jiān)控多個微服務(wù)需要付出更多的努力。此外，擁有多個應(yīng)用也會導(dǎo)致黑客攻擊的途徑增加。

　　理論上，“松散耦合”可以保證某個服務(wù)發(fā)生故障時，其他服務(wù)繼續(xù)運行。但這只是癡人說夢，對于業(yè)務(wù)非常復(fù)雜的客戶來說，真正實現(xiàn)松散耦合幾乎是不可能的。

　　最后，架構(gòu)的可靠程度取決于最薄弱的環(huán)節(jié)。活動的部分越多，出錯的概率就越大。

　　總結(jié)

　　雖然許多公司都采用了微服務(wù)，但實際上并沒有必要。盡管如今微服務(wù)的人氣很高，但并不適合初創(chuàng)公司。

　　對于大多數(shù)公司來說，單體應(yīng)用才是更好的選擇。等到有必要時，再將單體應(yīng)用的各個部分拆分為微服務(wù)。

　　當然，資金雄厚的大型科技公司完全可以從零開始構(gòu)建微服務(wù)架構(gòu)。

　　對于剛起步的創(chuàng)業(yè)公司來說，微服務(wù)并不適合，而且還會浪費大量的時間和精力。