如何在微服務(wù)之間共享使用數(shù)據(jù)庫?本文介紹了一個該領(lǐng)域很容易犯錯的架構(gòu)問題，并且提出了解決方案和反思。

幾年前，我是一個團(tuán)隊的首席開發(fā)人員，該團(tuán)隊為客戶端開發(fā)Java web應(yīng)用程序。本文里我們稱之為“項目A”。我們在客戶現(xiàn)場構(gòu)建web應(yīng)用，還有其他團(tuán)隊在相關(guān)項目上共同工作。因為我們在項目早期溝通合作一直很愉快深入，所以會定期在團(tuán)隊間交換軟件的架構(gòu)思想。

一天，一個新項目(項目B)啟動了。該項目會由另外一個團(tuán)隊完成。我認(rèn)為在這個新項目中我們也能有所貢獻(xiàn)，我們將項目A的記錄用戶，角色和權(quán)限的通用認(rèn)證的數(shù)據(jù)庫schema共享給了項目B。最終，這兩個項目都是使用相同用戶數(shù)據(jù)庫的內(nèi)部web應(yīng)用程序。對了，還忘記說一點，這些應(yīng)用程序沒有中央的用戶數(shù)據(jù)庫 -- 每個新項目都是從頭開始的。我們發(fā)現(xiàn)通過共享已有的基礎(chǔ)架構(gòu)和最佳實踐，不僅僅可以節(jié)省開發(fā)時間，而且還能夠節(jié)省很多客戶支持的時間，因為他們不需要處理單獨的用戶目錄了。

項目進(jìn)展順利，第二個項目使用單獨的數(shù)據(jù)庫用戶賬號訪問我們的數(shù)據(jù)庫表，這樣兩個項目可以隔離開從而避免混亂。

一段時間之后。。。

畢竟存儲用戶，角色和權(quán)限不是什么難事。大概一年后，我們計劃開發(fā)項目A的新版本。我們都很興奮，因為有機會可以將項目A中工作不太好的地方改進(jìn)，同時保留好的功能。我們也改進(jìn)了一些項目A里工作得還可以的部分 -- 其中，包括改進(jìn)了存儲用戶，角色和權(quán)限的數(shù)據(jù)庫表的schema。老實說，當(dāng)時根本沒有想到會影響項目B。

當(dāng)然，很快項目B就崩潰了。我們的錯誤之處在于給了項目B直接訪問數(shù)據(jù)庫的權(quán)限。不僅僅就現(xiàn)在的標(biāo)準(zhǔn)而言，就算是根據(jù)以前的標(biāo)準(zhǔn)，正確的決定也是去創(chuàng)建一個單獨的認(rèn)證服務(wù)，來共享通用的API，而不是直接共享數(shù)據(jù)庫訪問。

還有更多的。。。

因此，我們犯了一個嚴(yán)重的架構(gòu)錯誤，但是這里還有另外一個問題。具有諷刺意味的是，項目B使用的人不多。當(dāng)時要求項目B的團(tuán)隊都沒怎么使用項目B。這個項目就一直停滯著，可以使用，但一直沒有正式啟用。因此在兩周之后才有人發(fā)現(xiàn)項目B不工作了。

在第一個可憐的用戶報告出問題的時候，我們的開發(fā)人員已經(jīng)到其他項目上工作去了。在做問題定位分析的時候，我們檢查了錯誤日志，嘗試找出是什么問題?，F(xiàn)在來看，我們當(dāng)時沒有規(guī)劃精細(xì)的監(jiān)控方案，能夠自動監(jiān)測到應(yīng)用程序的問題，這也是失誤決策的一部分。

雖然這次事故聽上去很古老，但是我真的希望大家能夠從中學(xué)習(xí)到經(jīng)驗教訓(xùn)。一定要確保通過穩(wěn)定的API來訪問數(shù)據(jù)庫，從而將簡單的數(shù)據(jù)庫轉(zhuǎn)變?yōu)榉?wù)，也使得共享使用更為容易。并且確保正確監(jiān)控應(yīng)用程序和服務(wù)。圍繞API構(gòu)建的環(huán)境會長期保持基礎(chǔ)架構(gòu)的動態(tài)性。監(jiān)控則能確保能夠有效控制日益增長的復(fù)雜度。

我期望這篇文章的問題能夠在你在Eclipse IDE里打開File菜單，選擇Export as .war來開啟部署之旅的時候就對你有所啟示。