互聯網架構為什么要做服務化？

CatBach 8年前發布 | 135K 次閱讀數據庫軟件架構

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

一、互聯網高可用架構，為什么要服務化？

【服務化之前高可用架構】

在服務化之前，互聯網的高可用架構大致是這樣一個架構：

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

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

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

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

更典型的， web-server 層是通過 DAO/ORM 等技術來訪問數據庫的。

可以看到，最初都是沒有服務層的，此時架構會碰到一些什么痛點呢？

【架構痛點一：代碼到處拷貝】

舉一個最常見的業務的例子 -> 用戶數據的訪問，絕大部分公司都有一個數據庫存儲用戶數據，各個業務都有訪問用戶數據的需求：

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

【架構痛點二：復雜性擴散】

隨著并發量的越來越高，用戶數據的訪問數據庫成了瓶頸，需要加入緩存來降低數據庫的讀壓力，于是架構中引入了緩存，由于沒有統一的服務層，各個業務線都需要關注緩存的引入導致的復雜性：

對于用戶數據的寫請求，所有業務線都要升級代碼：

（ 1 ）先淘汰 cache

（ 2 ）再寫數據

對于用戶數據的讀請求，所有業務線也都要升級代碼：

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

（ 2 ）沒命中則讀數據庫

（ 3 ）再把數據放入 cache

這個復雜性是典型的“業務無關”的復雜性，業務方需要被迫升級。

隨著數據量的越來越大，數據庫需要進行水平拆分，于是架構中又引入了分庫分表，由于沒有統一的服務層，各個業務線都需要關注分庫分表的引入導致的復雜性：

這個復雜性也是典型的“業務無關”的復雜性，業務方需要被迫升級。

包括 bug 的修改，發現一個 bug ，多個地方都需要修改。

【架構痛點三：庫的復用與耦合】

服務化并不是唯一的解決上述兩痛點的方法，抽象出統一的 “ 庫 ” 是最先容易想到的解決：

（ 1 ）代碼拷貝

（ 2 ）復雜性擴散

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

解決了舊的問題，會引入新的問題，庫的版本維護與業務線之間代碼的耦合：

業務線 A 將 user.so 由版本 1 升級至版本 2 ，如果不兼容業務線 B 的代碼，會導致 B 業務出現問題；

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

【架構痛點四： SQL 質量得不到保障，業務相互影響】

業務線通過 DAO 訪問數據庫：

本質上 SQL 語句還是各個業務線拼裝的，資深的工程師寫出高質量的 SQL 沒啥問題，經驗沒有這么豐富的工程師可能會寫出一些低效的 SQL ，假如業務線 A 寫了一個全表掃描的 SQL ，導致數據庫的 CPU100% ，影響的不只是一個業務線，而是所有的業務線都會受影響。

【架構痛點五：瘋狂的 DB 耦合】

業務線不至訪問 user 數據，還會結合自己的業務訪問自己的數據：

典型的，通過 join 數據表來實現各自業務線的一些業務邏輯。

這樣的話，業務線 A 的 table-user 與 table-A 耦合在了一起，業務線 B 的 table-user 與 table-B 耦合在了一起，業務線 C 的 table-user 與 table-C 耦合在了一起，結果就是： table-user ， table-A ， table-B ， table-C 都耦合在了一起。

隨著數據量的越來越大，業務線 ABC 的數據庫是無法垂直拆分開的，必須使用一個大庫（瘋了，一個大庫 300 多個業務表 =_= ）。

【架構痛點六： … 】