微服務學習筆記（一）微服架構初識

單體式架構

應用程序是一個總體，修改一部份內容，就整個從新打包部署。

拋問題：當用戶流量大，一個服務器撐不住、搞不定的時候，怎麼辦？

​

你說我對服務器擴容？

不合適。舉個栗子：一個電商網站，分爲商品模塊、用戶模塊、訂單模塊等，用戶頻繁訪問的是商品模塊，當流量大頂不住的時候，也是商品模塊頂不住。若是你對服務器擴容，那麼不怎麼須要擴容的用戶模塊和訂單模塊也會跟着一塊兒擴（項目耦合性強），對硬件資源是一種消耗。

怎麼辦？

把模塊拆分，變爲一個個子系統，好比商品系統、用戶系統、訂單系統，當流量大頂不住的時候，只拓展商品系統 。

微服務架構

講白了就是原來有一個項目，在拓展的過程當中發現整個項目耦合性很是強，若是直接拓展，就會把其餘的項目一塊兒拓展了，爲了不這種狀況，咱們能夠把這個項目拆分爲一個個服務，當系統出現瓶頸的時候，咱們來分析一下，究竟是哪一個服務出現了瓶頸，而後對這個瓶頸進行一個相應的拓展，這就是微服務架構的概念了。

微服架構設計原則

• 圍繞業務

  不解釋

• 單一職責

  一個服務就作一件事情。雖然「訂單」和「支付」看起來是一個模塊裏的，可是在微服務中是兩個服務。「支付」分爲支付寶支付啊微信支付啊等等，「訂單」的話還須要增刪改查訂單，因此不是一回事兒，不坐一塊兒討論。

• 誰建立，誰負責

  單體式架構的時候，開發人員能夠直接把包丟給運維，由運維負責部署啊維護啊，但由於微服務中各類配置、各個服務之間的關係只有開發人員最瞭解，因此它的維護工做也只能交給開發人員來作。

如何拆分一個業務？

舉個栗子，需求以下：

模擬雙十一商品搶購流程：

一、N個商品M個用戶同時搶購某商品（M > N）

二、搶購成功的用戶進行支付（支付寶、微信支付）

三、用戶超時未支付，回退訂單。

四、用戶支付成功，減庫存，修改訂單信息、狀態。

哇喔，有點亂，畫個圖先：

單體式架構中，這個業務被分爲了四個模塊。微服務架構中，首先分紅四個項目，分別部署。

而後呢？

舉個栗子：若是用戶要下單，系統得先判斷他是否登陸，因此確定須要調用用戶項目獲得用戶數據，而後去調用商品項目信息，拿到用戶挑選的商品信息，在本身的項目裏面生成訂單，再交給支付項目處理。

也就是說這四個項目互相之間須要通訊，並且每一個項目至少有兩部分功能：一個是對外我要提供什麼接口，你來訪問我給你什麼數據（項目提供者），一個是對內我須要對數據作什麼樣的處理加工（項目消費者）。

因此當前的業務需求一次性就可以衍生八個項目，隨之你須要思考幾個問題：

一、服務之間如何調用？（Dubbox...）

二、多個服務即有多個項目，如何快速部署？（Docker...）

三、多個服務之間如何實現事務？（MQ...）