Dubbo和Spring Cloud简单对比
2019年01月10日


首先做一个简单的功能对比:


DubboSpring Cloud
服务注册中心ZookeeperSpring Cloud Netflix Eureka
服务调用方式RPCREST API
服务监控Dubbo-monitorSpring Boot Admin
断路器不完善Spring Cloud Netflix Hystrix
服务网关Spring Cloud Netflix Zuul
分布式配置Spring Cloud Config
服务跟踪Spring Cloud Sleuth
消息总线Spring Cloud Bus
数据流Spring Cloud Stream
批量任务Spring Cloud Task
………………

从上图可以看出其实Dubbo的功能只是Spring Cloud体系的一部分。


但是,如果这样比,把Dubbo一个“框架”,跟Spring Cloud“整个体系”对比,实在有失公平。

像 服务网关、配置中心、APM(跟踪监控)这些东西,都是独立的,Spring Cloud可以用,Dubbo也可以用,而且选择还很多。

    拿 服务网关 来说,没必要一定用Spring Cloud Netflix Zuul,我们可以选择Kong、Zuul2等。

    拿 配置中心 来说,没必要一定用Spring Cloud Config,我们可以选择Disconf、Apollo等。


实际上,Dubbo具备一个微服务框架最核心的部分,而且这部分功能设计得非常好,具体可以参见dubbo作者梁飞的博客:https://javatar.iteye.com/blog/1345073


如果仅仅关注于服务治理的这个层面,Dubbo其实还优于Spring Cloud很多:

  • Dubbo 支持更多的协议,如:rmi、hessian、http、webservice、thrift、memcached、redis 等。

  • Dubbo 使用 RPC 协议效率更高,在极端压力测试下,Dubbo 的效率会高于 Spring Cloud 效率一倍多。

  • Dubbo 有更强大的后台管理,Dubbo 提供的后台管理 Dubbo Admin 功能强大,提供了路由规则、动态配置、访问控制、权重调节、均衡负载等诸多强大的功能。

  • 可以限制某个 IP 流量的访问权限,设置不同服务器分发不同的流量权重,并且支持多种算法,利用这些功能我们可以在线上做灰度发布、故障转移等,Spring Cloud 到现在还不支持灰度发布、流量权重等功能。


Dubbo最主要的问题是什么?是维护!

    我们知道,Dubbo出来得很早,反响也非常好,但是中间有5年没有更新了,它的开源做得不好,很多问题得不到及时解决,也没有持续的优化和更新。曾经有个专家说过一句话:“如果Dubbo一直更新下去,Spring Cloud在中国就没有机会了”。

    是的,如果Dubbo从2011年就一直壮大开源社区,一直持续不断的投入和优化,相信就没有Spring Cloud什么事儿了——毕竟2011年,Spring还是3.x版本,Spring还不属于Pivotal,还没有Spring Boot,更别谈Spring Cloud。


那么问题来了,Dubbo现在还有机会吗?Spring Cloud已经很成熟了。

    我想还是有的,首先Dubbo已经有不小的名气,而且有它自己的优势:功能、性能都很棒,再者有阿里和Apache的背书。

    选Dubbo,或者选Spring Cloud都OK,重要的是,你对哪个更熟悉,源码级别的熟悉!


附Dubbo最新信息:

    2018年1月8日,Dubbo创始人之一梁飞在Dubbo交流群里透露了Dubbo 3.0正在动工的消息。Dubbo 3.0内核与Dubbo 2.0完全不同,但兼容Dubbo 2.0。Dubbo 3.0将以Streaming为内核,不再是Dubbo时代的RPC,但是RPC会在Dubbo 3.0中变成远程Streaming对接的一种可选形态。Dubbo 3.0将支持可选Service Mesh,多加一层IPC,这主要是为了兼容老系统,而内部则会优先尝试内嵌模式。代理模式Ops可独立升级框架,减少业务侵入,而内嵌模式可以带业务测试、部署节点少、稳定性检测方便。同时,可以将Dubbo 3.0启动为独立进程,由dubbo-mesh进行IPC,路由、负载均衡和熔断机制将由独立进程控制。


我的点评:

    传统微服务框架,或者任何一个复杂的、功能强大的框架,最大的痛点是什么?我自己设计过、维护过这样的框架,深有感触。最大的痛点是升级困难。试想,公司有上百个项目跑在生产上,都用到这个框架,框架是和代码紧密耦合在一起的,如果想把框架升级,就得推动所有项目组,一个一个项目的去改造,去测试,去走上线流程。有些项目的开发上线周期,可能是按月为单位,这样下来,半年不一定能全部升级完。我推动业务方去升级,并告诉他们的项目/技术经理,这次框架的升级,只是做了一些大的优化并调整了一些运维规范相关的内容,不会影响原有功能和业务,但是有些项目组还是不放心,测试也不放心,还是得做一次全量回归测试!

    为此,我就在想,能不能把框架和代码剥离,研发只管升级业务代码,而框架升级维护由运维来负责。这个想法和Service Mesh不约而同,而且Service Mesh是一种颠覆式的创新,也正是因为它步子迈得太大了,所以迟迟不能落地。我感觉需要一个中间衔接过程,一个过渡阶段,而这个过渡阶段,我比较期望阿里能解决,Dubbo Mesh或者Sofa Mesh。