springCloud搭建一套簡單的分佈式

說明：

     爲何放棄zookeeper dubobo，阿里有個很奇怪的現象，但凡開源出來的東西基本上就不維護了。技術的突飛猛進，不斷的進行更換交替，老是有着相同的終點和不一樣的起點。

    選擇Spring Cloud一方面出於嘗試性，另外一方面出於對後來者更容易接觸；畢竟對於java 這一塊來講spring 這幾年彷佛得了瘋牛症，什麼都去插一腳，權限，微服務，分佈式，數據庫，jpa等等。

 

這是大致的項目構建方案 先上個圖後續慢慢完善，

zuul ：路由中心，主要處理路由；

user ：用戶模塊也就是業務模塊；

upload ：文件管理上傳下載的模塊，專門負責文件上傳，格式轉化，壓縮等等一系列有關服務器文件的相關內容；

tools：一些工具包，utils，還有一些返還的基本方法之類主要負責整個項目的所有自定義的輔助方法好比 電話號碼識別，ip識別等等一些；

sso ： 單點登陸以及權限控制中心，用戶請求模塊業務，以及權限處理都在整個服務內進行，目前用jwt+redis，權限使用spring security ；

rbbion： 負載均衡控制中心；

mybatis ：這裏統一管理 各個mapper 和 xml文件，全部模塊的xml和 mapper  和 vo類；這樣設計的目的有利之處在於各個庫之間用文件名區分統一管理，維護的時候方便，調用各個Mapper之間更加方便；有弊之處就是，項目大了以後可能部署時 各個木塊之間 此jar 可能會不一樣步的問題，這裏講後續時再解釋，目前暫時想到這裏；

message：消息隊列中心，目前主要使用kafak；

log ：日誌統一處理；

job：實現全部定時業務，用Quartz，負責整個項目的定時任務；

eureka： 服務發現中心；

config ：整個模塊的配置中心；通用統一配置；此處只配置通用；接上面的問題來講：jar 不一樣步的問題；

首先開發 模塊 例如user 用戶中心模塊  打包方式採用 lib  jar 外置的方式（就是把lib 不打包到項目內，打包到項目外，而後有新的關聯jar 加入的時候 只須要更換指定 jar 就好了，不須要從新打包，並且項目主體出去jar 後 每次部署上傳可能就  幾M）    因此 若是某個模塊一直都沒更新過 mappr 或者 xml的話 那麼  幾個版本迭代以後 先後的  Mapper.jar（即 mybatis模塊）可能出現不一致太多，惟一可以下降管理成本的 就是 每個 mapper.jar 儘可能作版本管理 ；

 

這樣構建的思想： 其實開發的時候 你只要交給 下面的程序user 模塊和 mapper 這樣的模塊就好了 剩下 的 的做爲一個架構 就是慢慢去完善那些 內容就好了。