多语言展示
当前在线:245今日阅读:167今日分享:16

经典Java面试题:spring cloud 和dubbo区别?

微服务的点 SpringCloud   Dubbo 配置管理 Config    服务发现 Eureka,Consual Zookpeer Zookpeer 负载均衡 Ribbon 自带 网关 Zuul 分布式追踪 SpringCloud Sleuth 容错 Hystrix 不完善 通信方式 Http Message RPC 安全模块 Spring Cloud Securit
工具/原料
1

SpringCloud

2

Hystrix

3

Spring Cloud Securit

4

SpringCloud Sleuth

5

Zookpeer

方法/步骤
1

Dubbo,是阿里巴巴服务化治理的核心框架,并被广泛应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内还是国外都是引人注目的,比如:JStorm捐赠给Apache并加入Apache基金会等,为中国互联网人争足了面子,使得阿里巴巴在国人眼里已经从电商升了。

2

Spring Cloud,从命名我们就可以知道,它是Spring Source的产物,Spring社区的强大背书可以说是Java企业界最有影响力的组织了,除了Spring Source之外,还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。

3

如果拿Dubbo与Netflix套件做对比,前者在国内影响力较大,后者在国外影响力较大,我认为在背景上可以打个平手;但是若要与Spring Cloud做对比,由于Spring Source的加入,在背书上,Spring Cloud略胜一筹。不过,英雄不问出处,在背景这一点上,不能作为选择框架的主要因素,当您一筹莫展的时候,可以作为参考依据。

4

服务提供方与调用方接口依赖方式太强:我们为每个微服务定义了各自的service抽象接口,并通过持续集成发布到私有仓库中,调用方应用对微服务提供的抽象接口存在强依赖关系,因此不论开发、测试、集成环境都需要严格的管理版本依赖,才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题,以及这也会直接影响本地开发的环境要求,往往一个依赖很多服务的上层应用,每天都要更新很多代码并install之后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具,这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化,服务提供方和调用方的依赖只是依靠一纸契约,不存在代码级别的强依赖,当然REST接口也有痛点,因为接口定义过轻,很容易导致定义文档与实际实现不一致导致服务集成时的问题,但是该问题很好解决,只需要通过每个服务整合swagger,让每个服务的代码与文档一体化,就能解决。所以在分布式环境下,REST方式的服务依赖要比RPC方式的依赖更为灵活。

5

服务对平台敏感,难以简单复用:通常我们在提供对外服务时,都会以REST的方式提供出去,这样可以实现跨平台的特点,任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时,不得不实现一层代理,用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在,当要对外提供服务时,主要在API网关中配置映射关系和权限控制就可实现服务的复用了。

6

Dubbo实现了服务治理的基础,但是要完成一个完备的微服务架构,还需要在各环节去扩展和完善以保证集群的健康,以减轻开发、测试以及运维各个环节上增加出来的压力,这样才能让各环节人员真正的专注于业务逻辑。而Spring Cloud依然发扬了Spring Source整合一切的作风,以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体,并继承了Spring Boot简单配置、快速开发、轻松部署的特点,让原本复杂的架构工作变得相对容易上手一些(如果您读过我之前关于Spring Cloud的一些核心组件使用的文章,应该能体会这些让人兴奋而激动的特性,传送门)。所以,如果选择Dubbo请务必在各个环节做好整套解决方案的准备,不然很可能随着服务数量的增长,整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud,相对来说每个环节都已经有了对应的组件支持,可能有些也不一定能满足你所有的需求,但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。

7

Spring Cloud由于整合了大量组件,文档在体量上自然要比dubbo多很多,文档内容上还算简洁清楚,但是更多的是偏向整合,更深入的使用方法还是需要查看其整合组件的详细文档。另外由于Spring Cloud基于Spring Boot,很多例子相较于传统Spring应用要简单很多(因为自动化配置,很多内容都成了约定的默认配置),这对于刚接触的开发者可能会有些不适应,比较建议了解和学习Spring Boot之后再使用Spring Cloud,不然可能会出现很多一知半解的情况。

8

在微服务架构的实施和落地过程中,通常我们会进行技术选型,很多人会拿阿里开源的Dubbo和Spring Cloud进行对比,实际上对比的是REST和RPC,其实Dubbo和Spring Cloud并不在同一领域,没有可比性。

9

Spring Cloud是一个完整的微服务解决方案,正如上面的表格中展现的,它提供分布式情况下的各种解决方案合集。而Dubbo是一款高性能的Java RPC框架。Spring Cloud生态和Dubbo生态随着技术的发展,会逐渐的融合互补。

10

服务注册和发现作为基础的能力Dubbo是有的,默认大概提供了zookeeper,广播,redis等几种。Spring Cloud在这块也有多个方案,比如Spring Cloud Consul,再比如Netflix系的 Eureka 。 路由和负载均衡Dubbo默认提供了几种方式,可以扩展。Spring Cloud同样有ribbon和zuul,其实现的路由和负载功能更强大,其中也包括了授权、安全、服务质量监控等。 服务调用Dubbo使用了私有的Dubbo协议(当然也有其他协议也可以自己扩展,个人感觉Dubbo的扩展性做的很不错。),spring cloud应该是推荐HTTP。

注意事项
1

相比起Dubbo简单的四个模块,SpringCloud则是一个完整的分布式一站式框架,他有着一样的服务注册中心,服务提供者,服务消费者,管控台,断路器,分布式配置服务,消息总线,以及服务追踪等;

2

Dubbo主要分为服务注册中心,服务提供者,服务消费者,还有管控中心;

推荐信息