Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。简单的说,dubbo就是个服务框架,若是没有分布式的需求,实际上是不须要用的,只有在分布式的时候,才有dubbo这样的分布式服务框架的需求,而且本质上是个服务调用的东东,说白了就是个远程服务调用的分布式框架(告别Web Service模式中的WSdl,以服务者与消费者的方式在dubbo上注册)
其核心部分包含:
1. 远程通信: 提供对多种基于长链接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式。
2. 集群容错: 提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。
3. 自动发现: 基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方能够平滑增长或减小机器。算法
1.透明化的远程方法调用,就像调用本地方法同样调用远程方法,只需简单配置,没有任何API侵入。
2.软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,下降成本,减小单点。
3. 服务自动注册与发现,再也不须要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,而且可以平滑添加或删除服务提供者。
Dubbo采用全Spring配置方式,透明化接入应用,对应用没有任何API侵入,只需用Spring加载Dubbo的配置便可,Dubbo基于Spring的Schema扩展进行加载。缓存
dubbo架构图以下所示:mybatis
Provider: 暴露服务的服务提供方。架构
Consumer: 调用远程服务的服务消费方。mvc
Registry: 服务注册与发现的注册中心。负载均衡
Monitor: 统计服务的调用次调和调用时间的监控中心。框架
Container: 服务运行容器。分布式
这点我以为很是好,角色分明,能够根据每一个节点角色的状态来肯定该服务是否正常。ide
0 服务容器负责启动,加载,运行服务提供者。性能
dubbo的容错性显而易见,性能方面尚未还得及测,咱们系统某页面须要掉5次接口,原本想建议作个缓存,但业务关系不能采纳,还须要研究下dubbo的性能调优问题...
Dubbo采用全Spring配置方式,透明化接入应用,对应用没有任何API侵入,只需用Spring加载Dubbo的配置便可,Dubbo基于Spring的Schema扩展进行加载。若是不想使用Spring配置,而但愿经过API的方式进行调用(不推荐)
下面咱们一步一步的来剖解dubbo如何使用
请各位持续关注《跟我学习dubbo-ZooKeeper注册中心安装(2)》
核心技术:Maven,Springmvc mybatis shiro, Druid, Restful, Dubbo, ZooKeeper,Redis,FastDFS,ActiveMQ,Nginx
1. 项目核心代码结构截图
项目模块依赖
特别提醒:开发人员在开发的时候能够将本身的业务REST服务化或者Dubbo服务化
2. 项目依赖介绍
2.1 后台管理系统、Rest服务系统、Scheculer定时调度系统依赖以下图:
2.2 Dubbo独立服务项目依赖以下图:
3. 项目功能部分截图:
zookeeper、dubbo服务启动
dubbo管控台
REST服务平台