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

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

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

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

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

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

　　但是對于微服務，松散耦合導致這些操作變得更加困難,。

　　設置時間更長

　　構建微服務架構所需的時間比將相同的功能整合到單體應用更長,。雖然微服務的一個服務很簡單，但交互的服務集合比類似的單體應用要復雜得多,。

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

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

　　微服務更適合大型團隊

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

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

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

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

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

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

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

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

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

　　最后，架構的可靠程度取決于最薄弱的環(huán)節(jié),?；顒拥牟糠衷蕉啵鲥e的概率就越大,。

　　總結

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

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

　　當然,，資金雄厚的大型科技公司完全可以從零開始構建微服務架構,。

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