通過Springboot拆分服務構建微服務集

應用背景：

1.基於spring boot開發

2.依賴activemq，kafka,redis,mongodb,mysql等開源軟體

3.內部服務伺服器，分布式計算平台服務，檢索服務,訊息推送服務等

拆分原因：

1.（原有的）應用模組之間高度耦合，各個模組都擔當了牽一髮而動全身的「角色」

2.應用的配置資訊分布到依賴個幾個服務的配置中，配置資訊冗餘，對配置的修改改動地方過多

3.應用在依賴的基礎服務的時候，沒能遵循「依賴倒轉原則」，導致基礎服務公升級，問題修復，功能增加時應用在面對變化，不夠靈活

4.應用定製化開發分支與主線決裂，無法滿足靈活定製化開發

拆分過程：

整個拆封過程中保持原有業務不變，逐步進行的。

1.先是把依賴基礎服務的部分抽取出來，應用對依賴服務的操作全部通過抽象出來的介面進行。然後通過具體實現來完成基礎服務的操作。比如：操作伺服器的操作通過imageserverclient進行，操作分布式計算平台服務通過pccserverclient進行。

2.梳理應用的配置資訊，比如伺服器配置，資料庫配置等，搭建spring cloud config服務（支援git,svn,local file 讀取配置檔案）採用local file的方式來管理配置檔案;應用整合spring cloud config client ，配置資訊統一才配置服務中讀取。

拆分結果：

3.拆分步驟1解決拆分原因3中的問題

5.解決拆分原因4的問題就更加容易了，定製化開發僅需要新增定製的應用即可

訪問應用：

拆分難點：

1.應用的模組劃分，這個需要對應用業務流程，資料流向，依賴服務之間的呼叫關係以及通訊協議清楚

2.避免為拆分而拆分

3.團隊成員都能夠理解拆分的原因，清楚操作的過程，能夠想象到期望的結果

乙個故事：

某一天女朋友包了兩種餃子：大肉蔥，韭菜雞蛋。

我：一起煮

女朋友：說分開煮

我：不嫌麻煩

女朋友：我不吃大肉

我：那煮好，不撈大肉給你就好了

女朋友：那大肉蔥煮爛了，咋辦！鍋裡全是肉味

大而全的應用就像是乙個鍋煮各種餃子，小應用（微服務）就像是一鍋煮一類餃子。