前言
之前，我都是說了很多的關於微服務的概念，說到底，很多人看了之后會認為沒有什么意思，因為沒有實際的東西說明，即使每個概念都明白了，也很難賦之實踐。所以這次，我來用一個實際的例子去說明，在實際的項目過程中我們會如何去構建我們的微服務。
PS：我們只是利用場景去模擬我們微服務構建或者說拆分的整個過程，對於場景本身在實際中會出現的問題我們不做考慮，說白了就是我們不考慮場景本身在實際生活中是不是這樣的。
使用SpringCloud+Gradle構建
本文目的：讓你體會到服務拆分本身，引起你對服務拆分的思考。
場景模擬
我們首先模擬這樣一個業務場景，積分兌換實體商品。流程大致如下：
1、用戶登錄
2、選擇商品
3、下單
4、積分支付
5、商品發貨
6、訂單完成
“抽離業務”這里為了簡化我們的實現，我們去掉用戶登錄和商品發貨這樣兩個步驟，也就是默認用戶登錄，默認訂單一定完成。
如果使用單體架構，那我們最后實現的情況應該大多是這樣的。
···
用戶點擊兌換 ->
【減少商品庫存，操作商品表】
【生成訂單，操作訂單表】
【減少用戶積分，操作用戶積分表】
【添加用戶積分記錄，操作積分記錄表】
在不考慮並發的情況下，也需要使用事務，也就是說，其中任意一步操作出現問題，都會導致整個兌換出現問題，也就是全部回滾數據。這是我們一般在單體應用中所經常實現的方式。
如何拆分成微服務
現在，無論是老板說了，還是說就是想做，甭管因為什么，反正我就是想要把它做成微服務。怎么辦？
那么一個看似耦合性很高的業務場景，我們究竟如何將它拆分成微服務呢？
我們拆分需要掌握的邏輯
1、如果我們要拆分的業務本身耦合度較高，那么拆分的需要做的是拆離業務，說白了就是需要和產品商量業務上面需要進行部分改動。
2、如果我們拆分的業務本身沒有耦合度，那么隨你拆？？？不是的，需要考慮兩點，一個是粒度太細成本就會上去，一個是后期擴展是否會有影響
架構改變
下面兩張圖是我們模擬架構改變前后大致畫了一下的兩張圖，我們可以簡單從圖中獲得兩者的大體差異
具體拆分
現在我提出一種拆分的方式
1、減少商品庫存創建訂單放在一個微服務中，構成下單服務
2、減少用戶積分和操作用戶積分記錄放在另一個微服務中，構成支付服務
拆分后的邏輯
用戶點擊兌換 ->
【減少商品庫存，操作商品表】
【生成訂單，操作訂單表】
【減少用戶積分，操作用戶積分表】
【添加用戶積分記錄，操作積分記錄表】
拆分達到的效果：
即使用戶積分因為種種原因沒有正常扣除，后續還可以進行支付
拆分的好處：
后期擴展上來講，后期如果支付方式不只是積分，可以用別的，那么只需要對支付服務進行修改，對於下單來說沒有任何關系
拆分代碼
https://github.com/LinkinStars/MicroServiceExample
分析總結
如果你看完代碼你就知道，其實拆分本身沒有你想象的那么復雜，雖然我們簡化了其中的部分細節，但是實際如果需要這樣去拆分，邏輯上其實就這樣的。沒有你想象的那么復雜。
但是！！！
困難其實並不在拆分代碼本身，之前一篇博客我就提到了，其實微服務的拆分並沒有實際想象的那么復雜，而困難來自於拆分后會導致的各種問題，因為其實對於業務本身來說，很多時候我們都會遇到一些耦合性的業務，這些業務本身很難拆分。所以和上面說的一樣，在一些服務進行實際拆分的時候我們會對業務進行調整，雖然對於用戶感知本身是一樣的，但是實際代碼來說是不一樣的。
總結以下幾點供參考：
1、如果經驗不足，先小拆，后大拆
2、假設異常，假設每個服務都分別出現一次異常，會對你拆分后的服務造成什么樣的影響
3、優先保證主線業務穩定
4、拆分的原則是為了后期業務擴展，那么你需要優先考慮到后期的擴展大致會怎么樣
Follow up
我一直在強調一點就是，我們這個只是一個業務場景的模擬，實際上會有什么問題呢？
1、當用戶積分不夠所帶來的一直無法支付，對於這個訂單的后期如何處理？
2、針對於一些大型項目，對於訂單和商品都需要進行拆分，那么會對現在的系統造成什么影響呢？
3、減少用戶積分（后期別的支付方式），其實添加記錄不應該影響支付，那么如何解耦？
...
等等的一些問題，我覺得你都應該去考慮，然后去嘗試，然后去發現問題。
這里面就會有很多有趣的東西了，比如mq、異步等等，拋磚引玉、拋磚引玉
后面就看你的了！