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

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

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

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

一段時間之后。。。

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

當然，很快項目B就崩潰了。我們的錯誤之處在于給了項目B直接訪問數據庫的權限。不僅僅就現在的標準而言，就算是根據以前的標準，正確的決定也是去創建一個單獨的認證服務，來共享通用的API，而不是直接共享數據庫訪問。

還有更多的。。。

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

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

雖然這次事故聽上去很古老，但是我真的希望大家能夠從中學習到經驗教訓。一定要確保通過穩定的API來訪問數據庫，從而將簡單的數據庫轉變為服務，也使得共享使用更為容易。并且確保正確監控應用程序和服務。圍繞API構建的環境會長期保持基礎架構的動態性。監控則能確保能夠有效控制日益增長的復雜度。

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