互聯(lián)網(wǎng)架構(gòu)，究竟為啥要做服務(wù)化？

“微服務(wù)架構(gòu)”的話題非常之火，很多朋友都在小窗我，說怎么做服務(wù)化?解答“怎么做”之前，先得了解“為什么做”。

畫外音：做技術(shù)千萬不能是這種思路，“別人都在做，所以我們也要搞”。

并不是所有的業(yè)務(wù)都適合“服務(wù)化”，互聯(lián)網(wǎng)高可用架構(gòu)，到底為什么要服務(wù)化?

服務(wù)化之前，高可用架構(gòu)是什么樣的?

在服務(wù)化之前，互聯(lián)網(wǎng)的典型高可用架構(gòu)如下：

客戶端，APP，H5，小程序，PC瀏覽器;后端入口，高可用的反向代理nginx集群;站點應(yīng)用，高可用的web-server集群;后端存儲，高可用db集群;

更典型的，web-server集群通過DAO/ORM等技術(shù)來訪問數(shù)據(jù)庫。

可以看到，最初是沒有服務(wù)層的，此時架構(gòu)會碰到什么典型痛點呢?

架構(gòu)痛點一：代碼到處拷貝

舉一個最常見的業(yè)務(wù)例子，用戶數(shù)據(jù)訪問，絕大部分公司都有一個數(shù)據(jù)庫存儲用戶數(shù)據(jù)，各個業(yè)務(wù)都有訪問用戶數(shù)據(jù)的需求。

在有用戶服務(wù)之前，各個業(yè)務(wù)線都是自己通過DAO寫SQL訪問user庫來存取用戶數(shù)據(jù)，這無形中就導(dǎo)致了代碼的拷貝。

架構(gòu)痛點二：復(fù)雜性擴散

隨著并發(fā)量的越來越高，用戶數(shù)據(jù)的訪問數(shù)據(jù)庫成了瓶頸，需要加入緩存來降低數(shù)據(jù)庫的讀壓力，于是架構(gòu)中引入了緩存，如果沒有統(tǒng)一的服務(wù)層，各個業(yè)務(wù)線都需要關(guān)注緩存的引入導(dǎo)致的復(fù)雜性。

對于寫請求，所有業(yè)務(wù)線都要升級代碼：

先淘汰cache;再寫db;對于讀請求，所有業(yè)務(wù)線也都要升級代碼：

先讀cache，命中則返回;沒命中則讀db;再把數(shù)據(jù)放入cache;這個復(fù)雜性是典型的“業(yè)務(wù)無關(guān)”的復(fù)雜性，業(yè)務(wù)方需要被迫升級。

隨著數(shù)據(jù)量的越來越大，數(shù)據(jù)庫需要進行水平拆分，于是架構(gòu)中又引入了分庫分表，如果沒有統(tǒng)一的服務(wù)層，各個業(yè)務(wù)線都需要關(guān)注分庫分表的引入導(dǎo)致的復(fù)雜性。

這個復(fù)雜性也是典型的“業(yè)務(wù)無關(guān)”的復(fù)雜性，業(yè)務(wù)方需要被迫升級。

典型的耦合，還包括bug的修改，發(fā)現(xiàn)一個bug，多個地方都需要修改。

架構(gòu)痛點三：庫的復(fù)用與耦合

服務(wù)化并不是唯一的解決上述兩痛點的方法，抽象出統(tǒng)一的“庫”是最先容易想到的解決(1)代碼拷貝;(2)復(fù)雜性擴散;的方法。

抽象出一個user.so，負責整個用戶數(shù)據(jù)的存取，從而避免代碼的拷貝。至于復(fù)雜性，也只有user.so這一個地方需要關(guān)注了。

解決了舊的問題，會引入新的問題，庫的版本維護會導(dǎo)致業(yè)務(wù)線之間的耦合。

業(yè)務(wù)線A將user.so由版本1升級至版本2，如果不兼容業(yè)務(wù)線B的代碼，會導(dǎo)致B業(yè)務(wù)出現(xiàn)問題。

業(yè)務(wù)線A如果通知了業(yè)務(wù)線B升級，則是的業(yè)務(wù)線B會無故做一些“自身業(yè)務(wù)無關(guān)”的升級，非常郁悶。當然，如果各個業(yè)務(wù)線都是拷貝了一份代碼則不存在這個問題。

畫外音：有時候拷貝代碼也是有好處的。

架構(gòu)痛點四：SQL質(zhì)量無法保障，業(yè)務(wù)相互影響

業(yè)務(wù)線通過DAO訪問數(shù)據(jù)庫，本質(zhì)上SQL語句還是各個業(yè)務(wù)線拼裝的，資深的工程師寫出高質(zhì)量的SQL，經(jīng)驗沒有這么豐富的工程師可能會寫出一些低效的SQL。

假如業(yè)務(wù)線A寫了一個全表掃描的SQL，導(dǎo)致數(shù)據(jù)庫的CPU100%，影響的不只是一個業(yè)務(wù)線，而是所有的業(yè)務(wù)線都會受影響。

畫外音：臨時工程序員要背鍋了。

架構(gòu)痛點五：瘋狂的DB耦合

業(yè)務(wù)線不只訪問user數(shù)據(jù)，還會結(jié)合自己的業(yè)務(wù)訪問自己的數(shù)據(jù)。

畫外音：user_biz表，也是用uid做主鍵。

典型的，通過join數(shù)據(jù)表來實現(xiàn)各自業(yè)務(wù)線的一些業(yè)務(wù)邏輯。

業(yè)務(wù)線A的table-user與table-A耦合在了一起，業(yè)務(wù)線B的table-user與table-B耦合在了一起，業(yè)務(wù)線C的table-user與table-C耦合在了一起，結(jié)果就是：table-user，table-A，table-B，table-C都耦合在了一起。

隨著數(shù)據(jù)量的越來越大，業(yè)務(wù)線ABC的數(shù)據(jù)庫是無法垂直拆分開的，必須使用一個大庫(瘋了，一個大庫300多個業(yè)務(wù)表 =_=)。

架構(gòu)痛點六：…

服務(wù)化后，高可用架構(gòu)如何?

互聯(lián)網(wǎng)高可用分層架構(gòu)演進的過程中，引入了“服務(wù)層”。

以上文中的用戶業(yè)務(wù)為例，引入了高可用user-service，對業(yè)務(wù)線響應(yīng)所用用戶數(shù)據(jù)的存取。

引入服務(wù)層有什么好處，到底解決什么問題呢?

(1) 好處一：調(diào)用方爽

有服務(wù)層之前，業(yè)務(wù)方訪問用戶數(shù)據(jù)，需要通過DAO拼裝SQL訪問。

有服務(wù)層之后，業(yè)務(wù)方通過RPC訪問用戶數(shù)據(jù)，就像調(diào)用一個本地函數(shù)一樣，非常之爽：

User = UserService::GetUserById(uid);

傳入一個uid，得到一個User實體，就像調(diào)用本地函數(shù)一樣，不需要關(guān)心序列化，網(wǎng)絡(luò)傳輸，后端執(zhí)行，網(wǎng)絡(luò)傳輸，范序列化等復(fù)雜性。

(2) 好處二：復(fù)用性，防止代碼拷貝

所有user數(shù)據(jù)的存取，都通過user-service來進行，代碼只此一份，不存在拷貝。

升級一處升級，bug修改一處修改。

(3) 好處三：專注性，屏蔽底層復(fù)雜度

在沒有服務(wù)層之前，所有業(yè)務(wù)線都需要關(guān)注緩存、分庫分表這些細節(jié)。

在有了服務(wù)層之后，只有服務(wù)層需要專注關(guān)注底層的復(fù)雜性了，向上游屏蔽了細節(jié)。

(4) 好處四：SQL質(zhì)量得到保障

原來是業(yè)務(wù)向上游直接拼接SQL訪問數(shù)據(jù)庫。

有了服務(wù)層之后，所有的SQL都是服務(wù)層提供的，業(yè)務(wù)線不能再為所欲為了。底層服務(wù)對于穩(wěn)定性的要求更好的話，可以由更資深的工程師維護，而不是像原來SQL難以收口，難以控制。

(5) 好處五：數(shù)據(jù)庫解耦

原來各個業(yè)務(wù)的數(shù)據(jù)庫都混在一個大庫里，相互join，難以拆分。

服務(wù)化之后，底層的數(shù)據(jù)庫被隔離開了，可以很方便的拆分出來，進行擴容。

(6) 好處六：提供有限接口，無限性能

在服務(wù)化之前，各業(yè)務(wù)線上游想怎么操縱數(shù)據(jù)庫都行，遇到了性能瓶頸，各業(yè)務(wù)線容易扯皮，相互推諉。

服務(wù)化之后，服務(wù)只提供有限的通用接口，理論上服務(wù)集群能夠提供無限性能，性能出現(xiàn)瓶頸，服務(wù)層一處集中優(yōu)化。

(7) 好處七：…

服務(wù)化不能解決所有問題，如果沒有碰到這些問題，架構(gòu)未必需要服務(wù)化。

一切脫離業(yè)務(wù)的架構(gòu)設(shè)計，都是耍流氓。

希望大家有收獲。