一文詳解微服務架構（一）

本文將介紹微服務架構和相關的組件，介紹他們是什麼以及爲何要使用微服務架構和這些組件。本文側重於簡明地表達微服務架構的全局圖景，所以不會涉及具體如何使用組件等細節。

要理解微服務，首先要先理解不是微服務的那些。一般跟微服務相對的是單體應用，即將全部功能都打包成在一個獨立單元的應用程序。從單體應用到微服務並非一蹴而就的，這是一個逐漸演變的過程。本文將以一個網上超市應用爲例來講明這一過程。

最初的需求

幾年前，小明和小皮一塊兒創業作網上超市。小明負責程序開發，小皮負責其餘事宜。當時互聯網還不發達，網上超市仍是藍海。只要功能實現了就能隨便賺錢。因此他們的需求很簡單，只須要一個網站掛在公網，用戶可以在這個網站上瀏覽商品、購買商品；另外還需一個管理後臺，能夠管理商品、用戶、以及訂單數據。

咱們整理一下功能清單：

• 網站
  • 用戶註冊、登陸功能
  • 商品展現
  • 下單
• 管理後臺
  • 用戶管理
  • 商品管理
  • 訂單管理

因爲需求簡單，小明左手右手一個慢動做，網站就作好了。管理後臺出於安全考慮，不和網站作在一塊兒，小明右手左手慢動做重播，管理網站也作好了。整體架構圖以下：

小明揮一揮手，找了家雲服務部署上去，網站就上線了。上線後好評如潮，深受各種肥宅喜好。小明小皮美滋滋地開始躺着收錢。

隨着業務發展……

好景不長，沒過幾天，各種網上超市緊跟着拔地而起，對小明小皮形成了強烈的衝擊。

在競爭的壓力下，小明小皮決定開展一些營銷手段：

• 開展促銷活動。好比元旦全場打折，春節買二送一，情人節狗糧優惠券等等。
• 拓展渠道，新增移動端營銷。除了網站外，還須要開發移動端 APP，微信小程序等。
• 精準營銷。利用歷史數據對用戶進行分析，提供個性化服務。
• ……

這些活動都須要程序開發的支持。小明拉了同窗小紅加入團隊。小紅負責數據分析以及移動端相關開發。小明負責促銷活動相關功能的開發。

由於開發任務比較緊迫，小明小紅沒有好好規劃整個系統的架構，隨便拍了拍腦殼，決定把促銷管理和數據分析放在管理後臺裏，微信和移動端 APP 另外搭建。通宵了幾天後，新功能和新應用基本完工。這時架構圖以下：

這一階段存在不少不合理的地方：

• 網站和移動端應用有不少相同業務邏輯的重複代碼。
• 數據有時候經過數據庫共享，有時候經過接口調用傳輸。接口調用關係雜亂。
• 單個應用爲了給其餘應用提供接口，漸漸地越改越大，包含了不少原本就不屬於它的邏輯。應用邊界模糊，功能歸屬混亂。
• 管理後臺在一開始的設計中保障級別較低。加入數據分析和促銷管理相關功能後出現性能瓶頸，影響了其餘應用。
• 數據庫表結構被多個應用依賴，沒法重構和優化。
• 全部應用都在一個數據庫上操做，數據庫出現性能瓶頸。特別是數據分析跑起來的時候，數據庫性能急劇降低。
• 開發、測試、部署、維護愈發困難。即便只改動一個小功能，也須要整個應用一塊兒發佈。有時候發佈會不當心帶上了一些未經測試的代碼，或者修改了一個功能後，另外一個意想不到的地方出錯了。爲了減輕發佈可能產生的問題的影響和線上業務停頓的影響，全部應用都要在凌晨三四點執行發佈。發佈後爲了驗證應用正常運行，還得盯到次日白天的用戶高峯期……
• 團隊出現推諉扯皮現象。關於一些公用的功能應該建設在哪一個應用上的問題經常要爭論好久，最後要麼乾脆各作各的，或者隨便放個地方可是都不維護。

儘管有着諸多問題，但也不可否認這一階段的成果：快速地根據業務變化建設了系統。不過緊迫且繁重的任務容易令人陷入局部、短淺的思惟方式，從而作出妥協式的決策。在這種架構中，每一個人都只關注在本身的一畝三分地，缺少全局的、長遠的設計。久而久之，系統建設將會愈來愈困難，甚至陷入不斷推翻、重建的循環。

是時候作出改變了

幸虧小明和小紅是有追求有理想的好青年。意識到問題後，小明和小紅從瑣碎的業務需求中騰出了一部分精力，開始梳理總體架構，針對問題準備着手改造。

要作改造，首先你須要有足夠的精力和資源。若是你的需求方（業務人員、項目經理、上司等）很強勢地一心追求需求進度，以至於你沒法挪出額外的精力和資源的話，那麼你可能沒法作任何事……

• 用戶服務
• 商品服務
• 促銷服務
• 訂單服務
• 數據分析服務

各個應用後臺只需從這些服務獲取所需的數據，從而刪去了大量冗餘的代碼，就剩個輕薄的控制層和前端。這一階段的架構以下：

這個階段只是將服務分開了，數據庫依然是共用的，因此一些煙囪式系統的缺點仍然存在：

1. 數據庫成爲性能瓶頸，而且有單點故障的風險。
2. 數據管理趨向混亂。即便一開始有良好的模塊化設計，隨着時間推移，總會有一個服務直接從數據庫取另外一個服務的數據的現象。
3. 數據庫表結構可能被多個服務依賴，牽一髮而動全身，很難調整。

若是一直保持共用數據庫的模式，則整個架構會愈來愈僵化，失去了微服務架構的意義。所以小明和小紅一氣呵成，把數據庫也拆分了。全部持久化層相互隔離，由各個服務本身負責。另外，爲了提升系統的實時性，加入了消息隊列機制。架構以下：

徹底拆分後各個服務能夠採用異構的技術。好比數據分析服務可使用數據倉庫做爲持久化層，以便於高效地作一些統計計算；商品服務和促銷服務訪問頻率比較大，所以加入了緩存機制等。

還有一種抽象出公共邏輯的方法是把這些公共邏輯作成公共的框架庫。這種方法能夠減小服務調用的性能損耗。可是這種方法的管理成本很是高昂，很難保證全部應用版本的一致性。

數據庫拆分也有一些問題和挑戰：好比說跨庫級聯的需求，經過服務查詢數據顆粒度的粗細問題等。可是這些問題能夠經過合理的設計來解決。整體來講，數據庫拆分是一個利大於弊的。

微服務架構還有一個技術外的好處，它使整個系統的分工更加明確，責任更加清晰，每一個人專心負責爲其餘人提供更好的服務。在單體應用的時代，公共的業務功能常常沒有明確的歸屬。最後要麼各作各的，每一個人都從新實現了一遍；要麼是隨機一我的（通常是能力比較強或者比較熱心的人）作到他負責的應用裏面。在後者的狀況下，這我的在負責本身應用以外，還要額外負責給別人提供這些公共的功能——而這個功能原本是無人負責的，僅僅由於他能力較強 / 比較熱心，就莫名地背鍋（這種狀況還被美其名曰能者多勞）。結果最後你們都不肯意提供公共的功能。久而久之，團隊裏的人漸漸變得各自爲政，再也不關心全局的架構設計。

從這個角度上看，使用微服務架構同時也須要組織結構作相應的調整。因此說作微服務改造須要管理者的支持。

改造完成後，小明和小紅分清楚各自的鍋。兩人十分滿意，一切就像是麥克斯韋方程組同樣漂亮完美。

然而……

---

「不積跬步，無以致千里」，但願將來的你能：有夢爲馬 隨處可棲！加油，少年！

關注公衆號:「Java 知己」，天天更新Java知識哦，期待你的到來！

• 發送「Group」，與 10 萬程序員一塊兒進步。
• 發送「面試」，領取BATJ面試資料、面試視頻攻略。
• 發送「玩轉算法」，領取《玩轉算法》系列視頻教程。
• 千萬不要發送「1024」...
  

做者：古霜卡比
原文：http://www.javashuo.com/article/p-gptbslhj-eb.html