微服務架構一直火,為什麼服務化要搞懂?

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

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

一、對微服務架構的理解

1.1 微服務架構

微服務架構一直火,為什麼服務化要搞懂?

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

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

1.2 為啥需要微服務?

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

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

  • 擴展性差
  • 可靠性不高
  • 維護成本還很大
  • 重複輪子很多
微服務架構一直火,為什麼服務化要搞懂?

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

  • 組件化
  • 服務化

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

組件化,即將一個大系統,按照一定的業務或者技術維度關注形式,拆分成獨立的組件。目的是為了分而治之,為了可重用,為了減少耦合度。比如按照技術維度:搜索組件、緩存組件;按照業務維度:用戶中心、支付中心等

微服務架構一直火,為什麼服務化要搞懂?

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

微服務架構一直火,為什麼服務化要搞懂?

(圖來自漫畫程序員小灰)

二、服務化前的問題

2.1 沒有服務化,不代表不是分佈式或集群

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

服務化,強調 “化”!核心就是不同服務之間的通信。是一種以服務為中心的解決方案:

  • 服務註冊
  • 服務發佈
  • 服務調用
  • 服務監控
  • 服務負載均衡
  • 等等
微服務架構一直火,為什麼服務化要搞懂?

2.2 沒有服務化的架構問題

沒有服務化前,舉個例子,會更形象:

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

  • 取票服務 -> 調用用戶DB代碼 -> 用戶DB
  • 買票服務 -> 調用用戶DB代碼 -> 用戶DB
  • 改座服務 -> 調用用戶DB代碼 -> 用戶DB
微服務架構一直火,為什麼服務化要搞懂?

明顯的問題是:

  • 代碼重複:不同業務相同訪問 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或者回滾都是巨大的成本

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

三、服務化後的好處

微服務架構一直火,為什麼服務化要搞懂?

如圖 Post 文章服務調用 Video 視頻服務,需要通過最上層的 Service 之間相互調用。服務化明顯改變:

  • DB 隔離:這樣底層細節設計可以屏蔽,後續加上其他存儲 Cache 等對業務調用方無感知。
  • 通過 Service 之間通信:具體協議可以 RPC / HTTP 等

服務化後的好處:

  • 調用簡單:不用寫相同的訪問用戶服務代碼,調用一個服務即可
  • 代碼複用:跟 lib 形式的代碼複用有所區別在於,服務化通過通信的方式解決
  • 業務隔離
  • 數據庫解耦
  • 等等

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

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

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

五、小結

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

  • 微服務擴展性高
  • 微服務可靠性高
  • 微服務 維護成本小
  • 微服務幾乎沒有重複輪子
  • 微服務直接調用調用簡單
  • 微服務業務隔離
  • 微服務數據庫解耦
  • 等等
  • 精華資料 原文鏈接 http://www.bysocket.com/technique/architecture/2423.html
  • 互聯網架構,究竟為啥要做服務化?https://mp.weixin.qq.com/s/S6ga8y88qaAjbKjuKMrowQ
  • https://zh.wikipedia.org/zh-sg/%E5%BE%AE%E6%9C%8D%E5%8B%99


分享到:


相關文章: