Spring Cloud 和 Dubbo,到底用哪个好?

Spring Cloud是http协议传输,带宽会比较多,同时使用http协议一般会使用JSON报文,消耗会更大

dubbo的开发难度较大,原因是dubbo的jar包依赖问题很多大型工程无法解决

springcloud的接口协议约定比较自由且松散,需要有强有力的行政措施来限制接口无序升级

dubbo的注册中心可以选择zk,redis等多种,springcloud的注册中心只能用eureka或者自研

但如果我选,我会用Spring Cloud

从公司整体规划:我不会选择很久没人维护的dubbo,重启之后也未必是原班人马

从程序员招聘难度:招springcloud的程序员会更好招,因为更新更炫

从系统结构简易程序:springcloud的系统结构更简单、“注册+springmvc=springcloud”,而dubbo各种复杂的Url,protocol,register,invocation,dubbofilter,dubboSPI,dubbo序列化..........炫技的成分更多一些

从性能:dubbo的网络消耗小于springcloud,但是在国内95%的公司内,网络消耗不是什么太大问题,如果真的成了问题,通过压缩、二进制、高速缓存、分段降级等方法,很容易解

从开发难易度:dubbo的神坑是jar包依赖,开发阶段难度极大,我曾经带一个三十人的团队,因为jar包升级问题,把每个人的电脑都操作过,尤其每个人电脑的库路径、命令、快捷键、键盘,鼠标快慢都不一样,那会儿我默默的在心中艹了dubbo发明者全家老小一百二十遍。

springcloud比较自由,但带来的问题是无法“强力约束接口规范”,建议用行政方式解决,且我们团队的强力行政约束做的还是比较好的,在接口管控层面比较强效,一个没有行政组织能力的IT团队真的是个废渣,用什么框架都不好使。

从后续改进:dubbo的改进是通过dubbofilter,很多东西没有,需要自己继承,如监控,如日志,如限流,如追踪。springcloud自己带了很多监控、限流措施,但是功能可能和欧美习惯相同,国内需要进行适当改造,但更简单,就是ServletFilter而已,但是总归比dubbo多一些东西是好的

从配套措施:springcloud一直宣称自己是“一套全方面的解决方案”。。。。。。我起初信了,后来发现上当了,实话说:有,但是不是很健全,100分打50的样子,很多你还需要改造。

关注微信公众号:Java技术栈,在后台回复:cloud,可以获取我整理的 N 篇最新Spring Cloud 教程,都是干货。

而DUBBO相反,一直宣称自己是“一套全方面的服务化方案”。。。。。。

纯服务化顶个鸟用,任何系统都是相辅相成配套的,一个完整的系统,要有前台、中台、后台、前台包括前端和交互,中台包括交易、任务、数据,后台包括财务、账户、管理...........单纯的服务化解决不了“任何问题”,唯有体系才能解决。

在这个层面,springcloud是个往“体系”方向发展的方案,而dubbo仅是个工具而已,两者相比,就好比始祖鸟与草履虫的区别。

从技术实力层面:对比双方的源码,不得不说dubbo作者的技术能力要高于springCloud,而springBoot的作者技术能力要高于dubbo。

即:springboot>dubbo>springcloud。我喜欢springboot这种大道至简的风格,keep it simple and stupid。

而dubbo好嘛......你先看看dubboSPI,再看看Protocol$Adpative里面那一群绕来绕去的瞎几把绕的玩意儿,你会迅速判断出:这群屌丝在炫技。

尽管dubbo从上之下分为十层四五十个组件,第一感官上是哇塞好全面好伟大的样子,但深入之后你会觉得,这技术是很炫,设计的确实很全面,但是用不到,例如:请各位大神给我解释一下,在zookeeper地址中,使用逗号分隔和分号分隔地址的区别。。。。。

用途不大,但是代码里为了这个就走向了“完全不同”的一条分支。用俗语评价,就是“臃肿且无用代码过多,在文档里还非得为了这个说出123456来”。

说完dubbo再说springCloud........它没有技术含量,完全没有,就是一堆简单组件拼装在一起,如configserver、eurekaserver、robin、feignClient、htstrix等,每个都特别简单,没什么技术含量,但我喜欢这种的,就喜欢这种大道至简的简单。

最后说springBoot,我要用“纯粹”两个字来评价这个框架,真的很纯粹,并且从其代码架构的总体思路一致性,目标的纯粹性,具体模块的干净利落,确实是个好框架,值得大家一读。

从系统应用层面:在技术实力满分一百能打85分的鄙人的眼中,dubbo和springcloud,不就是两个框架么?我们是要拯救世界的人,这俩块鹅卵石一块圆的一块方的,能垫脚就行,没有区别。

简而言之,Dubbo确实类似于Spring Cloud的一个子集,Dubbo功能和文档完善,在国内有很多的成熟用户,然而鉴于Dubbo的社区现状(曾经长期停止维护,2017年7月31日团队又宣布重点维护),使用起来还是有一定的门槛。

Dubbo具有调度、发现、监控、治理等功能,支持相当丰富的服务治理能力。Dubbo架构下,注册中心对等集群,并会缓存服务列表已被数据库失效时继续提供发现功能,本身的服务发现结构有很强的可用性与健壮性,足够支持高访问量的网站。

虽然Dubbo 支持短连接大数据量的服务提供模式,但绝大多数情况下都是使用长连接小数据量的模式提供服务使用的。

所以,对于类似于电商等同步调用场景多并且能支撑搭建Dubbo 这套比较复杂环境的成本的产品而言,Dubbo 确实是一个可以考虑的选择。

但如果产品业务中由于后台业务逻辑复杂、时间长而导致异步逻辑比较多的话,可能Dubbo 并不合适。同时,对于人手不足的初创产品而言,这么重的架构维护起来也不是很方便。

Spring Cloud由众多子项目组成,如Spring Cloud ConfigSpring Cloud Netflix、Spring Cloud Consul 等,提供了搭建分布式系统及微服务常用的工具,如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局锁、选主、分布式会话和集群状态等,满足了构建微服务所需的所有解决方案。

比如使用Spring Cloud Config 可以实现统一配置中心,对配置进行统一管理;使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现(Eureka)、智能路由(Zuul)、客户端负载均衡(Ribbon)。

但它并没有重复造轮子,而是选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架(我们需要特别感谢Netflix ,这家很早就成功实践微服务的公司,几年前把自家几乎整个微服务框架栈贡献给了社区,Spring Cloud主要是对Netflix开源组件的进一步封装),通过Spring Boot 进行封装集成并简化其使用方式。

基于Spring Boot,意味着其使用方式如Spring Boot 简单易用;能够与Spring Framework、Spring Boot、Spring Data 等其他Spring 项目完美融合,意味着能从Spring获得巨大的便利,意味着能减少已有项目的迁移成本。

关注微信公众号:Java技术栈,在后台回复:boot,可以获取我整理的 N 篇最新Spring Boot 教程,都是干货。

其实,从社区活跃度和功能完整度,再对照业务需求和团队状况,基本可以确定如何选型。这里分享网易考拉海购实践以及团队选型的心声:

当前开源上可选用的微服务框架主要有Dubbo、Spring Cloud等,鉴于Dubbo完备的功能和文档且在国内被众多大型互联网公司选用,考拉自然也选择了Dubbo作为服务化的基础框架。

其实相比于Dubbo,Spring Cloud可以说是一个更完备的微服务解决方案,它从功能性上是Dubbo的一个超集,个人认为从选型上对于一些中小型企业Spring Cloud可能是一个更好的选择。

提起Spring Cloud,一些开发的第一印象是http+JSON的rest通信,性能上难堪重用,其实这也是一种误读。

微服务选型要评估以下几点:内部是否存在异构系统集成的问题;备选框架功能特性是否满足需求;http协议的通信对于应用的负载量会否真正成为瓶颈点(Spring Cloud也并不是和http+JSON强制绑定的,如有必要Thrift、protobuf等高效的RPC、序列化协议同样可以作为替代方案);社区活跃度、团队技术储备等。

作为已经没有团队持续维护的开源项目,选择Dubbo框架内部就必须要组建一个维护团队,先不论你要准备要集成多少功能做多少改造,作为一个支撑所有工程正常运转的基础组件,问题的及时响应与解答、重大缺陷的及时修复能力就已足够重要。

鉴于服务发现对服务化架构的重要性,再补充一点:Dubbo 实践通常以ZooKeeper 为注册中心(Dubbo 原生支持的Redis 方案需要服务器时间同步,且性能消耗过大)。

针对分布式领域著名的CAP理论(C——数据一致性,A——服务可用性,P——服务对网络分区故障的容错性),Zookeeper 保证的是CP ,但对于服务发现而言,可用性比数据一致性更加重要 ,而 Eureka 设计则遵循AP原则 。

为什么选择使用Spring Cloud而放弃了Dubbo?

可能大家会问,为什么选择了使用Dubbo之后,而又选择全面使用Spring Cloud呢?其中有几个原因:

1)从两个公司的背景来谈:Dubbo,是阿里巴巴服务化治理的核心框架,并被广泛应用于中国各互联网公司;Spring Cloud是大名鼎鼎的Spring家族的产品。

阿里巴巴是一个商业公司,虽然也开源了很多的顶级的项目,但从整体战略上来讲,仍然是服务于自身的业务为主。Spring专注于企业级开源框架的研发,不论是在中国还是在世界上使用都非常广泛,开发出通用、开源、稳健的开源框架就是他们的主业。

2)从社区活跃度这个角度来对比,Dubbo虽然也是一个非常优秀的服务治理框架,并且在服务治理、灰度发布、流量分发这方面做的比Spring Cloud还好,除过当当网在基础上增加了rest支持外,已有两年多的时间几乎都没有任何更新了。在使用过程中出现问题,提交到github的Issue也少有回复。

相反Spring Cloud自从发展到现在,仍然在不断的高速发展,从github上提交代码的频度和发布版本的时间间隔就可以看出,现在Spring Cloud即将发布2.0版本,到了后期会更加完善和稳定。

3) 从整个大的平台架构来讲,dubbo框架只是专注于服务之间的治理,如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成,这样无形中使用dubbo的难度就会增加。Spring Cloud几乎考虑了服务治理的方方面面,更有Spring Boot这个大将的支持,开发起来非常的便利和简单。

4)从技术发展的角度来讲,Dubbo刚出来的那会技术理念还是非常先进,解决了各大互联网公司服务治理的问题,中国的各中小公司也从中受益不少。

经过了这么多年的发展,互联网行业也是涌现了更多先进的技术和理念,Dubbo一直停滞不前,自然有些掉队,有时候我个人也会感到有点可惜,如果Dubbo一直沿着当初的那个路线发展,并且延伸到周边,今天可能又是另一番景象了。

Spring 推出Spring Boot/Cloud也是因为自身的很多原因。Spring最初推崇的轻量级框架,随着不断的发展也越来越庞大,随着集成项目越来越多,配置文件也越来越混乱,慢慢的背离最初的理念。

随着这么多年的发展,微服务、分布式链路跟踪等更多新的技术理念的出现,Spring急需一款框架来改善以前的开发模式,因此才会出现Spring Boot/Cloud项目,我们现在访问Spring官网,会发现Spring Boot和Spring Cloud已经放到首页最重点突出的三个项目中的前两个,可见Spring对这两个框架的重视程度。

总结一下,dubbo曾经确实很牛逼,但是Spring Cloud是站在近些年技术发展之上进行开发,因此更具技术代表性。

spring cloud整机,dubbo需要自己组装;整机的性能有保证,组装的机子更自由。

作者:Crazy晓枫

https://blog.csdn.net/u010664947/article/details/80007767

END

学习资料:

分享一份最新 Java 架构师学习资料

最近热文:

1、远程办公一周,我有话说!

2、写了一首 Java 表白诗,女朋友不愁了!

3、阿里面试 Java 都问什么?万字总结!

4、Vert.x!这是目前最快的 Java 框架

5、用户密码到底要怎么加密存储?

6、2020 最新 Java 面试题整理,建议收藏!

7、Oracle JDK 和 OpenJDK 有什么区别?

8、Spring 解决循环依赖的 3 种方式!

9、18 个示例带你掌握 Java 8 日期时间处理!

10、图文并茂,傻瓜都能看懂的JVM内存布局

短视频:

1、switch case 支持哪几种数据类型?

2、一图搞懂 Java 中的异常分类!

3、Java 8 中的永久代去哪了?

4、Java 和 Javascript 的区别是什么?

公众号干货实在太多了,扫码关注Java技术栈公众号看更多。

点击「阅读原文」带你飞~

展开阅读全文

Git 实用技巧

11-24
这几年越来越多的开发团队使用了Git,掌握Git的使用已经越来越重要,已经是一个开发者必备的一项技能;但很多人在刚开始学习Git的时候会遇到很多疑问,比如之前使用过SVN的开发者想不通Git提交代码为什么需要先commit然后再去push,而不是一条命令一次性搞定; 更多的开发者对Git已经入门,不过在遇到一些代码冲突、需要恢复Git代码时候就不知所措,这个时候哪些对 Git掌握得比较好的少数人,就像团队中的神一样,在队友遇到 Git 相关的问题的时候用各种流利的操作来帮助队友于水火。 我去年刚加入新团队,发现一些同事对Git的常规操作没太大问题,但对Git的理解还是比较生疏,比如说分支和分支之间的关联关系、合并代码时候的冲突解决、提交代码前未拉取新代码导致冲突问题的处理等,我在协助处理这些问题的时候也记录各种问题的解决办法,希望整理后通过教程帮助到更多对Git操作进阶的开发者。 本期教程学习方法分为“掌握基础——稳步进阶——熟悉协作”三个层次。从掌握基础的 Git的推送和拉取开始,以案例进行演示,分析每一个步骤的操作方式和原理,从理解Git 工具的操作到学会代码存储结构、演示不同场景下Git遇到问题的不同处理方案。循序渐进让同学们掌握Git工具在团队协作中的整体协作流程。 在教程中会通过大量案例进行分析,案例会模拟在工作中遇到的问题,从最基础的代码提交和拉取、代码冲突解决、代码仓库的数据维护、Git服务端搭建等。为了让同学们容易理解,对Git简单易懂,文章中详细记录了详细的操作步骤,提供大量演示截图和解析。在教程的最后部分,会从提升团队整体效率的角度对Git工具进行讲解,包括规范操作、Gitlab的搭建、钩子事件的应用等。 为了让同学们可以利用碎片化时间来灵活学习,在教程文章中大程度降低了上下文的依赖,让大家可以在工作之余进行学习与实战,并同时掌握里面涉及的Git不常见操作的相关知识,理解Git工具在工作遇到的问题解决思路和方法,相信一定会对大家的前端技能进阶大有帮助。
©️2020 CSDN 皮肤主题: 大白 设计师: CSDN官方博客 返回首页
实付0元
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值