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

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

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

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

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

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

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

　　設(shè)置時(shí)間更長(zhǎng)

　　構(gòu)建微服務(wù)架構(gòu)所需的時(shí)間比將相同的功能整合到單體應(yīng)用更長(zhǎng),。雖然微服務(wù)的一個(gè)服務(wù)很簡(jiǎn)單，但交互的服務(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ù)無(wú)法避免,。單體應(yīng)用則可以定義一個(gè)模塊,，并多次導(dǎo)入，而微服務(wù)本身就是應(yīng)用,，所有的模塊和庫(kù)定義都在內(nèi)部,。

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

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

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

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

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

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

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

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

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

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

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

　　總結(jié)

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

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

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

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