服務(wù)化，是架構(gòu)中很常見(jiàn)的分層解耦手段，但如果服務(wù)化不合理，將部分個(gè)性化業(yè)務(wù)下沉到了底層，耦合與瓶頸會(huì)更加嚴(yán)重。

場(chǎng)景還原

業(yè)務(wù)1，業(yè)務(wù)2，業(yè)務(wù)3，因?yàn)閖oin導(dǎo)致數(shù)據(jù)庫(kù)實(shí)例耦合在了一起。

為了實(shí)現(xiàn)通用數(shù)據(jù)庫(kù)table-user的解耦，實(shí)施了服務(wù)化，將通用user數(shù)據(jù)的訪問(wèn)抽象出了服務(wù)。

由于服務(wù)化不合理，會(huì)有很少很少的個(gè)性化業(yè)務(wù)邏輯，實(shí)現(xiàn)在底層的服務(wù)中，典型的偽代碼是：

switch(biz_type){
 case(1) : exec_logic1();
 case(2) : exec_logic2();
 case(3) : exec_logic3();
 default : exec_default();
}

為什么會(huì)引發(fā)耦合呢？

不妨設(shè)，業(yè)務(wù)1來(lái)了一個(gè)新的個(gè)性化需求，這個(gè)需求本來(lái)實(shí)現(xiàn)在業(yè)務(wù)1自己的代碼里是合理的，但工程師S想到，底層的通用服務(wù)里也有業(yè)務(wù)1的一小撮個(gè)性化代碼，評(píng)估后，發(fā)現(xiàn)實(shí)現(xiàn)在底層新的需求改動(dòng)的代碼最小，時(shí)間最短，于是來(lái)找底層服務(wù)的負(fù)責(zé)人工程師B。

業(yè)務(wù)1工程師S：“有個(gè)小需求，幫個(gè)忙唄”

底層工程師B：“個(gè)性化實(shí)現(xiàn)在底層不合理”

業(yè)務(wù)1工程師S：“反正都有switch case的代碼了，再改一點(diǎn)也不麻煩，在我這邊實(shí)現(xiàn)特別復(fù)雜，要xxoo這么搞”

底層工程師B：“確實(shí)很復(fù)雜，那我來(lái)吧”

…

遺留了不合理的代碼，就會(huì)有第一次妥協(xié)，妥協(xié)了業(yè)務(wù)1，就會(huì)妥協(xié)業(yè)務(wù)2，隨著時(shí)間的推移，底層服務(wù)越來(lái)越復(fù)雜：

• 業(yè)務(wù)1，業(yè)務(wù)2，業(yè)務(wù)3的個(gè)性化代碼越來(lái)越多；
• 業(yè)務(wù)1，業(yè)務(wù)2，業(yè)務(wù)3的需求越來(lái)越多提給底層工程師；
• 底層工程師慢慢成了項(xiàng)目瓶頸，業(yè)務(wù)1，業(yè)務(wù)2，業(yè)務(wù)3的項(xiàng)目逐步delay，但逐步都怪到了底層工程師的頭上；

直到有一天，底層服務(wù)出了一個(gè)小bug，影響了業(yè)務(wù)1，業(yè)務(wù)2，業(yè)務(wù)3，歷史總是驚人的相似：

• 業(yè)務(wù)1的大boss在群里首先發(fā)飆：“技術(shù)都干啥了，怎么系統(tǒng)掛了”；
• 業(yè)務(wù)1的工程師S一臉無(wú)辜：“底層系統(tǒng)改造，工程師S的bug”；

額，然而，這個(gè)理由，好像在大boss那解釋不通…

底層服務(wù)工程師B一臉委屈：“...”。

明明需求是業(yè)務(wù)方的，為什么修改代碼的是我底層呢，業(yè)務(wù)代碼出了問(wèn)題，為什么責(zé)怪的是我底層呢，每每心中罵娘，系統(tǒng)中很可能就存在耦合。

如何解耦呢？

業(yè)務(wù)代碼上浮，通用代碼下沉，服務(wù)化徹底。

解決方案并不復(fù)雜，分層架構(gòu)中，每一層都有自己的職責(zé)，每一層都應(yīng)該守住自己的底線。

啟示

(1) 討論技術(shù)方案時(shí)，不要總以：

• “放在你那邊做代碼少”
• “放在你那邊做時(shí)間短”

作為設(shè)計(jì)折衷的理由，而要多問(wèn)：

• “怎么做合理”

(2) 盡量杜絕底層出現(xiàn)switch case(biz_type)走不同分支的代碼。

業(yè)務(wù)代碼上浮，通用代碼下沉，服務(wù)化徹底，只是一個(gè)很小的優(yōu)化點(diǎn)，但對(duì)于底層服務(wù)解耦卻是非常的有效。

知其然，知其所以然。

思路比結(jié)論更重要。