[[277207]]

微服務(wù)架構(gòu)，這 5 年左右一直被認(rèn)可，是軟件架構(gòu)的未來方向。需要大家理解的是，為什么需要服務(wù)化。比如微服務(wù)架構(gòu)對企業(yè)來說，帶來什么價(jià)值?有啥弊端?

這里淺談一下微服務(wù)架構(gòu)，主要還是在理解 Why ：為什么需要服務(wù)化?

一、對微服務(wù)架構(gòu)的理解

1.1 微服務(wù)架構(gòu)

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

反例：不是一個(gè) Service 類組成的應(yīng)用工程，發(fā)布成服務(wù)就是微服務(wù)。這樣分的太小，理解微服務(wù)就很片面。杭州某金融大廠，曾經(jīng)分的很細(xì)，造成了運(yùn)維測試成本巨大。開始分了合，折騰...

1.2 為啥需要微服務(wù)?

由 SOA 架構(gòu) -> 微服務(wù)架構(gòu)的轉(zhuǎn)變，得理解為什么微服務(wù)架構(gòu)被廣泛提到并實(shí)踐。它解決了什么問題，帶來了什么價(jià)值?

傳統(tǒng)企業(yè)或者很多企業(yè)的軟件，大多不止一套系統(tǒng)，都是各個(gè)獨(dú)立大系統(tǒng)的堆砌。整體存在的問題是：

• 擴(kuò)展性差
• 可靠性不高
• 維護(hù)成本還很大
• 重復(fù)輪子很多

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

• 組件化
• 服務(wù)化

微服務(wù)架構(gòu)，將各個(gè)組件或者模塊分散到各個(gè)服務(wù)中，對整個(gè)系統(tǒng)實(shí)現(xiàn)解耦。那微服務(wù)架構(gòu)強(qiáng)調(diào)的重中之重就是業(yè)務(wù)系統(tǒng)需要完善的組件化和服務(wù)化。什么是組件化?

組件化，即將一個(gè)大系統(tǒng)，按照一定的業(yè)務(wù)或者技術(shù)維度關(guān)注形式，拆分成獨(dú)立的組件。目的是為了分而治之，為了可重用，為了減少耦合度。比如按照技術(shù)維度：搜索組件、緩存組件;按照業(yè)務(wù)維度：用戶中心、支付中心等

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

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

二、服務(wù)化前的問題

2.1 沒有服務(wù)化，不代表不是分布式或集群

分布式，就是多個(gè)實(shí)例提供相同的服務(wù)。比如多個(gè)地方動車站里面，多個(gè)機(jī)器提供取票服務(wù)。多個(gè)地方，北京上海等，就是多機(jī)房，多個(gè)取票服務(wù)一起組成了集群，形成分布式服務(wù)。那啥是服務(wù)化?

服務(wù)化，強(qiáng)調(diào) “化”!核心就是不同服務(wù)之間的通信。是一種以服務(wù)為中心的解決方案：

• 服務(wù)注冊
• 服務(wù)發(fā)布
• 服務(wù)調(diào)用
• 服務(wù)監(jiān)控
• 服務(wù)負(fù)載均衡
• 等等

2.2 沒有服務(wù)化的架構(gòu)問題

沒有服務(wù)化前，舉個(gè)例子，會更形象：

假設(shè)有個(gè)取票服務(wù)、買票服務(wù)、改座服務(wù)都需要驗(yàn)證下用戶身份真實(shí)性，那么會存在下面的問題：

• 取票服務(wù) -> 調(diào)用用戶DB代碼 -> 用戶DB
• 買票服務(wù) -> 調(diào)用用戶DB代碼 -> 用戶DB
• 改座服務(wù) -> 調(diào)用用戶DB代碼 -> 用戶DB

明顯的問題是：

• 代碼重復(fù)：不同業(yè)務(wù)相同訪問 DB 的 userDAO 代碼邏輯。而且每個(gè)服務(wù)這塊代碼是不同人維護(hù)的。
• 可維護(hù)性低：不同人維護(hù);不同地方維護(hù);每次 DB 字段改變或者遷庫，全部業(yè)務(wù)都有修改
• DB 訪問耦合

自然也有解決方案是：lib。維護(hù)一個(gè) user-DAO-lib 1.0.0 release 包，給各個(gè)業(yè)務(wù)方。

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

基于服務(wù)化，就可以完美解決問題。

三、服務(wù)化后的好處

如圖 Post 文章服務(wù)調(diào)用 Video 視頻服務(wù)，需要通過最上層的 Service 之間相互調(diào)用。服務(wù)化明顯改變：

• DB 隔離：這樣底層細(xì)節(jié)設(shè)計(jì)可以屏蔽，后續(xù)加上其他存儲 Cache 等對業(yè)務(wù)調(diào)用方無感知。
• 通過 Service 之間通信：具體協(xié)議可以 RPC / HTTP 等

服務(wù)化后的好處：

• 調(diào)用簡單：不用寫相同的訪問用戶服務(wù)代碼，調(diào)用一個(gè)服務(wù)即可
• 代碼復(fù)用：跟 lib 形式的代碼復(fù)用有所區(qū)別在于，服務(wù)化通過通信的方式解決
• 業(yè)務(wù)隔離
• 數(shù)據(jù)庫解耦
• 等等

四、不可否認(rèn)的微服務(wù)架構(gòu)或者服務(wù)化帶來新的問題

1、本身不大的系統(tǒng)，業(yè)務(wù)不復(fù)雜的系統(tǒng)也不需要微服務(wù)架構(gòu)。微服務(wù)架構(gòu)會帶來一定的復(fù)雜性，是一套完整的服務(wù)治理方案

2、多個(gè)模塊數(shù)據(jù)庫，分布式事務(wù)是一個(gè)挑戰(zhàn)

3、開發(fā)過程，增加了測試等一定的復(fù)雜性

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

五、小結(jié)

本小結(jié)，不是講how，講的是 why。只有懂 why ，才能更好地 do。從為啥服務(wù)化?到為啥微服務(wù)架構(gòu)這么流行：

• 微服務(wù)擴(kuò)展性高
• 微服務(wù)可靠性高
• 微服務(wù) 維護(hù)成本小
• 微服務(wù)幾乎沒有重復(fù)輪子
• 微服務(wù)直接調(diào)用調(diào)用簡單
• 微服務(wù)業(yè)務(wù)隔離
• 微服務(wù)數(shù)據(jù)庫解耦
• 等等

參考資料

互聯(lián)網(wǎng)架構(gòu)，究竟為啥要做服務(wù)化?https://mp.weixin.qq.com/s/S6ga8y88qaAjbKjuKMrowQ

https://zh.wikipedia.org/zh-sg/%E5%BE%AE%E6%9C%8D%E5%8B%99