服務化了，沒想到耦合更加嚴重？

經過「庫」來實現業務，可能會引起業務系統之間耦合，須要通用業務服務化，將通用業務下沉，詳見《小小的公共庫，大大的耦合，你痛過嗎》。

經過「join」來實現業務，可能會致使數據庫之間耦合，須要基礎數據服務化，實現數據庫私有化，解除數據庫之間的耦合，詳見《小小的數據庫，大大的耦合，你經過嗎》。

但若是服務化不合理，將部分個性化業務下沉到了底層，耦合與瓶頸會更加嚴重。

場景還原
業務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)走不一樣分支的代碼。

業務代碼上浮，通用代碼下沉，服務化完全，只是一個很小的優化點，但對於底層服務解耦倒是很是的有效。

但願你們天天收穫一點點，這樣架構就能美好一點點。
你痛過嗎，你被反問過「你實現代價小，你來搞」嗎？你被迫實現過「switch case」嗎？那幫轉下。

相關文章：小小的數據庫，大大的耦合，你痛過嗎？小小的IP，大大的耦合，你痛過嗎？小小的公共庫，大大的耦合，你痛過嗎？