噩夢般的數據管理

　　跨多個微服務保持數據同步是一個很大的難題。

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

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

　　根據我的個人經驗，跨服務調查數據的不一致會非常痛苦。由于錯誤跨多個服務，因此需要某個人跨多個服務修正錯誤。不幸的是，這導致微服務喪失了其優勢之一：每項服務由一個開發團隊負責。

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

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

　　設置時間更長

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

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

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

　　微服務更適合大型團隊

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

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

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

　　此外，跨多個陌生的微服務調查 bug 真心累。

　　開發運維更加復雜

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

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

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

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

　　最后，架構的可靠程度取決于最薄弱的環節。活動的部分越多，出錯的概率就越大。

　　總結

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

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

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

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