几个Spring Cloud核心组件，在微服务架构中，分别扮演的角色：
- Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里
- Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台
- Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求
- Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
- Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务
////////////////////////////////////////////////////////
Feign
feign 一般是用于服务消费，什么叫服务消费呢， 譬如你有A服务，B服务。在B服务中需要调用A服务 （即B作为服务提供者，A作为服务消费者），获取结果，进行下一步动作，这个时候你可以使用resttemplate,也可以使用feign来写。
zuul
zuul起一个路由，分发服务（比如https://www.oschina.net/tweet/路径交给feign，而https://www.oschina.net/blog/交给bibbon）的作用，偶尔还能和自定义的过滤器协同工作。feign和ribbon都是做负载均衡（服务消费）的，和hystrix结合可以爆发强大的威力。
其余的组件，例如eureka、config client/server、zipkin、hystrixdashboard、sleuth、consul、turbine根据项目需要使用。
Ribbon，客户端负载均衡，特性有区域亲和、重试机制。
Hystrix，客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。
Feign，声明式服务调用，本质上就是Ribbon+Hystrix
Stream，消息驱动，有Sink、Source、Processor三种通道，特性有订阅发布、消费组、消息分区。
Bus，消息总线，配合Config仓库修改的一种Stream实现，
Sleuth，分布式服务追踪，需要搞清楚TraceID和SpanID以及抽样，如何与ELK整合。
独挑大梁，独自启动不需要依赖其它组件。
Eureka，服务注册中心，特性有失效剔除、服务保护。
Dashboard，Hystrix仪表盘，监控集群模式和单点模式，其中集群模式需要收集器Turbine配合。
Zuul，API服务网关，功能有路由分发和过滤。
Config，分布式配置中心，支持本地仓库、SVN、Git、Jar包内配置等模式，
每个组件都不是平白无故的产生的，是为了解决某一特定的问题而存在。
Eureka和Ribbon，是最基础的组件，一个注册服务，一个消费服务。
Hystrix为了优化Ribbon、防止整个微服务架构因为某个服务节点的问题导致崩溃，是个保险丝的作用。
Dashboard给Hystrix统计和展示用的，而且监控服务节点的整体压力和健康情况。
Turbine是集群收集器，服务于Dashboard的。
Feign是方便我们程序员写更优美的代码的(消费服务)
Zuul是加在整个微服务最前沿的防火墙和代理器，隐藏微服务结点IP端口信息，加强安全保护的。
Config是为了解决所有微服务各自维护各自的配置，设置一个统一的配置中心，方便修改配置的。
Bus是因为config修改完配置后各个结点都要refresh才能生效实在太麻烦，所以交给bus来通知服务节点刷新配置的。
Stream是为了简化研发人员对MQ使用的复杂度，弱化MQ的差异性，达到程序和MQ松耦合。
Sleuth是因为单次请求在微服务节点中跳转无法追溯，解决任务链日志追踪问题的。
特殊成员Zipkin，之所以特殊是因为从jar包和包名来看它不属于Spring Cloud的一员，但是它与Spring Cloud Sleuth的抽样日志结合的天衣无缝。乍一看它与Hystrix的Dashboard作用有重叠的部分，但是他们的侧重点完全不同。Dashboard侧重的是单个服务的统计和是否可用，Zipkin侧重的监控环节时长。简言之，Dashboard侧重故障诊断，Ziokin侧重性能优化。
//////////////////////////////////////////////////////
- Spring Cloud Config：配置管理开发工具包，可以让你把配置放到远程服务器，目前支持本地存储、Git以及Subversion。
- Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。
- Spring Cloud Netflix：针对多种Netflix组件提供的开发工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。
- Netflix Eureka：云端负载均衡，一个基于 REST 的服务，用于定位服务，以实现云端的负载均衡和中间层服务器的故障转移。
- Netflix Hystrix：容错管理工具，旨在通过控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。
- Netflix Zuul：边缘服务工具，是提供动态路由，监控，弹性，安全等的边缘服务。
- Netflix Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。
- Spring Cloud for Cloud Foundry：通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。
- Spring Cloud Sleuth：日志收集工具包，封装了Dapper,Zipkin和HTrace操作。
- Spring Cloud Data Flow：大数据操作工具，通过命令行方式操作数据流。\
- Spring Cloud Security：安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。
- Spring Cloud Consul：封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。
- Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服务注册和发现。
- Spring Cloud Stream：数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。
- Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。
///////////////////////////////////////////////////
Eureka/Consul：服务发现 （根据情况选择一个）
Hystrix：断路器
Zuul：智能路由
Ribbon/Feign：客户端负载均衡 （Feign用的更多）
Turbine：集群监控
Springcloud-config：远程获取配置文件
////////////////////////////////////////////////
我们从整体上来看一下Spring Cloud各个组件如何来配套使用：
从上图可以看出Spring Cloud各个组件相互配合，合作支持了一套完整的微服务架构。
其中Eureka负责服务的注册与发现，很好将各服务连接起来
Hystrix 负责监控服务之间的调用情况，连续多次失败进行熔断保护。
Hystrix dashboard,Turbine 负责监控 Hystrix的熔断情况，并给予图形化的展示
Spring Cloud Config 提供了统一的配置中心服务
当配置文件发生变化的时候，Spring Cloud Bus 负责通知各服务去获取最新的配置信息
所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关的作用
最后我们使用Sleuth+Zipkin将所有的请求数据记录下来，方便我们进行后续分析
Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。
微服务架构是一种趋势，Spring Cloud提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。
从现在开始，我这边会将近期研发的spring cloud微服务云架构的搭建过程和精髓记录下来，帮助更多有兴趣研发spring cloud框架的朋友，希望可以帮助更多的好学者。大家来一起探讨spring cloud架构的搭建过程及如何运用于企业项目。