首先做一个简单的功能对比:
Dubbo | Spring Cloud | |
---|---|---|
服务注册中心 | Zookeeper | Spring Cloud Netflix Eureka |
服务调用方式 | RPC | REST API |
服务监控 | Dubbo-monitor | Spring 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。