本文講的是<b>如何在微服務之間共享使用資料庫</b>，【編者的話】如何在微服務之間共享使用資料庫？本文介紹了一個該領域很容易犯錯的架構問題，并且提出了解決方案和反思。
幾年前，我是一個團隊的首席開發人員，該團隊為用戶端開發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來開啟部署之旅的時候就對你有所啟示。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
譯者介紹
崔婧雯，現就職于IBM，進階軟體工程師，負責IBM WebSphere業務流程管理軟體的系統測試工作。曾就職于VMware從事桌面虛拟化産品的品質保證工作。對虛拟化，中間件技術，業務流程管理有濃厚的興趣。
原文釋出時間為：2015-10-26
本文作者：lingxizhixia
本文來自雲栖社群合作夥伴DockerOne，了解相關資訊可以關注DockerOne。
原文标題：如何在微服務之間共享使用資料庫