我们为什么要使用Spring Cloud？
两个需要好好看看：
Spring Cloud是一个集成了众多开源的框架，利用Spring Boot的开发便利性实现了服务治理、服务注册与发现、负载均衡、数据监控，REST API发布方式等，基本囊括了分布式框架所需要的所有功能。是一套易开放、易部署、易维护的分布式开发工具包。在详细的了解Spring Cloud中所使用的各个组件之前，我们先了解下微服务框架的前世今生。
单体架构
在网站开发的前期，项目面临的流量相对较少，单一应用可以实现我们所需要的功能，从而减少开发、部署和维护的难度。这种用于简单的增删改查的数据访问框架（ORM）十分的重要。
ORM(Object Relational Mapping) 参考：ORM百科
垂直应用架构
当用户访问量不断的提升，单一应用需要不断的增加服务器来应对，同时将单一的应用拆分成多个应用用来处理提升效率。这种用于加速Web前端加载的Web框架（MVC）起到了关键性的作用。
在这一阶段往往会将系统分为不同的层级，每个层级有对应的职责，UI层负责和用户进行交互、业务逻辑层负责具体的业务功能、数据库层负责和上层进行数据交换和存储。 
在这一阶段我们最常使用到的开发框架就是Spring（业务逻辑层管理POJO）+Struts（web层前置服务控制）+Hibernate（数据库层持久化）。
服务化架构
伴随着企业服务量的不断提升，MVC框架的部署导致系统的负重越来越多，无法满足并发的要求，系统间数据、报文的传输会出现频繁的丢失。这时候我们需要考虑服务化的架构（SOA）。
SOA Service Oriented Architecture 面向服务的架构（SOA）是一个组件模型.
SOA表示面向服务的架构。将应用根据不同的职责划分成不同的模块（类似于企业划分不同的事业部），不同的模块使用特定的调用协议（RPC）和接口进行交互。
这样使整个系统切分成很多单个组件服务来完成请求，当流量过大时通过水平扩展相应的组件来支撑，所有的组件通过交互来满足整体的业务需求。
SOA服务化的优点是，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。
服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
服务化架构是一套松耦合的架构，服务的拆分原则是服务内部高内聚，服务之间低耦合。 
在这个阶段可以使用WebService或者dubbo来服务治理。
微服务架构
微服务架构算是SOA架构的一种拓展，主要关注的是服务个体的独立性、拆分粒度更小。相对于SOA架构来说，微服务拥有以下优势：
微服务强调更深层次的组件化和服务化，每个微服务都可以拥有独立的运行空间，确保每一个服务组件可以作为单独的产品进行发布。
微服务抛弃了传统SOA笨重的企业服务总线，对外发布强调使用HTTP REST API的接口发布形式。
微服务的切分粒度大。
了解了架构的发展过程，我们来认识一下Spring Cloud。
Spring Cloud来源于Spring，利用Spring Boot进行快捷开发。由于目前Spring Cloud社区的维护和支持的人员数量众多，相信Spring Cloud会有很好的发展。而且Spring Cloud基本上都是使用了现有的开源框架进行的集成，学习的难度和部署的门槛就比较低，对于中小型企业来说，更易于使用和落地。
Spring Cloud主要解决了什么问题？
1、对于企业级的SOA框架来说，服务与服务间的解耦是一项巨大的难题，随着功能服务的不断增加，多服务间的相互调用频繁，调用过程就像一个杂乱无章的毛线球，很容易导致牵一发而动全身的情况，经常会由于在服务更新的过程中，没有合理通信，导致数据的丢失。
这时候就应该进行服务治理，将服务之间的直接依赖转化为服务对服务中心的依赖。Spring Cloud 核心组件Eureka就是解决这类问题。
Eureka
Eureka是Netflix开源的一款提供服务注册和发现的产品，它提供了完整的Service Registry和Service Discovery实现。也是Spring Cloud体系中最重要最核心的组件之一。
用大白话讲，Eureka就是一个服务中心，将所有的可以提供的服务都注册到它这里来管理，其它各调用者需要的时候去注册中心获取，然后再进行调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移等。如下图： 
当然服务中心这么重要的组件一但挂掉将会影响全部服务，因此需要搭建Eureka集群来保持高可用性，生产中建议最少两台。
随着系统的流量不断增加，需要根据情况来扩展某个服务，Eureka内部已经提供均衡负载的功能，只需要增加相应的服务端实例既可。
那么在系统的运行期间某个实例挂了怎么办?Eureka内容有一个心跳检测机制，如果某个实例在规定的时间内没有进行通讯则会自动被剔除掉，避免了某个实例挂掉而影响服务。
因此使用了Eureka就自动具有了注册中心、负载均衡、故障转移的功能。
Hystrix ==>解决服务雪崩效应
在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。
服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。
如下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。 
在这种情况下就需要整个服务机构具有故障隔离的功能，避免某一个服务挂掉影响全局。在Spring Cloud 中Hystrix组件就扮演这个角色。
Hystrix会在某个服务连续调用N次不响应的情况下，立即通知调用端调用失败，避免调用端持续等待而影响了整体服务。Hystrix间隔时间会再次检查此服务，如果服务恢复将继续提供服务。
Hystrix Dashboard和Turbine
当熔断发生的时候需要迅速的响应来解决问题，避免故障进一步扩散，那么对熔断的监控就变得非常重要。
熔断的监控现在有两款工具：Hystrix-dashboard和Turbine
Hystrix-dashboard是一款针对Hystrix进行实时监控的工具，通过Hystrix Dashboard我们可以直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据。
但是只使用Hystrix Dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够。
我们需要一个工具能让我们汇总系统内多个服务的数据并显示到Hystrix Dashboard上, 这个工具就是Turbine。
监控的效果图如下： 
想了解具体都监控了哪些指标，以及如何监控可以参考这篇文章：熔断监控Hystrix Dashboard和Turbine
配置中心
随着微服务不断的增多，每个微服务都有自己对应的配置文件。在研发过程中有测试环境、UAT环境(User Acceptance Test用户体验环境)、生产环境，因此每个微服务又对应至少三个不同环境的配置文件。
这么多的配置文件，如果需要修改某个公共服务的配置信息，如：缓存、数据库等，难免会产生混乱，这个时候就需要引入Spring Cloud另外一个组件：Spring Cloud Config。
Spring Cloud Config
Spring Cloud Config是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，Server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client通过接口获取数据、并依据此数据初始化自己的应用。
其实就是Server端将所有的配置文件服务化，需要配置文件的服务实例去Config Server获取对应的数据。将所有的配置文件统一整理，避免了配置文件碎片化。
如果服务运行期间改变配置文件，服务是不会得到最新的配置信息，需要解决这个问题就需要引入Refresh。它可以在服务的运行期间重新加载配置文件。
当所有的配置文件都存储在配置中心的时候，配置中心就成为了一个非常重要的组件。
如果配置中心出现问题将会导致灾难性的后果，因此在生产中建议对配置中心做集群，来支持配置中心高可用性。
Spring Cloud Bus
上面的 Refresh 方案虽然可以解决单个微服务运行期间重载配置信息的问题，但是在真正的实践生产中，可能会有 N 多的服务需要更新配置。
如果每次依靠手动 Refresh 将是一个巨大的工作量，这时候 Spring Cloud 提出了另外一个解决方案：Spring Cloud Bus。
Spring Cloud Bus 通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化(例如配置变化)或者其它的消息指令中。
Spring Cloud Bus 的一个核心思想是通过分布式的启动器对 Spring Boot 应用进行扩展，也可以用来建立一个或多个应用之间的通信频道。目前唯一实现的方式是用 AMQP 消息代理作为通道。
Spring Cloud Bus 是轻量级的通讯组件，也可以用在其它类似的场景中。有了 Spring Cloud Bus 之后，当我们改变配置文件提交到版本库中时，会自动的触发对应实例的Refresh，具体的工作流程如下： 
服务网关
在微服务架构模式下，后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。
因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway作为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。
Spring Cloud体系中支持API Gateway落地的技术就是Zuul。
Spring Cloud Zuul路由是微服务架构中不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。
Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。
它的具体作用就是服务转发，接收并转发所有内外部的客户端调用。
使用Zuul可以作为资源的统一访问入口，同时也可以在网关做一些权限校验等类似的功能。
链路跟踪
随着服务的越来越多，对调用链的分析会越来越复杂，如服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等，对这些信息进行监控就成为一个问题。
在实际的使用中我们需要监控服务和服务之间通讯的各项指标，这些数据将是我们改进系统架构的主要依据。
因此分布式的链路跟踪就变的非常重要，Spring Cloud 也给出了具体的解决方案：Spring Cloud Sleuth 和 Zipkin。
Spring Cloud Sleuth为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。
Zipkin是Twitter的一个开源项目，允许开发者收集 Twitter 各个服务上的监控数据，并提供查询接口。
总结
我们从整体上来看一下Spring Cloud各个组件如何来配套使用：
通过这张图，我们来了解一下各组件配置使用运行流程：
-
1、请求统一通过API网关（Zuul）来访问内部服务.
-
2、网关接收到请求后，从注册中心（Eureka）获取可用服务
-
3、由Ribbon进行均衡负载后，分发到后端具体实例
-
4、微服务之间通过Feign进行通信处理业务
-
5、Hystrix负责处理服务超时熔断
-
6、Turbine监控服务间的调用和熔断相关指标
pring Cloud各个组件相互配合，合作支持了一套完整的微服务架构。
其中Eureka负责服务的注册与发现，很好将各服务连接起来
Hystrix 负责监控服务之间的调用情况，连续多次失败进行熔断保护。
Hystrix dashboard,Turbine 负责监控 Hystrix的熔断情况，并给予图形化的展示
Spring Cloud Config 提供了统一的配置中心服务
当配置文件发生变化的时候，Spring Cloud Bus 负责通知各服务去获取最新的配置信息
所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关的作用
最后我们使用Sleuth+Zipkin将所有的请求数据记录下来，方便我们进行后续分析
Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。
这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。
微服务架构是一种趋势，Spring Cloud提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。
本人着重介绍Spring Cloud 的功能，总结就是五个大的功能，不过我感觉直接看结论，印象不深，不如本文写得好，来龙去脉都说的很清楚
这是总结：SpringCloud分布式开发五大神兽