我們在微服務之間共享數(shù)據(jù)庫時犯下的錯誤
如何在微服務之間共享使用數(shù)據(jù)庫?本文介紹了一個該領域很容易犯錯的架構問題，并且提出了解決方案和反思。
幾年前，我是一個團隊的***開發(fā)人員，該團隊為客戶端開發(fā)Java web應用程序。本文里我們稱之為“項目A”。我們在客戶現(xiàn)場構建web應用，還有其他團隊在相關項目上共同工作。因為我們在項目早期溝通合作一直很愉快深入，所以會定期在團隊間交換軟件的架構思想。
一天，一個新項目(項目B)啟動了。該項目會由另外一個團隊完成。我認為在這個新項目中我們也能有所貢獻，我們將項目A的記錄用戶，角色和權限的通用認證的數(shù)據(jù)庫schema共享給了項目B。最終，這兩個項目都是使用相同用戶數(shù)據(jù)庫的內(nèi)部web應用程序。對了，還忘記說一點，這些應用程序沒有中央的用戶數(shù)據(jù)庫 -- 每個新項目都是從頭開始的。我們發(fā)現(xiàn)通過共享已有的基礎架構和***實踐，不僅僅可以節(jié)省開發(fā)時間，而且還能夠節(jié)省很多客戶支持的時間，因為他們不需要處理單獨的用戶目錄了。
項目進展順利，第二個項目使用單獨的數(shù)據(jù)庫用戶賬號訪問我們的數(shù)據(jù)庫表，這樣兩個項目可以隔離開從而避免混亂。
一段時間之后。。。
畢竟存儲用戶，角色和權限不是什么難事。大概一年后，我們計劃開發(fā)項目A的新版本。我們都很興奮，因為有機會可以將項目A中工作不太好的地方改進，同時保留好的功能。我們也改進了一些項目A里工作得還可以的部分 -- 其中，包括改進了存儲用戶，角色和權限的數(shù)據(jù)庫表的schema。老實說，當時根本沒有想到會影響項目B。
當然，很快項目B就崩潰了。我們的錯誤之處在于給了項目B直接訪問數(shù)據(jù)庫的權限。不僅僅就現(xiàn)在的標準而言，就算是根據(jù)以前的標準，正確的決定也是去創(chuàng)建一個單獨的認證服務，來共享通用的API，而不是直接共享數(shù)據(jù)庫訪問。
還有更多的。。。
因此，我們犯了一個嚴重的架構錯誤，但是這里還有另外一個問題。具有諷刺意味的是，項目B使用的人不多。當時要求項目B的團隊都沒怎么使用項目B。這個項目就一直停滯著，可以使用，但一直沒有正式啟用。因此在兩周之后才有人發(fā)現(xiàn)項目B不工作了。
在***個可憐的用戶報告出問題的時候，我們的開發(fā)人員已經(jīng)到其他項目上工作去了。在做問題定位分析的時候，我們檢查了錯誤日志，嘗試找出是什么問題。現(xiàn)在來看，我們當時沒有規(guī)劃精細的監(jiān)控方案，能夠自動監(jiān)測到應用程序的問題，這也是失誤決策的一部分。
雖然這次事故聽上去很古老，但是我真的希望大家能夠從中學習到經(jīng)驗教訓。一定要確保通過穩(wěn)定的API來訪問數(shù)據(jù)庫，從而將簡單的數(shù)據(jù)庫轉(zhuǎn)變?yōu)榉眨彩沟霉蚕硎褂酶鼮槿菀?。并且確保正確監(jiān)控應用程序和服務。圍繞API構建的環(huán)境會長期保持基礎架構的動態(tài)性。監(jiān)控則能確保能夠有效控制日益增長的復雜度。
我期望這篇文章的問題能夠在你在Eclipse IDE里打開File菜單，選擇Export as .war來開啟部署之旅的時候就對你有所啟示。
