服務化了，沒想到耦合更加嚴重？
通過“庫”來實現業務，可能會引發業務系統之間耦合，需要通用業務服務化，將通用業務下沉，詳見《小小的公共庫，大大的耦合，你痛過嗎》。
通過“join”來實現業務，可能會導致數據庫之間耦合，需要基礎數據服務化，實現數據庫私有化，解除數據庫之間的耦合，詳見《CA，給了數據庫，給了機器，為啥也擴不了容?》。
但如果服務化不合理，將部分個性化業務下沉到了底層，耦合與瓶頸會更加嚴重。
場景還原
業務1，業務2，業務3，因為join導致數據庫實例耦合在了一起。
為了實現通用數據庫table-user的解耦，實施了服務化，將通用user數據的訪問抽象出了服務。
由于服務化不合理，會有很少很少的個性化業務邏輯，實現在底層的服務中，典型的偽代碼是：
- switch(biz_type){
- case(1) : exec_logic1();
- case(2) : exec_logic2();
- case(3) : exec_logic3();
- default : exec_default();
- }
為什么會引發耦合呢?
不妨設，業務1來了一個新的個性化需求，這個需求本來實現在業務1自己的代碼里是合理的，但工程師S想到，底層的通用服務里也有業務1的一小撮個性化代碼，評估后，發現實現在底層新的需求改動的代碼最小，時間最短，于是來找底層服務的負責人工程師B。
- 業務1工程師S：“有個小需求，幫個忙唄”
- 底層工程師B：“個性化實現在底層不合理”
- 業務1工程師S：“反正都有switch case的代碼了，再改一點也不麻煩，在我這邊實現特別復雜，要xxoo這么搞”
- 底層工程師B：“確實很復雜，那我來吧”
- …
遺留了不合理的代碼，就會有第一次妥協，妥協了業務1，就會妥協業務2，隨著時間的推移，底層服務越來越復雜：
- 業務1，業務2，業務3的個性化代碼越來越多
- 業務1，業務2，業務3的需求越來越多提給底層工程師
- 底層工程師慢慢成了項目瓶頸，業務1，業務2，業務3的項目逐步delay，但逐步都怪到了底層工程師的頭上
直到有一天，底層服務出了一個小bug，影響了業務1，業務2，業務3，歷史總是驚人的相似：
- 業務1的大boss在群里首先發飆：“技術都干啥了，怎么系統掛了”
- 業務1的工程師S一臉無辜：“底層系統改造，工程師S的bug”
額，然而，這個理由，好像在大boss那解釋不通…
- 底層服務工程師B一臉委屈：“...”。明明需求是業務方的，為什么修改代碼的是我底層呢，業務代碼出了問題，為什么責怪的是我底層呢，每每心中罵娘，系統中很可能就存在耦合。
如何解耦呢?
業務代碼上浮，通用代碼下沉，服務化徹底。
解決方案并不復雜，分層架構中，每一層都有自己的職責，每一層都應該守住自己的底線。
啟示
1. 討論技術方案時，不要總以：
- “放在你那邊做代碼少”
- “放在你那邊做時間短”
- 作為設計折衷的理由，而要多問：“怎么做合理”
2. 盡量杜絕底層出現switch case(biz_type)走不同分支的代碼。
業務代碼上浮，通用代碼下沉，服務化徹底，只是一個很小的優化點，但對于底層服務解耦卻是非常的有效。
【本文為51CTO專欄作者“58沈劍”原創稿件，轉載請聯系原作者】
