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

 

 上個月(16/07)把一個大而全的應用拆分紅一個個小的應用。

 

 應用背景：

 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.進行應用拆分，將提供Http請求接口的拆分爲WebApp,將提供RPC接口的拆分爲App。而後這兩類分別安裝實現的業務功能進行拆分。

  拆分的WebApp,App仍然採用Spring Boot框架。

   

 拆分結果：

 

 

 

 1.WebApp經過Spring Session + Redis來實現Session共享

 2.WebApp,App經過請求配置服務（Spring Cloud Config Server）完成配置文件的讀取，解決了拆封緣由2的問題

 3.拆分步驟1解決拆分緣由3中的問題

 4.各個獨立的應用之間除了webApp要session共享外，其它的通訊，數據流向都是經過中間件來完成

 5.解決拆分緣由4的問題就更加容易了，定製化開發僅須要添加定製的應用便可

 訪問應用：

 1.應用是先後端分離，經過反向代理來完成Http請求到多個WebApp的轉發

 2.外部系統能夠經過Http請求，TCP/IP的方式分別訪問WebApp和App

 拆分難點：

 1.應用的模塊劃分，這個須要對應用業務流程，數據流向，依賴服務之間的調用關係以及通訊協議清楚

 2.避免爲拆分而拆分

 3.團隊成員都可以理解拆分的緣由，清楚操做的過程，可以想象到指望的結果

 一個故事：

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

 我：一塊兒煮

 女友：說分開煮

 我：不嫌麻煩

 女友：我不吃大肉

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

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

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