【本文是为了梳理知识的总结性文章,总结了一些自认为相关的重要知识点,只为巩固记忆以及技术交流,忘批评指正。其中参考了很多前辈的文章,包括图片也是引用,如有冒犯,侵删。】
当前开源上可选用的微服务框架主要有Dubbo、Spring Cloud等,下面对这两个框架做一个简单对比介绍。
1 概念
Dubbo:Apache Dubbo是一款高性能Java RPC框架,之前由阿里巴巴开源,现已成为 Apache 基金会孵化项目。
Spring Cloud:是一个基于Spring Boot实现的微服务架构开发工具,它使用一系列开源框架,为微服务架构中涉及的配置管理、服务治理、断路器、智能路由、微代理、控制总线、一次性token、全局锁、决策竞选、分布式会话和集群状态管理等操作提供了一种简单的开发方式。
Dubbo具有调度、发现、监控、治理等功能,支持相当丰富的服务治理能力。而Spring Cloud 则满足了构建微服务所需的所有解决方案,其中包括了服务治理,因此可以说Dubbo是Spring Cloud的一个子集。
架构选型一般会考虑几个因素,如社区活跃度、功能完整度、技术特点和业务需求等。下面从这几个方面,对这两个框架进行对比介绍。
2 社区活跃度
我们选择一个开源框架,社区的活跃度是我们极为关注的一个要点。社区越活跃,解决问题的速度越快,框架也会越来越完善,不然当我们碰到问题,就不得不自己解决。而对于团队来说,也就意味着我们不得不自己去维护框架的源码,这对于团队来说也将会是一个很大的负担。
2.1 Dubbo 社区
2011 年 10 月 27 日,阿里巴巴开源了自己服务化治理方案的核心框架 Dubbo,服务治理的设计理念开始逐渐在国内软件行业中落地,并被广泛应用。自开源后,许多非阿里系公司选择使用 Dubbo,其中既有当当网、网易考拉等互联网公司,也有中国人寿、青岛海尔等传统企业。
2012 年 10 月 23 日 Dubbo 2.5.3 发布后,在 Dubbo 开源将满一周年之际,阿里基本停止了对 Dubbo 的主要升级。
2013 年,2014 年,更新了 2 次 Dubbo 2.4 的维护版本,然后停止了所有维护工作。至此,Dubbo 对 Srping 的支持也停留在了 Spring 2.5.6 版本上。
阿里停止维护和升级 Dubbo 期间,当当网开始维护自己的 Dubbo 分支版本 Dubbox,新增支持了新版本的 Spring,支持了 Rest 协议等,并对外开源了 Dubbox。同时,网易考拉也维护了自己的独立分支 Dubbok,可惜并未对外开源。
2017 年 9 月 7 日,Dubbo 悄悄在 GitHub 发布了 2.5.4 版本。随后,又迅速发布了 2.5.5、2.5.6、2.5.7 等版本。在 10 月举行的云栖大会上,阿里宣布 Dubbo 被列入集团重点维护开源项目,这也就意味着 Dubbo 起死回生,开始重新进入快车道。
2018 年 1 月 8 日,Dubbo 2.6.0 版本发布,新版本将之前当当网开源的 Dubbox 进行了合并,实现了 Dubbo 版本的统一整合。
2018 年 2 月 9 日,成为 Apache 基金会孵化项目。
自此,Dubbo 开始了两个长期维护的版本,Dubbo 2.6.x (包名:com.alibaba)稳定维护版本和 Dubbo 2.7.x (包名:org.apache)apache 孵化版本。
2018 ~ 2019 年,在此期间,Dubbo 发布了 4、5 个版本,并发布了 nodejs,python,go 等多语言的客户端。
2019 年 1 月,2.7.0 release 版本发布,这个 apache 版本支持了丰富的新特性,全新的 Dubbo Ops 控制台。时至 5 月,Dubbo 来到了 2.7.2 版本,期间积极引入了新的特性,支持 consul,nacos,etcd 等注册中心。
2019 年 5 月 21 号,经过了漫长的孵化期,Dubbo 成为Apache 基金会顶级项目。
虽然阿里内部原因 Dubbo 曾经一度暂停维护版本,但是框架本身的成熟度以及文档的完善程度,完全能满足各大互联网公司的业务需求,在国内有很多的成熟用户,在国内影响力较大。
2.2 Spring Cloud 社区
有强大的 Spring 社区、Netflix 等公司支持,并且开源社区贡献非常活跃。Netflix 很早就成功实践微服务,几年前把自家几乎整个微服务框架栈贡献给了社区,Spring Cloud主要是对Netflix开源组件的进一步封装。
社区支持强大,更新非常快,开发效率高。
3 功能完整度
在功能方面,Dubbo只是实现了服务治理,而Spring Cloud下面有24个子项目(可能还会新增)分别覆盖了微服务架构下的方方面面,服务治理只是其中的一个方面。在选择框架上,方案完整度恰恰是一个需要重点关注的内容。
3.1 Dubbo 功能
Dubbo具有调度、发现、监控、治理等功能,支持相当丰富的服务治理能力。Dubbo架构下,注册中心对等集群,并会缓存服务列表以备注册中心失效时继续提供发现功能,本身的服务发现结构有很强的可用性与健壮性,足够支持高访问量的网站。虽然,Dubbo自身只是实现了服务治理的基础,其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现,但是几乎大部分关键组件都能找到第三方开源来实现,这些组件主要来自于国内各家大型互联网企业的开源产品。
3.2 Spring Cloud 功能
Spring Cloud由众多子项目组成,如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等,提供了搭建分布式系统及微服务常用的工具,如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等,满足了构建微服务所需的所有解决方案。比如使用Spring Cloud Config 可以实现统一配置中心,对配置进行统一管理;使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现(Eureka)、智能路由(Zuul)、客户端负载均衡(Ribbon)。
但它并没有重复造轮子,而是选用目前各家公司 开发的比较成熟的、经得住实践考验的服务框架,通过Spring Boot 进行封装集成并简化其使用方式。基于Spring Boot,意味着其使用方式如Spring Boot 简单易用;能够与Spring Framework、Spring Boot、Spring Data 等其他Spring 项目完美融合,意味着能从Spring获得巨大的便利,意味着能减少已有项目的迁移成本。
3.3 功能对比
Dubbo 提供了各种 Filter,对于上述中“无”的要素,可以通过扩展 Filter 来完善。例如:
- 分布式配置:可以使用淘宝的 diamond、百度的 disconf 来实现分布式配置管理。
- 服务跟踪:可以使用京东开源的 Hydra,或者扩展 Filter 用 Zippin 来做服务跟踪。
- 批量任务:可以使用当当开源的 Elastic-Job、tbschedule。
从核心要素来看,Spring Cloud 更胜一筹,在开发过程中只要整合 Spring Cloud 的子项目就可以顺利的完成各种组件的融合,而 Dubbo 却需要通过实现各种 Filter 来做定制,开发成本以及技术难度略高。
Dubbo实现了服务治理的基础,但是要完成一个完备的微服务架构,还需要在各环节去扩展和完善以保证集群的健康,以减轻开发、测试以及运维各个环节上增加出来的压力,这样才能让各环节人员真正的专注于业务逻辑。而Spring Cloud依然发扬了Spring Source整合一切的作风,以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体,并继承了Spring Boot简单配置、快速开发、轻松部署的特点,让原本复杂的架构工作变得相对容易上手一些。所以,如果选择Dubbo请务必在各个环节做好整套解决方案的准备,不然很可能随着服务数量的增长,整个团队都将疲于应付各种架构上不足引起的困难。而如果选择Spring Cloud,相对来说每个环节都已经有了对应的组件支持,可能有些也不一定能满足你所有的需求,但是其活跃的社区与高速的迭代进度也会是你可以依靠的强大后盾。
4 技术特点
4.1 通讯协议
Dubbo:dubbo使用RPC通讯协议,提供序列化方式如下:
- dubbo:Dubbo缺省协议采用单一长连接和NIO异步通讯,适合于小数据量大并发的服务调用,以及服务消费者机器数远大于服务提供者机器数的情况
- rmi:RMI协议采用JDK标准的java.rmi.*实现,采用阻塞式短连接和JDK标准序列化方式
- Hessian:Hessian协议用于集成Hessian的服务,Hessian底层采用Http通讯,采用Servlet暴露服务,Dubbo缺省内嵌Jetty作为服务器实现
- http:采用Spring的HttpInvoker实现
- Webservice:基于CXF的frontend-simple和transports-http实现
Spring Cloud:Spring Cloud 使用HTTP协议的REST API。
dubbo支持各种通信协议,而且消费方和服务方使用长链接方式交互,通信速度上略胜Spring Cloud,如果对于系统的响应时间有严格要求,长链接更合适。
4.2 服务依赖方式
Dubbo 使用面向接口代理的高性能RPC调用,使得服务提供方(抽象接口)与调用方在代码上产生了强依赖,服务提供者需要不断将包含抽象接口的 jar 包打包出来供消费者使用。一旦打包出现问题,就会导致服务调用出错,并且以后发布部署会成很大问题(太强的依赖关系)。
Spring Cloud 支持 REST 服务调用,相比于 RPC,更加轻量化和灵活(服务之间只依赖一纸契约,不存在代码级别的强依赖),有利于跨语言服务的实现,以及服务的发布部署。服务提供方和服务消费方通过json方式交互,因此只需要定义好相关json字段即可,消费方和提供方无接口依赖。
Dubbo服务依赖略重,需要有完善的版本管理机制,但是程序入侵少。而Spring Cloud通过Json交互,省略了版本管理的问题,但是具体字段含义需要统一管理,自身Rest API方式交互,为跨平台调用奠定了基础。这也是为什么当当网在dubbox(基于Dubbo的开源扩展)中增加了对REST支持的原因之一。
4.3 组件运行流程
dubbo
Dubbo中的每个组件都是需要部署在单独的服务器上,gateway用来接受前端请求、聚合服务,并批量调用后台原子服务。每个service层和单独的DB交互。
gateWay:前置网关,具体业务操作,gateWay通过dubbo提供的负载均衡机制自动完成
Service:原子服务,只提供该业务相关的原子服务
Zookeeper:原子服务注册到zk上
Spring Cloud
所有请求都统一通过 API 网关(Zuul)来访问内部服务。
网关接收到请求后,从注册中心(Eureka)获取可用服务。
由 Ribbon 进行均衡负载后,分发到后端的具体实例。
微服务之间通过 Feign 进行通信处理业务。
业务部署方式相同,都需要前置一个网关来隔绝外部直接调用原子服务的风险。Dubbo需要自己开发一套API 网关,而Spring Cloud则可以通过Zuul配置即可完成网关定制。使用方式上Spring Cloud略胜一筹。
5 业务需求
在技术选型时需要考虑目前的业务需求,比如内部是否存在异构系统集成的问题,备选框架功能特性是否满足需求,http协议的通信对于应用的负载量会否真正成为瓶颈点等。
5.1 dubbo 适合的业务特点
根据Dubbo官方说法,在小数据量的情况下表现卓越。虽然Dubbo 支持短连接大数据量的服务提供模式,但绝大多数情况下都是使用长连接小数据量的模式提供服务使用的。所以,对于类似于电商等同步调用场景多并且能支撑搭建Dubbo 这套比较复杂环境的成本的产品而言,Dubbo 确实是一个可以考虑的选择。但如果产品业务中由于后台业务逻辑复杂、时间长而导致异步逻辑比较多的话,可能Dubbo 并不合适。
5.2 Spring Cloud 适合的业务特点
提起Spring Cloud,一些开发的第一印象是http+JSON的rest通信,性能上难堪重用,其实这也是一种误读。Spring Cloud也并不是和http+JSON强制绑定的,如有必要Thrift、protobuf等高效的RPC、序列化协议同样可以作为替代方案。
参考文章
【1】http://blog.itpub.net/31556476/viewspace-2645082/
【2】http://blog.didispace.com/microservice-framework/
【3】https://www.zhihu.com/question/45413135/answer/226794957
【4】https://cloud.tencent.com/developer/article/1116063
【5】https://www.zhihu.com/question/45413135