沈劍聊微服務：先做好你的服務拆分

嘉賓 沈劍

編輯 雨多田光

標籤 微服務

隨著自動化運維等相關技術的發展，微服務變得更容易管理，這給了微服務架構良好的發展機會；同時，Docker 等容器技術的發展，使微服務架構的落地變得更加方便，這更是為其成為主流技術鋪好了道路。目前各家對微服務架構都有自己的理解與落地實踐。

本次 InfoQ 採訪到 58 到家技術委員會主席沈劍老師，請他講講他對微服務架構的一些思考。沈劍老師之前任職於 58 到家，目前在 58 速運，本次分享涉及到 58 到家與 58 速運的相關內容。本文即由採訪整理而成。

本次分享主要從服務化的角度來看待微服務，主要是梳理一下微服務這個概念，不做深入地講解。

從服務化的角度看微服務

互聯網架構發展的過程中，當業務複雜度劇增，數據量劇增，吞吐量劇增的時候，就會出現一些技術痛點，下邊幾個都是最常見的：

痛點一：代碼到處拷貝

舉一個最常見的業務的例子：用戶數據的訪問。

絕大部分公司都有一個資料庫用來存儲用戶數據，而各個業務都有訪問用戶數據的需求。

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

抽象出一個服務層之後，有統一的一份代碼，那麼就解決了代碼復用的問題。同時業務方通過 RPC 訪問用戶數據，就像調用一個本地函數一樣，比如使用

傳入一個 uid，得到一個 User 實體，就像調用本地函數一樣，不需要關心序列化、後端執行、網路傳輸、反序列化等複雜性，方便高效。

痛點二：複雜性擴散

這個內容主要講一下下邊兩個點：

1、緩存導致的複雜性

隨著訪問量越來越高，資料庫成了瓶頸，需要加入緩存來降低資料庫的讀寫壓力，於是架構中引入了緩存，由於沒有統一的服務層，各個業務線都需要關注緩存的引入導致的複雜性：

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

1、先淘汰 cache

2、再寫數據

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

1、先讀 cache，命中則返回

2、沒命中則讀資料庫

3、再把數據放入 cache

這個複雜性是典型的「業務無關」的複雜性，業務方需要被迫升級。

2、分庫分表導致的複雜性

數據量越來越大，資料庫需要進行水平拆分，於是架構中又引入了分庫分表，這時又是由於沒有統一的服務層，各個業務線都需要關注分庫分表的引入導致的複雜性。

這個複雜性也是典型的「業務無關」的複雜性，業務方需要被迫升級。

有了服務層之後，只有服務層需要專註關注底層的複雜性了，向上游屏蔽了細節。

痛點三：庫的復用與耦合

服務化並不是唯一解決上述兩個痛點的方法，另一種方法是抽象出統一的「庫」。比如抽象出一個 user.so，負責整個用戶數據的存取，從而避免代碼的拷貝。至於複雜性，現在也只剩下 user.so 這一個地方需要關注了。

但是這時候會引入新的問題：庫的版本維護與業務線之間代碼的耦合。

比如業務線 A 將 user.so 由版本 1 升級至版本 2，如果不兼容業務線 B 的代碼，那就會導致 B 業務出現問題；業務線 A 如果通知了業務線 B 升級，這時的業務線 B 就會去升級，但這是與它「自身業務無關」的升級。

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

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

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

痛點五：瘋狂的 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 都耦合在了一起。

服務化之後，底層的資料庫被隔離開了，可以很方便的拆分出來，進行擴容。

像上邊說的，服務層就是在這樣的情況下被抽象出來的。概括起來，它就是用來統一完成一部分數據訪問或者子業務邏輯。這就是指服務化。

而從這個角度來看，微服務本質上就是指粒度比較細的服務化的實施。

具體到 58 到家 /58 速運

就像上邊說的，隨著業務越來越複雜，數據量越來越大，並發量越來越大，58 到家因為經歷了這些階段，所以系統架構走上了微服務之路。

具體來說，15 年的時候，58 到家的架構碰到了類似的種種問題：

垂直業務擴展，家政、麗人、速運、平台，一些相似的業務代碼拷貝越來越嚴重

數據量、並發量提升，底層架構複雜性不斷向上游擴散，所有調用方都需要關注緩存、分庫、存儲引擎等，效率逐步降低

jar 包耦合，多個系統依賴一個公用的 jar 包，一個業務升級導致兼容性問題，影響其他業務

資料庫耦合，多個業務公用一個資料庫，相互耦合，相互影響

SQL 質量低，業務相互耦合，一個業務撰寫了一個低質量的 SQL，導致其他業務受影響

其實我們也不是一開始就直接採用微服務架構，這個也是經過了不同階段而演進出來的。

簡單地說，58 到家剛開始的時候，我們先找到通用痛點，抽象出通用數據訪問與子業務，然後將它們下沉成微服務。

更具體地，早期 58 到家是抽象出用戶中心，訂單中心，支付中心等來構建微服務的。

我們從 58 速運的角度來講，剛開始 58 到家是大一統階段，就是系統沒有進行業務拆分的時候，因為剛開始業務量也小，所以它還是可行的。

後來整個系統拆分成了站點、資料庫、緩存這三個部分。

接著我們進行了垂直拆分，將平台、家政、麗人、速運這些業務拆分開來。

然後就具體到速運這一塊進行服務化架構。

而最近我們還在演進這樣一個架構，我們知道速運這一塊其實它本身也有多個業務形態，有對小 C 的，有對小 B 的。小 C 是搬家服務，小 B 是貨的服務，大 B 是優配服務。原來這三塊它們都是耦合在一起的，現在也在進行拆分。

這其實也就是架構演進過程中必然會出現的，而具體再討論下去，其實就是在做一些微服務架構上的事情了。

上邊這些說的都是業務的垂直拆分，下邊看一下我們的系統分層情況是怎麼樣的。

我們現在的系統分成了四層，如下：

第一層：站點平台

第二層：業務服務層。把基礎數據通用的東西往上抽，就像上邊說的，比如它解決代碼拷備的痛點，不能讓代碼拷來拷去，所以把這份代碼抽象成一個服務。解決庫的耦合，如果之前沒有服務化，可能用代碼庫，用 jar 包、DLL、SO 庫來解決代碼拷備這個問題，一個庫，多個服務依賴，那庫的版本升級，影響範圍很大，可能多個服務因為一個庫的原因耦合在一起。上邊說的這些就是發生在這個層上，它解決的是底層複雜性屏蔽的問題。如果沒有服務層，那麼牽一髮而動全身。

第三層：基礎數據服務層。不包含複雜的業務邏輯，只是數據訪問的代理，對資料庫層的 CRUD。原來設計為相對簡單的「DAO 層」。

第四層：數據層。數據層包括緩存和 DB。

最開始的時候是沒有業務服務層的，業務應用分別直接訪問資料庫，導致大量耦合；架構演進到第二個階段的時候，我們抽象出一些通用的業務無關的基礎服務，例如地理位置服務、經緯度服務、短網址服務、簡訊服務等；到了第三個階段，我們抽象出一些通用業務的服務，例如 passport 服務、訂單中心服務、支付中心服務等；未來，我們會進一步去抽象更多的通用業務服務。總之，整個微服務架構演進的思路就是：「共性 + 通用痛點」抽象下沉。

需要關注的問題

很多架構師只看到微服務的好處，但其實微服務會導致增加系統運維的複雜性，增加配置文件的複雜性，加大追查問題與監控系統的難度。為了解決這些問題，需要有配套的技術體系支撐，例如：引入自動化上線平台解決運維複雜性問題，引入配置中心解決配置耦合的問題，引入監控平台與調用鏈平台解決監控與問題追查的問題。微服務體系，需要有一系列技術基礎設施配套，而不只是引入一個簡單的服務框架，而這些配套的技術基礎設施，往往比服務框架本身複雜得多。

微服務體系配套基礎設施包括但是不限於以下這些東西：

配置中心，解除系統之間因為配置文件導致的耦合，做邏輯上解耦（但物理上仍然保持上下游連接）

消息中心，解除系統之間調用關係導致的耦合，做邏輯上與物理上的雙重解耦（物理上不再相互連接）

監控中心，立體化監控，實施機器、進程、介面、日誌、用戶層面多維度監控，及早發現問題

調用鏈跟蹤系統，圖形化，量化展現請求在系統中的調用路徑，及早定位問題

一個重要的原則

像上邊提到的，在微服務架構的實施過程中，抓住「共性」與「通用痛點」下沉，是一個最常見的原則。這裡簡單地再以 58 到家為例做一下總結。家政、麗人、速運各個業務都有自己的賬戶體系、訂單體系、支付體系，這樣成本顯然是較高的，複雜性成本也是會不斷增加的。對於這樣的一些通用業務，就應該抽象出 passport 服務統一解決 SSO（Single Sign-On）問題；抽象出訂單中心服務解決訂單的集中存儲與展現問題；抽象出支付中心服務來統一解決微信與支付寶的對接，統一解決對賬等問題。

寄 語

關注業務比研究架構更重要，任何脫離業務的架構設計都是耍流氓。找痛點、解決痛點比高瞻遠矚重要，架構是演進而來的，而不是設計而來的。幾點個人淺見，共勉。

今日薦文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！