微服務架構一直火，為什麼服務化要搞懂？

泥瓦匠發表於2019-09-19
微服務架構

微服務架構，這 5 年左右一直被認可，是軟體架構的未來方向。需要大家理解的是，為什麼需要服務化。比如微服務架構對企業來說，帶來什麼價值？有啥弊端？

這裡淺談一下微服務架構，主要還是在理解 Why ：為什麼需要服務化？

一、對微服務架構的理解

1.1 微服務架構

file

微服務架構，主要是多了個 “微”。亞馬遜有個粗粗的定義：一個微服務應用工程的所有開發、測試、運維加起來大約 6 到 8 個人，只需要兩個披薩就可以聚餐了。

反例：不是一個 Service 類組成的應用工程，釋出成服務就是微服務。這樣分的太小，理解微服務就很片面。杭州某金融大廠，曾經分的很細，造成了運維測試成本巨大。開始分了合，折騰...

1.2 為啥需要微服務？

由 SOA 架構 -> 微服務架構的轉變，得理解為什麼微服務架構被廣泛提到並實踐。它解決了什麼問題，帶來了什麼價值？

傳統企業或者很多企業的軟體，大多不止一套系統，都是各個獨立大系統的堆砌。整體存在的問題是：

  • 擴充套件性差
  • 可靠性不高
  • 維護成本還很大
  • 重複輪子很多

file

那麼這些問題，可以想到的解決方案就是：

  • 元件化
  • 服務化

微服務架構，將各個元件或者模組分散到各個服務中，對整個系統實現解耦。那微服務架構強調的重中之重就是業務系統需要完善的元件化和服務化。什麼是元件化？

元件化，即將一個大系統，按照一定的業務或者技術維度關注形式，拆分成獨立的元件。目的是為了分而治之，為了可重用，為了減少耦合度。比如按照技術維度：搜尋元件、快取元件；按照業務維度：使用者中心、支付中心等

file

元件化是不是有點中臺的意思？阿里巴巴提出 大中臺，小前臺；就是把元件化、外掛化、服務化解決方案到極致。通過產品線公共業務或者技術下沉，形成各種技術或者業務中臺

file

（圖來自漫畫程式設計師小灰）

二、服務化前的問題

2.1 沒有服務化，不代表不是分散式或叢集

分散式，就是多個例項提供相同的服務。比如多個地方動車站裡面，多個機器提供取票服務。多個地方，北京上海等，就是多機房，多個取票服務一起組成了叢集，形成分散式服務。那啥是服務化？

服務化，強調 “化”！核心就是不同服務之間的通訊。是一種以服務為中心的解決方案：

  • 服務註冊
  • 服務釋出
  • 服務呼叫
  • 服務監控
  • 服務負載均衡
  • 等等

file

2.2 沒有服務化的架構問題

沒有服務化前，舉個例子，會更形象：

假設有個取票服務、買票服務、改座服務都需要驗證下使用者身份真實性，那麼會存在下面的問題：

  • 取票服務 -> 呼叫使用者DB程式碼 -> 使用者DB
  • 買票服務 -> 呼叫使用者DB程式碼 -> 使用者DB
  • 改座服務 -> 呼叫使用者DB程式碼 -> 使用者DB

file

明顯的問題是：

  • 程式碼重複：不同業務相同訪問 DB 的 userDAO 程式碼邏輯。而且每個服務這塊程式碼是不同人維護的。
  • 可維護性低：不同人維護；不同地方維護；每次 DB 欄位改變或者遷庫，全部業務都有修改
  • DB 訪問耦合

自然也有解決方案是：lib。維護一個 user-DAO-lib 1.0.0 release 包，給各個業務方。

解決了問題，引入了新的問題，lib 升級是巨大而又漫長的問題。比如小李是維護 user-DAO-lib 的人，有一次寫了隱蔽的 bug 。user-lib 升級到了 1.0.1 release，花了 1 個月左右時間，推幾十個業務方升級完畢。然後這個 bug 執行了幾天出現了，考慮升級fix或者回滾都是巨大的成本

基於服務化，就可以完美解決問題。

三、服務化後的好處

file

如圖 Post 文章服務呼叫 Video 視訊服務，需要通過最上層的 Service 之間相互呼叫。服務化明顯改變：

  • DB 隔離：這樣底層細節設計可以遮蔽，後續加上其他儲存 Cache 等對業務呼叫方無感知。
  • 通過 Service 之間通訊：具體協議可以 RPC / HTTP 等

服務化後的好處：

  • 呼叫簡單：不用寫相同的訪問使用者服務程式碼，呼叫一個服務即可
  • 程式碼複用：跟 lib 形式的程式碼複用有所區別在於，服務化通過通訊的方式解決
  • 業務隔離
  • 資料庫解耦
  • 等等

四、不可否認的微服務架構或者服務化帶來新的問題

1、本身不大的系統，業務不復雜的系統也不需要微服務架構。微服務架構會帶來一定的複雜性，是一套完整的服務治理方案
2、多個模組資料庫，分散式事務是一個挑戰
3、開發過程，增加了測試等一定的複雜性

有利必有弊，具體場景具體選擇

五、小結

本小結，不是講how，講的是 why。只有懂 why ，才能更好地 do。從為啥服務化？到為啥微服務架構這麼流行：

  • 微服務擴充套件性高
  • 微服務可靠性高
  • 微服務 維護成本小
  • 微服務幾乎沒有重複輪子
  • 微服務直接呼叫呼叫簡單
  • 微服務業務隔離
  • 微服務資料庫解耦
  • 等等

參考資料

相關文章