java服务化,JAVA单服务应用拆分成多个服务的实践(２)--服务的dubbo化

上篇文章JAVA单服务应用拆分成多个服务的实践(1)--拆分的设计思想--提到,需要将各个应用微服务化.

我的应用是使用Spring boot ,没用spring Cloud,所以微服务间的通讯是使用dubbo.

在我个人开发期间,我已经有意识的使用api+provider的开发方式.

API为相关接口定义,provider为API的实现,而所有项目只能使用需要模块的API,绝对不能引入provider的模块.

当时的构想是说,provider层的东西可以替换以另一种方式实现.这种构想在服务dubbo化时,为我带了很大的方便.

下面以组织为例列一下实现过程.

服务API的dubbo化只需要配置XML就可以了

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:dubbo="http://code.alibabatech.com/schema/dubbo"

xsi:schemaLocation="http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans.xsd

http://code.alibabatech.com/schema/dubbo

http://code.alibabatech.com/schema/dubbo/dubbo.xsd">

ref="sysOrgApiService" retries="0" timeout="6000" />

这里有些人会提,为什么不使用dubbo注解,但其实上一个已经提到了,我要实现ALL IN ONE,使用注解会增加依赖,不恰当.

dubbo初始化就更简单了

@Configuration

@ImportResource({"classpath*:dubbo/**/dubbo*.xml" })

public class DubboConfig {

}

dubbo化之后,就不能联合查询了,其他服务很多时候都要查询组织的信息,只能通过接口来查询. 查询最多的时候是需要将用户ID转成名字,很多都是在接口里调用dubbo查询,这样性能会很慢,而且如果组织卡死了,会给前端体现相当不好.

这种情况可以考虑我的一篇文章巧用vue组件实现人员id及名称的转换,这种方式直接对组织的相关接口

组织调整后,应用的结构调整如下:

组织的dubbo化

至此,组织的dubbo已完成.这种办法解决了我的个人开发平台的组织,权限,附件上传,数据字典,数据过滤,表单引擎,流程引擎的微服务化.

[未完待续]