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

為陸川等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及陸川網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站建設(shè)、網(wǎng)站制作、陸川網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

 

明顯的問題是：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

五、小結(jié)

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

• 微服務(wù)擴展性高
• 微服務(wù)可靠性高
• 微服務(wù) 維護成本小
• 微服務(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

網(wǎng)站題目：微服務(wù)架構(gòu)一直火，為什么服務(wù)化要搞懂？
文章路徑：http://uogjgqi.cn/article/ccdihee.html