对比参照表：
| name | Dubbo | springcloud |
| 服务注册中心 | Zookeeper | SpringCloud Netflix Eureka |
| 服务调用方式 | RPC | REST Api |
| 服务监控 | Dubbo-monitor | Spring Boot Admin |
| 断路器 | 不完善 | SpringCloud Netflix Hystrix |
| 服务网关 | 无 | SpringCloud Netflix Zuul |
| 分布式配置 | 无 | SpringCloud Config |
| 服务跟踪 | 无 | SpringCloud Sleuth |
| 消息总线 | 无 | SpringCloud Bus |
| 数据流 | 无 | SpringCloud Stream |
| 批量任务 | 无 | SpringCloud task |
名词解释：
SpringCloud Netflix Eureka：
eureka服务:用以提供服务注册、发现
eureka-server: 相对client端的服务端，为客户端提供服务
eureka-client:客户端，通过向eureka服务发现注册的可用的eureka-server，向后端发送请求
REST Api：
是通信方式，不同与Dubbo的RPC通信
Spring Boot Admin：
当前处于活跃状态的会话数量、当前应用的并发数、延迟以及其他度量信息
SpringCloud Netflix Hystrix：
Hystrix的断路器就像我们家庭电路中的保险丝, 一旦后端服务不可用, 断路器会直接切断请求链, 避免发送大量无效 请求影响系统吞吐量, 并且断路器有自我检测并恢复的能力.
SpringCloud Netflix Zuul：
它就解决了上面的问题，你想调用某个服务，它会给你映射，把你服务的IP地址映射成某个路径，你输入该路径， 它匹配到了，它就去替你访问这个服务，它会有个请求转发的过程，像Nginx一样，服务机器的具体实例，它不会 直接去访问IP，它会去Eureka注册中心拿到服务的实例ID，即服务的名字。我再次使用客户端的负载均衡ribbon访 问其 中服务实例中的一台。API网关主要为了服务本身对外的调用该怎么调用来解决的，还有解决权限校验的问 题，你可以在这里整合调用一系列过滤器的，例如整合shiro,springsecurity之类的东西
SpringCloud Config：
a.spring cloud config server 作为配置中心的服务端：
1.拉取配置时更新git仓库副本，保证是最新结果
2.支持数据结构丰富，yml, json, properties 等
3.配合 eureke 可实现服务发现，配合 cloud bus 可实现配置推送更新
4.配置存储基于 git 仓库，可进行版本管理
5.简单可靠，有丰富的配套方案
b.Spring Cloud Config Client 客户端：
1.Spring Boot项目不需要改动任何代码，加入一个启动配置文件指明使用ConfigServer上哪个配置文件即可
SpringCloud Sleuth:
随着分布式系统越来越复杂，你的一个请求发过发过去，各个微服务之间的跳转，有可能某个请求某一天压力太大了，一 个请求过去没响应，一个请求下去依赖了三四个服务，但是你去不知道哪一个服务出来问题，这时候我是不是需要对微服务进行追踪呀？监控一个请求的发起，从服务之间传递之间的过程，我最好记录一下，记录每一个的耗时多久，一旦出了问题，我们就可以针对性的进行优化，是要增加节点，减轻压力，还是服务继续拆分，让逻辑更加简单点呢？这时候springcloud-sleuth集成zipkin能帮我们解决这些服务追踪问题。
Span：基本工作单元，例如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址)
span在不断的启动和停止，同时记录了时间信息，当你创建了一个span，你必须在未来的某个时刻停止它。
Trace：一系列spans组成的一个树状结构，例如，如果你正在跑一个分布式大数据工程，你可能需要创建一个trace。
Annotation：用来及时记录一个事件的存在，用于定义请求的开始和停止的一些核心注释是：
1.cs- Client Sent -客户端发起一个请求，这个annotion描述了这个span的开始
2.sr- Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络延迟
3.ss- Server Sent -注解表明请求处理的完成(当请求返回客户端)，如果ss减去sr时间戳便可得到服务端需要的处理请求时间
4.cr- Client Received -表明span的结束，客户端成功接收到服务端的回复，如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间
SpringCloud Bus:
你的配置信息改变了，需要及时修改内存中的配置信息。这时候我们就不要忘记消息队列的发布订阅模型。让所有为服务来订阅这个事件，当这个事件发生改变了，就可以通知所有微服务去更新它们的内存中的配置信息。这时Bus消息总线就能解决，你只需要在springcloud Config Server端发出refresh，就可以触发所有微服务更新了。
Spring Cloud Bus除了支持RabbitMQ的自动化配置之外，还支持现在被广泛应用的Kafka。
SpringCloud Stream:
是一个构建消息驱动微服务的框架,应用程序通过 inputs 或者 outputs 来与 Spring Cloud Stream 中binder 交互，通过我们配置来 binding ，而 Spring Cloud Stream 的 binder 负责与消息中间件交互。所以，我们只需要搞清楚如何与 Spring Cloud Stream 交互就可以方便使用消息驱动的方式。通过使用Spring Integration来连接消息代理中间件以实现消息事件驱动。Spring Cloud Stream 为一些供应商的消息中间件产品提供了个性化的自动化配置实现，引用了发布-订阅、消费组、分区的三个核心概念。目前仅支持RabbitMQ、Kafka。
SpringCloud task:
主要解决短命微服务的任务管理，任务调度的工作，比如说某些定时任务晚上就跑一次，或者某项数据分析临时就跑几次。