以實例說明微服務拆分（以SpringCloud+Gradle）

前言

以前，我都是說了不少的關於微服務的概念，說到底，不少人看了以後會認爲沒有什麼意思，由於沒有實際的東西說明，即便每一個概念都明白了，也很難賦之實踐。因此此次，我來用一個實際的例子去說明，在實際的項目過程當中咱們會如何去構建咱們的微服務。

PS：咱們只是利用場景去模擬咱們微服務構建或者說拆分的整個過程，對於場景自己在實際中會出現的問題咱們不作考慮，說白了就是咱們不考慮場景自己在實際生活中是否是這樣的。

使用SpringCloud+Gradle構建

本文目的：讓你體會到服務拆分自己，引發你對服務拆分的思考。

 

場景模擬

咱們首先模擬這樣一個業務場景，積分兌換實體商品。流程大體以下：
一、用戶登陸
二、選擇商品
三、下單
四、積分支付
五、商品發貨
六、訂單完成

「抽離業務」這裏爲了簡化咱們的實現，咱們去掉用戶登陸和商品發貨這樣兩個步驟，也就是默認用戶登陸，默認訂單必定完成。
若是使用單體架構，那咱們最後實現的狀況應該大可能是這樣的。
···
用戶點擊兌換 ->
【減小商品庫存，操做商品表】
【生成訂單，操做訂單表】
【減小用戶積分，操做用戶積分表】
【添加用戶積分記錄，操做積分記錄表】

在不考慮併發的狀況下，也須要使用事務，也就是說，其中任意一步操做出現問題，都會致使整個兌換出現問題，也就是所有回滾數據。這是咱們通常在單體應用中所常常實現的方式。

 

如何拆分紅微服務

如今，不管是老闆說了，仍是說就是想作，甭管由於什麼，反正我就是想要把它作成微服務。怎麼辦？
那麼一個看似耦合性很高的業務場景，咱們究竟如何將它拆分紅微服務呢？

咱們拆分須要掌握的邏輯
一、若是咱們要拆分的業務自己耦合度較高，那麼拆分的須要作的是拆離業務，說白了就是須要和產品商量業務上面須要進行部分改動。
二、若是咱們拆分的業務自己沒有耦合度，那麼隨你拆？？？不是的，須要考慮兩點，一個是粒度太細成本就會上去，一個是後期擴展是否會有影響

 

架構改變

下面兩張圖是咱們模擬架構改變先後大體畫了一下的兩張圖，咱們能夠簡單從圖中得到二者的大致差別

 

 

具體拆分

如今我提出一種拆分的方式
一、減小商品庫存建立訂單放在一個微服務中，構成下單服務
二、減小用戶積分和操做用戶積分記錄放在另外一個微服務中，構成支付服務

拆分後的邏輯
用戶點擊兌換 ->
【減小商品庫存，操做商品表】
【生成訂單，操做訂單表】

【減小用戶積分，操做用戶積分表】
【添加用戶積分記錄，操做積分記錄表】

拆分達到的效果：
即便用戶積分由於種種緣由沒有正常扣除，後續還能夠進行支付

拆分的好處：
後期擴展上來說，後期若是支付方式不僅是積分，能夠用別的，那麼只須要對支付服務進行修改，對於下單來講沒有任何關係

 

拆分代碼

https://github.com/LinkinStars/MicroServiceExample

 

分析總結

若是你看完代碼你就知道，其實拆分自己沒有你想象的那麼複雜，雖然咱們簡化了其中的部分細節，可是實際若是須要這樣去拆分，邏輯上其實就這樣的。沒有你想象的那麼複雜。
可是！！！
困難其實並不在拆分代碼自己，以前一篇博客我就提到了，其實微服務的拆分並無實際想象的那麼複雜，而困難來自於拆分後會致使的各類問題，由於其實對於業務自己來講，不少時候咱們都會遇到一些耦合性的業務，這些業務自己很難拆分。因此和上面說的同樣，在一些服務進行實際拆分的時候咱們會對業務進行調整，雖然對於用戶感知自己是同樣的，可是實際代碼來講是不同的。
總結如下幾點供參考：
一、若是經驗不足，先小拆，後大拆
二、假設異常，假設每一個服務都分別出現一次異常，會對你拆分後的服務形成什麼樣的影響
三、優先保證主線業務穩定
四、拆分的原則是爲了後期業務擴展，那麼你須要優先考慮到後期的擴展大體會怎麼樣

 

Follow up

我一直在強調一點就是，咱們這個只是一個業務場景的模擬，實際上會有什麼問題呢？ 一、當用戶積分不夠所帶來的一直沒法支付，對於這個訂單的後期如何處理？ 二、針對於一些大型項目，對於訂單和商品都須要進行拆分，那麼會對如今的系統形成什麼影響呢？ 三、減小用戶積分（後期別的支付方式），其實添加記錄不該該影響支付，那麼如何解耦？ ... 等等的一些問題，我以爲你都應該去考慮，而後去嘗試，而後去發現問題。 這裏面就會有不少有趣的東西了，好比mq、異步等等，拋磚引玉、拋磚引玉 後面就看你的了！