有朋友在社群問我，大家都在做微服務，到底怎么做服務化？

朋友，或許你問錯了問題，“怎么做”之前，先得了解“為什么做”，“大家都在做”，并不是我們也要做的理由。

并不是所有的業務都適合“服務化”，互聯網高可用架構，到底為什么要服務化？

服務化之前，高可用架構是什么樣的？

服務化之前，互聯網的典型高可用架構如下：

• 端，APP，H5，小程序，PC瀏覽器；
• 后端入口，高可用的反向代理nginx集群；
• 站點應用，高可用的web-server集群；
• 后端存儲，高可用db集群；

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

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

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

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

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

架構痛點二：復雜性擴散。

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

對于寫請求，所有業務線都要升級代碼：

• 先淘汰cache；
• 再寫db；

對于讀請求，所有業務線也都要升級代碼：

• 先讀cache，命中則返回；
• 沒命中則讀db；
• 再把數據放入cache；

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

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

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

典型的耦合，還包括bug的修改，發現一個bug，多個地方都需要修改。

架構痛點三：SQL質量無法保障，業務相互影響。

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

假如業務線A寫了一個全表掃描的SQL，導致數據庫的CPU100%，影響的不只是一個業務線，而是所有的業務線都會受影響。

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

架構痛點四：瘋狂的DB耦合。

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

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

典型的，通過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多個業務表 =_=）。

服務化后，高可用架構如何？

互聯網高可用分層架構演進的過程中，引入了“服務層”。

以上文中的用戶業務為例，引入了高可用user-service，對業務線響應所用用戶數據的存取。

引入服務層有什么好處，到底解決什么問題呢？

好處一：調用方爽。

有服務層之前，業務方訪問用戶數據，需要通過DAO拼裝SQL訪問。

有服務層之后，業務方通過RPC訪問用戶數據，就像調用一個本地函數一樣，非常之爽：

User = UserService::GetUserById(uid);

傳入一個uid，得到一個User實體，就像調用本地函數一樣，不需要關心序列化，網絡傳輸，后端執行，網絡傳輸，反序列化等復雜性。

好處二：復用性，防止代碼拷貝。

所有user數據的存取，都通過user-service來進行，代碼只此一份，不存在拷貝。升級一處升級，bug修改一處修改。

好處三：專注性，屏蔽底層復雜度。

在沒有服務層之前，所有業務線都需要關注緩存、分庫分表這些細節。

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

好處四：SQL質量得到保障。

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

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

好處五：數據庫解耦。

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

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

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

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

服務化之后，服務只提供有限的通用接口，理論上服務集群能夠提供無限性能，性能出現瓶頸，服務層一處集中優化。

服務化不能解決所有問題，如果沒有碰到這些問題，架構未必需要服務化。一切脫離業務的架構設計，都是耍流氓。

知其然，知其所以然。

思路比結論更重要。