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

上篇文章JAVA单服务应用拆分成多个服务的实践(1)--拆分的设计思想--提到,需要将各个应用微服务化.
我的应用是使用Spring boot ,没用spring Cloud,所以微服务间的通讯是使用dubbo.
在我个人开发期间,我已经有意识的使用api+provider的开发方式.
API为相关接口定义,provider为API的实现,而所有项目只能使用需要模块的API,绝对不能引入provider的模块.
当时的构想是说,provider层的东西可以替换以另一种方式实现.这种构想在服务dubbo化时,为我带了很大的方便.　　
下面以组织为例列一下实现过程.

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

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       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">

<dubbo:service interface="com.starmark.sys.org.api.service.ISysOrgApiService"
               ref="sysOrgApiService" retries="0" timeout="6000" />
</beans>

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

• dubbo初始化就更简单了

@Configuration
@ImportResource({"classpath*:dubbo/**/dubbo*.xml" })
public class DubboConfig {
}

dubbo化之后,就不能联合查询了,其他服务很多时候都要查询组织的信息,只能通过接口来查询. 查询最多的时候是需要将用户ID转成名字,很多都是在接口里调用dubbo查询,这样性能会很慢,而且如果组织卡死了,会给前端体现相当不好.
这种情况可以考虑我的一篇文章巧用vue组件实现人员id及名称的转换,这种方式直接对组织的相关接口　　
组织调整后,应用的结构调整如下:　　

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