這個問題是由工作中的一次需求的變動引起的。

1:為什麽會有這個思考

　　我們當前做的是一個視頻門戶系統,這個系統分為四個子系統:cms(內容系統),bms(訂購系統),tms(終端管理系統),ims(用戶系統)。這四個系統對應同名的四個數據庫,分別記錄相關的數據。

　　問題出現在一次需求變動後,我們要用各地的CDN播放地址替換源播放地址,所以我們要對業務做一下小小的改動。但是在改動的過程中發現,ims的一些業務功能也用到了播放地址,所以不僅cms要改動,ims也要改動。這樣的話改動的地方就比較多,比較大了。

2:存在這個問題的原因

　　為什麽會出現這個問題呢?最初我們在設計這個系統的時候,數據庫的劃分還是比較明確的。但是在業務劃分方面,由於沒有經驗,導致業務模塊的邊界劃分的不夠清晰。而且在後期的系統構建過程中,為了圖方便,用到其它系統的數據的地方就直接引用其它系統的數據庫了。這些原因就導致了要修改一個功能，卻要修改多個項目的多個地方的問題。

3:關於這個問題的思考

　　出現這個問題首先是因為設計之初沒能深入透徹的明白業務需求,導致業務劃分,特別是業務邊界的劃分不夠明確,導致我們關於某個功能的實現可能同時出現在多個系統中。

　　然後就是業務劃分的粒度不夠細,因為粒度劃分的越細,越容易實現模塊間的解耦,模塊間的復用。而不用因為一個問題的出現到處去修改。

　　還有就是對於某個模塊或某個功能,對外暴露出來的供外部使用或調用的接口一定要是唯一的,這樣如果業務改變我們只用修改這個接口的內部實現就行了。例如：對於一個數據表的操作,如果四個子系統都有一定的實現,那麽當數據庫表有改動時,四個子系統都要改動。如果只有一個子系統實現了這個數據庫的操作,別的子系統都是通過調用這個子系統暴露的接口來對數據庫進行操作的話,這個問題就變得很簡單了。

4:後記

　　當然,任何復雜的系統都不是一蹴而就的，都是由一些簡單的甚至不合理的系統慢慢進化而來的。在設計之初,我們也不可能將系統架構的十全十美。在這種情況下,我們一定要擦亮眼睛,因為一切讓我們感覺到復雜甚至不合理的地方都是我們進一步優化的入口。我們一定要保持思維的敏感與潔癖,因為你對問題的將就和習慣可能會使你的技術與能力止步不前。

從微服務劃分,微服務之間通信到程序員能力提高的一些思考