⽐较springcloud和dubbo，各⾃的优缺点是什么
dubbo由于是⼆进制的传输，占⽤带宽会更少
springCloud是http协议传输，带宽会⽐较多，同时使⽤http协议⼀般会使⽤JSON报⽂，消耗会更⼤
dubbo的开发难度较⼤，原因是dubbo的jar包依赖问题很多⼤型⼯程⽆法解决
springcloud的接⼝协议约定⽐较⾃由且松散，需要有强有⼒的⾏政措施来限制接⼝⽆序升级
dubbo的注册中⼼可以选择zk,redis等多种，springcloud的注册中⼼只能⽤eureka或者⾃研
但如果我选，我会⽤springcloud。
从公司整体规划：我不会选择很久没⼈维护的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的样⼦，很多你还需要改造。⽽DUBBO相反，⼀直宣称⾃⼰是“⼀套全⽅⾯的服务化⽅案”。。。。。。纯服务化顶个鸟⽤，任何系统都是相辅相成配套的，⼀个完整的系统，要有前台、中台、后台、前台包括前端和交互，中台包括交易、任务、数据，
后台包括财务、账户、管理...........单纯的服务化解决不了“任何问题”，唯有体系才能解决。在这个层⾯，springcloud是个往“体系”⽅向发展的⽅案，⽽dubbo仅是个⼯具⽽已，两者相⽐，就好⽐始祖鸟与草履⾍的区别。
从技术实⼒层⾯：对⽐双⽅的源码，不得不说dubbo作者的技术能⼒要⾼于springCloud，⽽springBoot的作者技术能⼒要⾼于dubbo。即：springboot>dubbo>springcloud。我喜欢springboot这种⼤道⾄简的风格，keep it simple and stupid。⽽dubbo好嘛......你先看看dubboSPI，再看看Protocol$Adpative⾥⾯那⼀绕来绕去的瞎⼏把绕的玩意⼉，你会迅速判断出：这屌丝在炫技。尽管dubbo从上之下分为⼗层四五⼗个组件，第⼀感官上是哇塞好全⾯好伟⼤的样⼦，但深⼊之后你会觉得，这技术是很炫，设计的确实很全⾯，但是⽤不到，例如：请各位⼤神给我解释⼀下，在zookeeper地址中，使⽤逗号分隔和分号分隔地址的区别。。。。。⽤途不⼤，但是代码⾥为了这个就⾛向了“完全不同”的⼀条分⽀。⽤俗语评价，就是“臃肿且⽆⽤代码过多，在⽂档⾥还⾮得为了这个说出123456来”。说完dubbo 再说它没有技术含量，完全没有，就是⼀堆简单组件拼装在⼀起，如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 Config、Spring 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获得巨⼤的便利，意味着能减少已有项⽬的迁移成本。
其实，从社区活跃度和功能完整度，再对照业务需求和团队状况，基本可以确定如何选型。这⾥分享⽹易考拉海购实践以及团队选型的⼼声：
当前开源上可选⽤的微服务框架主要有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框架内部就必须要组建⼀个维护团队，先不论你要准备要集成多少功能做多少改造，作为⼀个⽀撑所有⼯程正常运转的基础组件，问题的及时响应与解答、重⼤缺陷的及时修复能⼒就已⾜够重要。
详见⽹易考拉海购Dubbok框架优化详解
鉴于服务发现对服务化架构的重要性，再补充⼀点：Dubbo 实践通常以ZooKeeper 为注册中⼼（Dub
bo 原⽣⽀持的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版本，到了后期会更加完善和稳定。
springcloud难学吗
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需要⾃⼰组装；整机的性能有保证，组装的机⼦更⾃由。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。