关于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项目。