近期參加一些業(yè)界的技術(shù)大會， “ 微服務(wù)架構(gòu) ” 的話題非常之火，也在一些場合聊過服務(wù)化架構(gòu)實踐，最近幾期文章期望用通俗易懂的語言聊聊了個人對服務(wù)化以及微服務(wù)架構(gòu)的理解，希望能給大伙一些啟示。 如果有遺漏，也歡迎大家補充 。

一、互聯(lián)網(wǎng)高可用架構(gòu)，為什么要服務(wù)化？

【服務(wù)化之前高可用架構(gòu)】

在服務(wù)化之前，互聯(lián)網(wǎng)的高可用架構(gòu)大致是這樣一個架構(gòu)：

（ 1 ）用戶端是瀏覽器 browser ， APP 客戶端

（ 2 ）后端入口是高可用的 nginx 集群，用于做反向代理

（ 3 ）中間核心是高可用的 web-server 集群， 研發(fā)工程師主要編碼工作就是在這一層

（ 4 ）后端存儲是高可用的 db 集群，數(shù)據(jù)存儲在這一層

更典型的， 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ù)雜性 ：

對于用戶數(shù)據(jù)的寫請求，所有業(yè)務(wù)線都要升級代碼：

（ 1 ）先淘汰 cache

（ 2 ）再寫數(shù)據(jù)

對于用戶數(shù)據(jù)的讀請求，所有業(yè)務(wù)線也都要升級代碼：

（ 1 ）先讀 cache ，命中則返回

（ 2 ）沒命中則讀數(shù)據(jù)庫

（ 3 ）再把數(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 ，負責(zé)整個用戶數(shù)據(jù)的存取，從而避免代碼的拷貝。至于復(fù)雜性，也只有 user.so 這一個地方需要關(guān)注了。

解決了舊的問題，會引入新的問題， 庫的版本維護與業(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)”的升級，非常郁悶。當(dāng)然，如果各個業(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ù)：

典型的，通過 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ù)化解決什么問題？

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

以上文中的用戶業(yè)務(wù)為例，引入了 user-service ，對業(yè)務(wù)線響應(yīng)所用用戶數(shù)據(jù)的存取。引入服務(wù)層有什么好處，解決什么問題呢？

【好處一：調(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ù)雜性。

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

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

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

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

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

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

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

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

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

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

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

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

【好處六：提供有限接口，無限性能】

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

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

來自：http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651959519&idx=1&sn=065074b135fc9cb243abe897261e1a72&scene=0