关于Jeecg互联网化dubbo改造方案

为什么80%的码农都做不了架构师？>>>   

随着互联网化越来越走近生活，国家也在推广互联网+，传统的垂直应用架构无法应对，所以我设想对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配置声明暴露服务（服务的提供者）

 

 

其中注册中心：1、multicast广播注册中心暴露服务地址2、zookeeper。

最后一个红圈是本地服务的部署。当然在linux正式环境下，dubbo会有独立的容器来部署。

 

 

 

Dc-web:MVC，同样也依赖dc-api，图中红圈是服务的消费者。配制如下：

 

与provider.xml相比consumer.xml引用的配制类不一样 。目前官网提供核心配制类如下：

详情参考：http://dubbo.io/User+Guide-zh.htm

Dc-web可以直接部署到apache的tomcat下。是一个web项目。

转载于:https://my.oschina.net/jeecg/blog/726248