自第一篇《 基於SpringCloud的Microservices架構實戰案例-序篇》發表出來後，差不多有半年時間了，一直也沒有接著拆分完，有如讀本書一樣，也是需要契機的，還是要把未完成的工作做完，雖然並不是什麼經典應用，還是有必要將simplemall的形成過程拆解下，也便於對此案例的理解。
服務拆分具體拆分到多細，業內沒有一個統一的標準。當然也不能為了拆分而拆分，還要依據具體的業務場景應用情況而定，讀過《淘寶技術這十年》的朋友，相信對淘寶的技術演進有一個很直觀的感受。雖然當時微服務的概念並不今天這般火熱，但實際已經在生產環境中執行。
simplemall專案的業務背景基於簡單的購物場景，也即是常見的電商業務。實現完備的電商業務流程非常複雜龐大，此專案僅中拆分出基礎的簡單的5個基礎服務，使用者模組、訂單模組、支付模組、產品模組、訊息模組。實際的業務應用中可能拆解的更加細緻，比如產品服務中還可以細分出庫存、促銷、價格、產品分類、推薦等等，本專案僅以最簡單的服務展現，以達成簡單瞭解並使用spring cloud元件的目的。
全部模組基於SpringBoot，採用maven進行專案管理。
專案架構結構圖如下：
基礎業務服務分為：
-
account-service使用者子服務
-
product-service產品子服務
-
payment-service支付子服務
-
order-service訂單子服務
-
msg-service訊息子服務
-
front-app業務前端展示
每個業務服務有自己的單獨的DB，資料儲存基於mysql 5.6+，sql資料夾下面存放著基礎的初始化指令碼，直接執行即可。每個服務連線db的配置依本地配置為準。
基礎支撐服務分為：
-
admin-server服務監控
-
conf-server配置中心
-
eureka-server服務註冊中心
-
hystrix-dashborad服務熔斷監控皮膚
-
sleuth-server連結跟蹤監控
-
turbine-server服務熔斷集合監控
-
zuul-server閘道器伺服器
-
common-module基礎模組
必備服務是eureka-server，用於服務註冊、發現。其餘基礎服務模組是慢慢演變優化加入進去的。
common-module模組中存放redis的連線配置及相關模組的實體。有朋友問entity為何儲存在common模組中，此種做法有利有弊。好處是所有子模組直接依賴此common模組，可以拿到所以模組相關的實體及介面，弊端是服務增多時，Java類繁多龐大，會引入很多無關程式碼。比較常見的做法時，每個子服務模組中獨立一個api模組，存放實體及對外的api介面。如下圖：
小節一下：本文介紹了simplemall專案的程式碼結構，重點述說了下子服務的實體及介面程式碼的儲存，後續深入具體模組詳細介紹。
原始碼地址：https://github.com/backkoms/simplemall
擴充套件閱讀：