關於Jeecg互聯網化dubbo改造方案

隨着互聯網化愈來愈走近生活，國家也在推廣互聯網+，傳統的垂直應用架構沒法應對，因此我設想對jeecg進行垂直服務化拆分。

藉助dubbo官網提供

從節點的角色能夠看出

    Provider: 暴露服務的服務提供方。（core-核心，可依賴其它api）

    Consumer: 調用遠程服務的服務消費方。(web-MVC)

    Registry: 服務註冊與發現的註冊中心。（zookeeper-分佈式文件配置）

 

從而讓我想起對jeecg的拆分主體子項目(依賴關係：從下到上)以下：

    Jeecg-api

    Jeecg-minidao

    Jeecg-codegenerate

    Jeecg-core

    Jeecg-jobs

    Jeecg-web

再結合當前的項目結構

 

tag-拆分-jeecg-api：共享其它子程序依賴

web-拆分-jeecg-web

 

Core-拆分-jeecg-core

 

注：相似dao、impl拆分到core;相似pojo、entity、interface、exception統一拆分到api中、含controller的包拆分到web中。

目前是按功能劃分包，顯得包不少。拆分後是按平臺整體結構劃分，結構整體會更清晰。

整體結構分層：優先按平臺結構在此基礎上再按業務包管理 。

Jeecg-codegenerate

能夠獨立項目，也能夠拆分紅依賴子項目。

Jeecg-minidao

獨立子項目供core依賴。

Jeecg-jobs

關於定時任務這塊我是想獨立出一個job子工程，能夠獨立部署，依賴core。

—————————————————————————————————————————

此次主要對jeecg拆分細化dubbo工程構建，結合dubbo相關配置文件。

目前我拿dc這個項目實戰作簡要分析，以下圖：

 

 

Dc-api：是獨立子項目不須要依賴其它子項目，是提供其它子項目依賴。如core、web.在service中提供的都是遠程服務的接口，供外部訪問。

 

 

 

Dc-core:是核心，依賴dc-api。第1個紅圈是dao也是依賴aof-all(在線服務框架-分庫分表);對於jeecg能夠依賴minidao。第2個紅圈是對api接口的impl（具體業務的實現）。第3個紅圈表示用Spring配置聲明暴露服務（服務的提供者）

 

 

其中註冊中心：一、multicast廣播註冊中心暴露服務地址二、zookeeper。

最後一個紅圈是本地服務的部署。固然在linux正式環境下，dubbo會有獨立的容器來部署。

 

 

 

Dc-web:MVC，一樣也依賴dc-api，圖中紅圈是服務的消費者。配製以下：

 

與provider.xml相比consumer.xml引用的配製類不同 。目前官網提供核心配製類以下：

詳情參考：http://dubbo.io/User+Guide-zh.htm

Dc-web能夠直接部署到apache的tomcat下。是一個web項目。