SpringCloud基础组件总结，与Dubbo框架、SpringBoot框架对比分析

SpringCloud基础组件总结，与Dubbo框架、SpringBoot框架对比分析
本文源码：GitHub·点这里 || GitEE·点这里

一、基础组件总结

1、文章阅读目录

1)、基础组件

Eureka组件，服务注册与发现

Ribbon和Feign组件，实现负载均衡

Hystrix组件，实现服务熔断

Turbine组件，实现微服务集群监控

Zuul组件，实现路由网关控制

Config组件，实现配置统一管理

Zipkin组件，实现请求链路追踪

2)、应用案例

基于Shard-Jdbc分库分表，数据库扩容方案

基于SpringCloud实现Shard-Jdbc的分库分表扩容

3)、后续更新

该案例主要基于SpringCloud2版本，演示微服务在实际开发中的应用。

<modules>
    <!-- 客户端接口层 -->
    <module>storey-client-web</module>
    <!-- 公共代码块层 -->
    <module>storey-block-code</module>
    <!-- 中间件管理层 -->
    <module>storey-middle-soft</module>
    <!-- 数据 中 心层 -->
    <module>storey-data-center</module>
    <!-- 微服务组件层 -->
    <module>storey-cloud-ware</module>
</modules>

1、采用版本

Spring： 5.0+
SpringBoot： 2.0+
SpringCloud: 2.0+

2、常用组件概念

Eureka组件
Eureka是一种基于REST的服务，主要用于AWS云，用于定位服务，以实现中间层服务器的负载平衡和故障转移。此服务称为EurekaServer。客户端组件EurekaClient，它使与服务的交互变得更加容易。

Ribbon和Feign组件
Ribbon是一个客户端的负载均衡（Load Balancer，简称LB）器，它提供对大量的HTTP和TCP客户端的访问控制。

Feign 是一个声明式的 Web Service 客户端。它的出现使开发 Web Service 客户端变得很简单。使用 Feign 只需要创建一个接口加上对应的注解，比如：@FeignClient 接口类注解。

Hystrix组件
微服务架构中某个微服务发生故障时，要快速切断服务，提示用户，后续请求，不调用该服务，直接返回，释放资源，这就是服务熔断。

Turbine组件
微服务架构中为了保证程序的可用性，防止程序出错导致网络阻塞，出现了断路器模型。断路器的状况反应程序的可用性和健壮性，它是一个重要指标。HystrixDashboard是作为断路器状态的一个组件，提供了数据监控和直观的图形化界面。

Zuul组件
Zuul 网关主要提供动态路由，监控，弹性，安全管控等功能。在分布式的微服务系统中，系统被拆为了多个微服务模块，通过zuul网关对用户的请求进行路由，转发到具体的后微服务模块中。

Config组件
在微服务系统中，服务较多，相同的配置：如数据库信息、缓存、参数等，会出现在不同的服务上，如果一个配置发生变化，需要修改很多的服务配置。spring cloud提供配置中心，来解决这个场景问题。

Zipkin组件
Zipkin是SpringCloud微服务系统中的一个组件，实现了链路追踪解决方案。可以定位一个请求到底请求了哪些具体的服务。在复杂的微服务系统中，如果请求发生了异常，可以快速捕获问题所在的服务。

二、Boot 对比Cloud

SpringBoot专注于快速开发单个微服务。SpringCloud是关注全局的微服务协调框架，它将SpringBoot开发的单个微服务整合管理，并为微服务之间提供，配置管理、服务发现、断路器、路由网关等集成服务，SpringCloud依赖SpringBoot。

三、Dubbo对比Cloud

1、调用方式对比

服务调用方式是 Dubbo 和 Spring Cloud 重要不同点,熟悉RPC/HTTP/REST概念，有助对比 Dubbo 和SpringCloud。RPC 是远端过程调用，其调用协议通常包含传输协议和编码协议。RPC调用是面向服务的封装，针对服务的可用性和效率等都做了优化。http是超文本传输协议，RPC 也可以用http作为传输协议，但一般是用 tcp作为传输协议。

2、执行性能对比

Dubbo 采用单一长连接和NIO异步通讯（保持连接/轮询处理），使用自定义报文的TCP协议，并且序列化使用定制Hessian2框架，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况，但不适用于传输大数据的服务调用。Spring Cloud 直接使用 HTTP 协议，在性能上弱于Dubbo。

3、注册中心对比

这里通常指ZooKeeper(Dubbo注册中心)和Eureka(Cloud注册中心)的对比。分布式领域著名的CAP理论（C：数据一致性，A：服务可用性，P：分区故障的容错性），Zookeeper保证的是CP，但对于服务发现而言，可用性比数据一致性更加重要，AP胜过CP，而 Eureka 设计则遵循 AP 原则。

4、框架生态对比

Dubbo 专注 RPC 和服务治理，Spring Cloud 则是一个微服务架构生态。

四、源代码地址

GitHub·地址
https://github.com/cicadasmile/spring-cloud-base
GitEE·地址
https://gitee.com/cicadasmile/spring-cloud-base

=============================================

比较spring cloud和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包升级问题，把每个人的电脑都操作过，尤其每个人电脑的库路径、命令、快捷键、键盘，鼠标快慢都不一样，脑补一下咯。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框架内部就必须要组建一个维护团队，先不论你要准备要集成多少功能做多少改造，作为一个支撑所有工程正常运转的基础组件，问题的及时响应与解答、重大缺陷的及时修复能力就已足够重要。
详见网易考拉海购Dubbok框架优化详解

鉴于服务发现对服务化架构的重要性，再补充一点：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需要自己组装；整机的性能有保证，组装的机子更自由。