随着快的业务的快速发展,我们逐步按照业务垂直划分,抽象出基础服务层。 一 服务化目标
二 dubbo架构dubbo来作为服务化中间件,dubbo作为一个RPC框架,大致的原理如下图
三 工程分类总体来说,服务化工程类型分为两种 standalong工程 以独立的应用形式提供远程服务,不依赖web容器,这是比较标准的服务提供形式,有3个子工程: api
core
impl
web工程 已有的web应用暴露服务,最好对原有的工程结构无侵入,只是再增加2个子工程: api
impl 描述:业务域的远程服务实现,负责服务启动停止,内部业务组装,参数转换 无论是否服务化,某个业务域内部的数据和行为是不变的,服务化只是将业务域内的逻辑做一些裁剪或聚合,然后供外部调用。业务域的内部模型和提供的外部服务要划分一个边界,各自专注于自己的职责。以下是服务角色和子工程的对应关系:
四 standalong工程依赖关系 服务内部工程间的依赖都通过本地jar依赖,impl依赖api和core,没有其他依赖关系,严禁core依赖api。关系如下:
工程结构 浅蓝色是目录,浅绿色是文件。assembly.xml不能修改,dubbo.properties和dubbo-provider.xml都可以修改,dubbo.properties描述服务公共配置,如注册中心,超时等;dubbo-provider.xml通过spring描述具体服务信息
部署结构 standalong型的应用启动停止都必须有对应的脚本,这些脚本文件不需要每个standalong型应用自己写,只需要工程结构遵循规范,执行mvn package/install后,会在target自动输出最后的部署包,部署包结构如下图: 浅蓝色是目录,浅绿色是文件。 lib目录:存放依赖的jar包,工程里java代码都会输出为jar包到lib里 start.sh:启动服务 restart.sh:重启服务 stop.sh:停止服务 server.sh:命令入口,如server.sh start dump.sh:dump应用的线程栈,内存,GC;供排查问题用
五 web工程依赖关系 web应用大致分为两层:biz和web,实际上biz可能由内部多个工程组成,这里biz只是一个抽象概念。impl依赖api和biz,web依赖impl和biz,没有其他依赖关系,严禁biz依赖api。关系如下:
工程结构和部署结构 web应用的服务只需要配置在spring配置文件里,服务的启动停止依赖web容器的启动停止。所以web工程的服务化不需要调整原有工程结构,只是要增加两个子工程:api和impl。 这样做是希望某个已存在的web应用要做服务化,不会对原有工程发生改动。 六 svn目录结构对应工程结构,svn目录也做相应的划分,每个业务域是个大目录,然后该目录内部又分为3个目录:api,core,impl。以会员为例,svn目录结构为,以会员为例: user trunk api core impl branch
七 一些注意事项
以会员为例,假设core里存在UserService;有方法addUser(UserDO user);现在要将addUser(UserDO user)作为服务开放出去,则在api里加入UserRemoteService,UserRemoteService有对应的方法: addUser(UserDTO user),该方法内部操作数据通过UserService.addUser实现。大概代码如下: UserRemoteService{ private UserService userService; public void addUser(UserDTO userDTO){ UserDO userDO=***Converter.convert(userDTO); userService.addUser(userDO); } } |
|