一、分类
简单来讲，Spring Cloud 的组件可以分为两类，如下：
自成体系型
Eureka。服务注册中心，所有的服务都必须注册在Eureka才能被发现被使用。
Dashboard、Hystrix。仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。
Zuul。API服务网关，进行路由分发和过滤。
Config。分布式配置中心，可以在本地仓库、SVN、Git、Jar包内进行项目配置信息的编辑。
锦上添花型
Ribbon。客户端负载均衡，特性有区域亲和、重试机制。
Hystrix熔断器。客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。
Feign。声明式服务调用，用法上等价于Ribbon+Hystrix。
Stream。消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区。
Bus。消息总线，配合Config仓库修改的一种Stream实现，配合文件更新以后不用重启项目即可刷新配置信息。
Sleuth。分布式服务追踪，需要搞清楚TraceID和SpanID以及抽样，如何与ELK整合。
二、具体用法
并不是每个微服务项目都要使用这些组件，一个项目中也不是会用到所有的组件。具体问题具体分析，灵活使用。
Eureka和Ribbon，是最基础的组件，一个注册服务，一个消费服务。我们可以将自己定义的API 接口注册到Eureka上，Eureka负责服务的注册于发现，解决接口之间相互调用的问题。但是Eureka只是维护了服务生产者、注册中心、服务消费者三者之间的关系，真正的服务消费者调用服务生产者提供的数据是通过Ribbon来实现的。同时，Ribbon起到负载均衡器的作用。
Hystrix为了优化Ribbon、防止整个微服务架构因为某个服务节点的问题导致崩溃，是个保险丝的作用。当有一个服务出现了故障，而服务的调用方不知道服务出现故障，若此时调用放的请求不断的增加，最后就会等待出现故障的依赖方 相应形成任务的积压，最终导致自身服务的瘫痪。Hystrix正是为了解决这种情况的，防止对某一故障服务持续进行访问。
Dashboard给Hystrix统计和展示用的，而且监控服务节点的整体压力和健康情况。
Turbine是集群收集器，服务于Dashboard的。
Feign是方便我们程序员些更优美的代码的。Feign 是一个声明web服务客户端，使用Feign 创建一个接口并对它进行注解，它具有可插拔的注解支持包括Feign注解与JAX-RS注解，Feign还支持可插拔的编码器与解码器，Spring Cloud 增加了对 Spring MVC的注解，Spring Cloud 集成 Ribbon 和 Eureka 提供的负载均衡的HTTP客户端 Feign。简单的可以理解为：Spring Cloud Feign 的出现使得Eureka和Ribbon的使用更为简单。
Zuul是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，加强安全保护的。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。
Config是为了解决所有微服务各自维护各自的配置，设置一个统一的配置中心，方便修改配置的。
Bus。可以在不关闭服务的情况下更新配置信息。
Stream是为了简化研发人员对MQ使用的复杂度，弱化MQ的差异性，达到程序和MQ松耦合。
Sleuth是因为单次请求在微服务节点中跳转无法追溯，解决任务链日志追踪问题的。
特殊成员Zipkin，之所以特殊是因为从jar包和包名来看它不属于Spring Cloud的一员，但是它与Spring Cloud Sleuth的抽样日志结合的天衣无缝。乍一看它与Hystrix的Dashboard作用有重叠的部分，但是他们的侧重点完全不同。Dashboard侧重的是单个服务的统计和是否可用，Zipkin侧重的监控环节时长。简言之，Dashboard侧重故障诊断，Ziokin侧重性能优化。
三、参考文章
我只是做个笔记，大神的原文在这里：
- https://blog.csdn.net/yejingtao703/article/details/78331442
- https://blog.csdn.net/xlgen157387/article/details/77773908