dubbo服务化实施整理
随着快的业务的快速发展,我们逐步按照业务垂直划分,抽象出基础服务层。
一 服务化目标
- 基础业务的服务为上游业务的灵活发展提供支持
- 服务应用本身无状态化,可以随着系统的负荷灵活伸缩来提供服务能
- 服务的稳定性,可用性达到99%
二 dubbo架构
dubbo来作为服务化中间件,dubbo作为一个RPC框架,大致的原理如下图
- Registry: 注册中心;和服务的消费者,和服务提供者都建立长连接。服务提供者注册服务到注册中心;服务消费者从注册中心获取服务提供者列表;
- Consumer: 服务消费端;服务消费者从注册中心获取到服务提供者列表后,根据负载均衡算法,选择一个服务提供者,和服务提供者直接建立连接,开始调用服务;
- Provider:服务提供者;服务提供者提供RPC服务;
- Monitor: 监控服务的调用情况统计;
- 注册中心为N+1对等集群,一台挂掉后,会自动切换到另外一台注册中心
- 注册中心全部挂掉后,消息消费者本地会缓存服务提供者列表,所以不影响当时的服务调用。
- 服务提供者为集群,一台挂掉后,通过心跳过程,注册中心会立即刷到服务消费者告知;
三 工程分类
描述:业务域对外提供的服务接口,参数类型输出:独立jar,例如user-api.jar
描述:业务域的模型,包括数据和行为,只关心领域内的数据和模型,不关心外部服务输出:独立jar,例如user-core.jar,外部业务不能依赖该jar
描述:业务域的远程服务实现,负责服务启动停止,内部业务组装,参数转换输出:***-assembly.tar.gz,输出是一个压缩包
描述:业务域对外提供的服务接口,参数类型输出:独立jar,例如user-api.jar
描述:业务域的远程服务实现,负责服务启动停止,内部业务组装,参数转换
四 standalong工程
工程结构
浅蓝色是目录,浅绿色是文件。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目录结构
七 一些注意事项
- 所有服务接口都以"RemoteService"结尾
- 不要传输超大对象
- 服务化接口涉及的入参类型和返回类型都必须实现序列化接口,并且必须放到api包
- 子类和父类不允许有同名同类型的属性,序列化容易出问题
- 所有类型都应该有序列化id
- 外部参数和内部参数必须做隔离,简单来说就是core里面的东西不能被透传到外部
已有 0 人发表留言,猛击->> 这里<<-参与讨论
ITeye推荐