分佈式系統常見問題總結(二)

時間 2019-12-14

標籤分佈式系統常見問題總結欄目系統架構简体版

原文原文鏈接

分佈式系統常見問題總結(二)html

參考：前端

微信公衆號:架構師之路node

互聯網分層架構的本質

上圖是一個典型的互聯網分層架構：nginx

客戶端層：典型調用方是browser或者APPweb
站點應用層：實現核心業務邏輯，從下游獲取數據，對上游返回html或者json數據庫
數據-緩存層：加速訪問存儲編程
數據-數據庫層：固化數據存儲json

若是實施了服務化，這個分層架構圖多是這樣：後端

中間多了一個服務層。瀏覽器

同一個層次的內部，例如端上的APP，以及web-server，也都有進行MVC分層：

view層：展示
control層：邏輯
model層：數據

能夠看到，每一個工程師骨子裏，都潛移默化的實施着分層架構。

那麼，互聯網分層架構的本質到底是什麼呢？

若是咱們仔細思考會發現，無論是跨進程的分層架構，仍是進程內的MVC分層，都是一個「數據移動」，而後「被處理」和「被呈現」的過程，歸根結底一句話：互聯網分層架構，是一個數據移動，處理，呈現的過程，其中數據移動是整個過程的核心。

如上圖所示：

數據處理和呈現要CPU計算，CPU是固定不動的：

db/service/web-server都部署在固定的集羣上
端上，無論是browser仍是APP，也有固定的CPU處理

數據是移動的：

跨進程移動：數據從數據庫和緩存裏，轉移到service層，到web-server層，到client層
同進程移動：數據從model層，轉移到control層，轉移到view層

數據要移動，因此有兩個東西很重要：

數據傳輸的格式
數據在各層次的形態

先看數據傳輸的格式，即協議很重要：

service與db/cache之間，二進制協議/文本協議是數據傳輸的載體
web-server與service之間，RPC的二進制協議是數據傳輸的載體
client和web-server之間，http協議是數據傳輸的載體

再看數據在各層次的形態，以用戶數據爲例：

db層，數據是以「行」爲單位存在的row(uid, name, age)
cache層，數據是以kv的形式存在的kv(uid -> User)
service層，會把row或者kv轉化爲對程序友好的User對象
web-server層，會把對程序友好的User對象轉化爲對http友好的json對象
client層：最終端上拿到的是json對象

結論：互聯網分層架構的本質，是數據的移動。

爲何要說這個，這將會引出「分層架構演進」的核心原則與方法：

讓上游更高效的獲取與處理數據，複用
讓下游能屏蔽數據的獲取細節，封裝

弄清楚這個原則與方法，再加上一些經驗積累，就能回答網友常常在評論中提出的這些問題了：

是否須要引入DAO層，什麼時機引入
是否須要服務化，什麼時機服務化
是否須要抽取通用中臺業務，什麼時機抽取
是否須要先後端分離，什麼時機分離

（網友們的這些提問，其實很難回答。在不瞭解業務發展階段，業務規模，數據量併發量的狀況下，妄下YES或NO的結論，自己就是不負責任的。）

更具體的分層架構演進細節，下一篇和你們細究。

總結

互聯網分層架構的本質，是數據的移動
互聯網分層架構中，數據的傳輸格式（協議）與數據在各層次的形態很重要
互聯網分層架構演進的核心原則與方法：封裝與複用

互聯網分層架構之-DAO與服務化

互聯網分層架構的本質，是數據的移動。

互聯網分層架構演進的核心原則：

讓上游更高效的獲取與處理數據，複用
讓下游能屏蔽數據的獲取細節，封裝

這些在上一篇《互聯網分層架構的本質》中有詳盡的描述，在實際系統架構演進過程當中，如何利用這兩個原則，對系統逐步進行分層抽象呢？我們先從後端系統開始講解。

本文主要解答兩個問題：

後端架構，何時進行DAO層的抽象
後端架構，何時進行數據服務層的抽象

核心問題一：何時進行DAO層的抽象

一個業務系統最初的後端結構如上：

web-server層從db層獲取數據並進行加工處理
db層存儲數據

此時，web-server層如何獲取底層的數據呢？

web-server層獲取數據的一段僞代碼如上，不用糾結代碼的細節，也不用糾結不一樣編程語言與不一樣數據庫驅動的差別，其獲取數據的過程大體爲：

建立一個與數據庫的鏈接，初始化資源
根據業務拼裝一個SQL語句
經過鏈接執行SQL語句，並得到結果集
經過遊標遍歷結果集，取出每行數據，亦可從每行數據中取出屬性數據
關閉數據庫鏈接，回收資源

若是業務不復雜，這段代碼寫1次2次還能夠，但若是業務愈來愈複雜，每次都這麼獲取數據，就略顯低效了，有大量冗餘、重複、每次必寫的代碼。

如何讓數據的獲取更加高效快捷呢？

經過技術手段實現：

表與類的映射
屬性與成員的映射
SQL與函數的映射

絕大部分公司正在用的ORM，DAO等技術，就是一種分層抽象，能夠提升數據獲取的效率，屏蔽鏈接，遊標，結果集這些複雜性。

結論

當手寫代碼從DB中獲取數據，成爲通用痛點的時候，就應該抽象出DAO層，簡化數據獲取過程，提升數據獲取效率，向上遊屏蔽底層的複雜性。

核心問題二：何時要進行數據服務層的抽象

抽象出DAO層以後，系統架構並不會一成不變：

隨着業務愈來愈複雜，業務系統會不斷進行垂直拆分
隨着數據量愈來愈大，數據庫會進行水平切分
隨着讀併發的愈來愈大，會增長緩存下降數據庫的壓力

因而系統架構變成了這個樣子：

業務系統垂直拆分，數據庫水平切分，緩存這些都是常見的架構優化手段。

此時，web-server層如何獲取底層的數據呢？

根據樓主的經驗，以用戶數據爲例，流程通常是這樣的：

先查緩存：先用uid嘗試從緩存獲取數據，若是cache hit，數據獲取成功，返回User實體，流程結束
肯定路由：若是cache miss，先查詢路由配置，肯定uid落在哪一個數據庫實例的哪一個庫上
查詢DB：經過DAO從對應庫獲取uid對應的數據實體User
插入緩存：將kv(uid, User)放入緩存，以便下次緩存查詢數據可以命中緩存

若是業務不復雜，這段代碼寫1次2次還能夠，但若是業務愈來愈複雜，每次都這麼獲取數據，就略顯低效了，有大量冗餘、重複、每次必寫的代碼。

特別的，業務垂直拆分紅很是多的子系統以後：

一旦底層有稍許變化，全部上游的系統都須要升級修改
子系統之間極可能出現代碼拷貝
一旦拷貝代碼，出現一個bug，多個子系統都須要升級修改

不相信業務會垂直拆分紅多個子系統？舉兩個例子：

58同城有招聘、房產、二手、二手車、黃頁等5大頭部業務，都須要訪問用戶數據
58到家有月嫂、保姆、麗人、速運、平臺等多個業務，也都須要訪問用戶數據

若是每一個子系統都須要關注緩存，分庫，讀寫分離的複雜性，調用層會瘋掉的。

如何讓數據的獲取更加高效快捷呢？

服務化，數據服務層的抽象勢在必行。

經過抽象數據服務層：

web-server層能夠經過RPC接口，像調用本地函數同樣調用遠端的數據
數據服務層，只有這一處須要關注緩存，分庫，讀寫分離這些複雜性

服務化這裏就不展開，更詳細的可參考《互聯網架構爲何要作服務化？》。

結論

當業務愈來愈複雜，垂直拆分的系統愈來愈多，數據庫實施了水平切分，數據層實施了緩存加速以後，底層數據獲取複雜性成爲通用痛點的時候，就應該抽象出數據服務層，簡化數據獲取過程，提升數據獲取效率，向上遊屏蔽底層的複雜性。

互聯網分層架構是一個頗有意思的問題，服務化的引入，並非越早越好：

請求處理時間可能會增長
運維可能會更加複雜
定位問題可能會更加麻煩

千萬別魯莽的在「微服務」大流之下，草率的進行微服務改造，看似「高大上架構」的背後，隱藏着更多並未接觸過的「大坑」。仍是那句話，架構和業務的特色和階段有關：一切脫離業務的架構設計，都是耍流氓。

這一篇先到這裏，分層架構，還有不少內容要和你們聊：

後端架構，是否須要抽取中臺業務，什麼時機抽取
後端架構，是否須要先後端分離，什麼時機分離
前端架構，如何進行分層實踐

末了，再次強調下，互聯網分層架構的本質，是數據的移動。

互聯網分層架構演進的核心原則，是讓上游更高效的獲取與處理數據，讓下游能屏蔽掉數據的複雜性獲取細節。

互聯網架構爲何要作服務化？

近期參加一些業界的技術大會，「微服務架構」的話題很是之火，也在一些場合聊過服務化架構實踐，最近幾期文章指望用通俗易懂的語言聊聊了我的對服務化以及微服務架構的理解，但願能給大夥一些啓示。若是有遺漏，也歡迎你們補充。

1、互聯網高可用架構，爲何要服務化？

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

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

（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多個業務表 =_=）。

【架構痛點六：…】

2、服務化解決什麼問題？

爲了解決上面的諸多問題，互聯網高可用分層架構演進的過程當中，引入了「服務層」。

以上文中的用戶業務爲例，引入了user-service，對業務線響應所用用戶數據的存取。引入服務層有什麼好處，解決什麼問題呢？

【好處一：調用方爽】

有服務層以前：業務方訪問用戶數據，須要經過DAO拼裝SQL訪問

有服務層以後：業務方經過RPC訪問用戶數據，就像調用一個本地函數同樣，很是之爽

User = UserService::GetUserById(uid);

傳入一個uid，獲得一個User實體，就像調用本地函數同樣，不須要關心序列化，網絡傳輸，後端執行，網絡傳輸，範序列化等複雜性。

【好處二：複用性，防止代碼拷貝】

這個不展開敘述，全部user數據的存取，都經過user-service來進行，代碼只此一份，不存在拷貝。

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

【好處三：專一性，屏蔽底層複雜度】

在沒有服務層以前，全部業務線都須要關注緩存、分庫分表這些細節。

在有了服務層以後，只有服務層須要專一關注底層的複雜性了，向上遊屏蔽了細節。

【好處四：SQL質量獲得保障】

原來是業務向上遊直接拼接SQL訪問數據庫。

有了服務層以後，全部的SQL都是服務層提供的，業務線不能再隨心所欲了。底層服務對於穩定性的要求更好的話，能夠由更資深的工程師維護，而不是像原來SQL難以收口，難以控制。

【好處五：數據庫解耦】

原來各個業務的數據庫都混在一個大庫裏，相互join，難以拆分。

服務化以後，底層的數據庫被隔離開了，能夠很方便的拆分出來，進行擴容。

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

在服務化以前，各業務線上遊想怎麼操縱數據庫都行，遇到了性能瓶頸，各業務線容易扯皮，相互推諉。

服務化以後，服務只提供有限的通用接口，理論上服務集羣可以提供無限性能，性能出現瓶頸，服務層一處集中優化。

啊，業務層是否也須要服務化？

《互聯網分層架構的本質》簡述了兩個觀點：

互聯網分層架構的本質，是數據的移動
互聯網分層架構演進的核心原則：是讓上游更高效的獲取與處理數據，讓下游能屏蔽數據的獲取細節

《分層架構：何時抽象DAO層，何時抽象數據服務層》中的觀點是：

當手寫代碼從DB中獲取數據，成爲通用痛點的時候，就應該抽象出DAO層，簡化數據獲取過程，提升數據獲取效率，向上遊屏蔽底層的複雜性
當業務愈來愈複雜，垂直拆分的系統愈來愈多，數據庫實施了水平切分，數據層實施了緩存加速以後，底層數據獲取複雜性成爲通用痛點的時候，就應該抽象出數據服務層，簡化數據獲取過程，提升數據獲取效率，向上遊屏蔽底層的複雜性

文本將要解答的問題是：