- 用于远程服务调用的分布式框架
- 高性能和透明化的RPC远程服务调用方案(RPC VS http)
- SOA服务治理方案(SOA VS 微服务)
dubbo能进行远程接口调用、负载均衡和容错、自动服务注册和发现。具有高性能、可与Spring无缝集成的优点。
使用场景:
- 传入传出参数数据包较小
- 消费者比提供者多
- 常规远程服务方法调用
- 不适合传送大数据量的服务,比如文件、视频
管理界面:
(1)各部分的名字和作用:
Provider:服务提供方(暴露服务)
Consumer:服务消费方(调用远程服务)
Registry:注册中心(服务注册和发现)
Monitor:监控中心(统计服务的调用次数和调用时间)
Container:服务运行容器
(2)调用流程如下:
0.服务运行容器启动、加载、运行服务提供方。
1.服务提供方在启动时,向注册中心注册自己提供的服务。
2.服务消费方在启动时,向注册中心订阅自己所需的服务。
3.注册中心返回服务提供方地址列表给消费方,而且是“终身服务”,一但有变更,注册中心会立即将变更数据推送给消费方。
4.服务消费方从地址列表中选一台提供方进行调用,如果调用失败,再选另一台。这个过程基于软负载均衡算法。
5.服务提供方和消费方在内存中累计调用次数和时间,每分钟向监控中心发送一次统计数据。
我们知道,dubbo、Springcloud、HSF都是分布式框架,但是HSF不常用,所以咱们今天只说说dubbo和Spring Cloud的不同。
- 能实现的功能方面
可以看出,dubbo只实现了服务治理,不过如果想实现如上“无”的要素,可以通过扩展Filter来完善;Spring Cloud覆盖的面更广一些。 - 内存损耗方面
dubbo是二进制传输的,所以其占用带宽较少;
springcloud是http协议传输的,而且使用了json报文,所以损耗较大。
总体来说,如果使用dubbo,需要自己“组装”。如果使用Spring Cloud,直接拿来用就好。但是如果想用Spring Could整体外的东西,再加入进去就相对费事一点。