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

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

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

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

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

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

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

　　設(shè)置時(shí)間更長

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

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

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

　　微服務(wù)更適合大型團(tuán)隊(duì)

　　將微服務(wù)分配給每個(gè)團(tuán)隊(duì)的做法更適合大型工程團(tuán)隊(duì)。

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

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

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

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

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

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

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

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

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

　　總結(jié)

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

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

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

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