公众号：MarkerHub，网站：https://markerhub.com
Cat 哥领读：
Spring Cloud，Spring 体系一站式解决方案，我更喜爱，你们呢？
作者：Crazy 晓枫
https://blog.csdn.net/u010664…
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 的样子，很多你还须要革新。
而 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 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 框架外部就必须要组建一个保护团队，先不管你要筹备要集成多少性能做多少革新，作为一个撑持所有工程失常运行的根底组件，问题的及时响应与解答、重大缺点的及时修复能力就已足够重要。
鉴于服务发现对服务化架构的重要性，再补充一点：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 须要本人组装；整机的性能有保障，组装的机子更自在。
举荐浏览
太赞了，这个 Java 网站，什么我的项目都有！https://markerhub.com
这个 B 站的 UP 主，讲的 java 真不错！
太赞了！最新版 Java 编程思维能够在线看了！