dubbo服务化实施整理

dubbo服务化实施整理

• 博客分类： 
• 服务器架构

原创文章，转载请注明出处：http://jameswxx.iteye.com/blog/2096425

 

随着快的业务的快速发展，我们逐步按照业务垂直划分，抽象出基础服务层。

一 服务化目标

• 基础业务的服务为上游业务的灵活发展提供支持

• 服务应用本身无状态化，可以随着系统的负荷灵活伸缩来提供服务能

• 服务的稳定性，可用性达到99%

 

二 dubbo架构

dubbo来作为服务化中间件，dubbo作为一个RPC框架，大致的原理如下图

         

 

• Registry: 注册中心；和服务的消费者，和服务提供者都建立长连接。服务提供者注册服务到注册中心；服务消费者从注册中心获取服务提供者列表；

• Consumer: 服务消费端；服务消费者从注册中心获取到服务提供者列表后，根据负载均衡算法，选择一个服务提供者，和服务提供者直接建立连接，开始调用服务；

• Provider:服务提供者；服务提供者提供RPC服务；

• Monitor: 监控服务的调用情况统计；

• 注册中心为N+1对等集群，一台挂掉后，会自动切换到另外一台注册中心

• 注册中心全部挂掉后，消息消费者本地会缓存服务提供者列表，所以不影响当时的服务调用。

• 服务提供者为集群，一台挂掉后，通过心跳过程，注册中心会立即刷到服务消费者告知；

 

三 工程分类

总体来说，服务化工程类型分为两种

standalong工程

以独立的应用形式提供远程服务，不依赖web容器，这是比较标准的服务提供形式，有3个子工程：

api

描述：业务域对外提供的服务接口，参数类型

输出：独立jar，例如user-api.jar

core

描述：业务域的模型，包括数据和行为，只关心领域内的数据和模型，不关心外部服务

输出：独立jar，例如user-core.jar，外部业务不能依赖该jar

impl

描述：业务域的远程服务实现，负责服务启动停止，内部业务组装，参数转换

输出：***-assembly.tar.gz，输出是一个压缩包

web工程

已有的web应用暴露服务，最好对原有的工程结构无侵入，只是再增加2个子工程：

api

描述：业务域对外提供的服务接口，参数类型

输出：独立jar，例如user-api.jar

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

 

 

七 一些注意事项

• 所有服务接口都以"RemoteService"结尾
• 不要传输超大对象

• 服务化接口涉及的入参类型和返回类型都必须实现序列化接口，并且必须放到api包

• 子类和父类不允许有同名同类型的属性，序列化容易出问题

• 所有类型都应该有序列化id

• 外部参数和内部参数必须做隔离，简单来说就是core里面的东西不能被透传到外部
  

以会员为例，假设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);

  }

}