如何在微服務(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來開啟部署之旅的時候就對你有所啟示。