软件是有生命的，你做出来的架构决定了这个软件它这一生是坎坷还是幸福。 本文不是讲解如何使用Spring Cloud的教程，而是探讨Spring Cloud是什么，以及它诞生的背景和意义。 转载自简书作者 原文链接：： https://www.jianshu.com/p/3899d7f47303 一、背景 2008年以后，国内互联网行业飞速发展，我们对软件系统的需求已经不再是过去”能用就行”这种很low的档次了，像 抢红包、双十一这样的活动 不断逼迫我们去突破软件系统的性能上限，传统的IT企业”能用就行”的开发思想已经不能满足互联网 高并发、大流量的性能要求 。系统架构 走向分布式 已经是服务器开发领域解决该问题唯一的出路，然而分布式系统由于天生的复杂度，并不像开发单体应用一样把框架一堆就能搞定，因此各大互联网公司都在投入技术力量研发自己的基础设施。这里面比较有名的如 阿里的开源项目dubbo, Netflix开发的一系列服务框架 。在这种“百花齐放”、重复造轮子的状况下，必然要出现一种统一的标准来简化分布式系统的开发， Spring Cloud 应运而生。 二、Spring Cloud是什么 Spring Cloud是一系列框架的有序集合。它利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如 服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控 等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。 Spring Cloud正是对Netflix的多个开源组件进一步的封装而成，同时又实现了和云端平台，和Spring Boot开发框架很好的集成。 Spring Cloud是一个相对比较新的微服务框架， 2016年才推出1.0的release版本 . 虽然Spring Cloud时间最短, 但是相比Dubbo等RPC框架, Spring Cloud提供的全套的分布式系统解决方案 。 Spring Cloud 为开发者提供了在分布式系统（ 配置管理，服务发现，熔断，路由，微代理，控制总线，一次性token，全居琐，leader选举，分布式session，集群状态 ）中快速构建的工具，使用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 Boot化”的封装和抽象，也是数量最多的项目；第二类是开发了一部分分布式系统的基础设施的实现，如 Spring Cloud Stream扮演的就是kafka, ActiveMQ这样的角色 。对于我们想快速实践微服务的开发者来说，第一类子项目就已经足够使用，如： Spring Cloud Netflix ，是对Netflix开发的一套分布式服务框架的封装，包括服务的发现和注册，负载均衡、断路器、REST客户端、请求路由等。该项目是Spring Cloud的子项目之一，主要内容是对Netflix公司一系列开源产品的包装，它为Spring Boot应用提供了自配置的Netflix OSS整合。 通过一些简单的注解，开发者就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统。它主要提供的模块包括：服务发现（Eureka），断路器（Hystrix），智能路由（Zuul），客户端负载均衡（Ribbon）等。 Spring Cloud Netflix 这可是个大boss，地位仅次于老大，老大各项服务依赖与它，与各种Netflix OSS组件集成，组成微服务的核心，它的小弟主要有Eureka, Hystrix, Zuul, Archaius… 太多了 3.1、Spring Cloud Eureka 服务发现
服务中心，云端服务发现， 一个基于 REST 的服务，用于定位服务 ，以实现云端中间层服务发现和故障转移。 这个可是SpringCloud最牛鼻的小弟，服务中心 ，任何小弟需要其它小弟支持什么都需要从这里来拿，同样的你有什么独门武功的都赶紧过报道，方便以后其它小弟来调用；它的好处是你不需要直接找各种什么小弟支持，只需要到服务中心来领取，也不需要知道提供支持的其它小弟在哪里，还是几个小弟来支持的，反正拿来用就行，服务中心来保证稳定性和质量。 Spring Cloud Eureka 提供在分布式环境下的服务发现，服务注册的功能。 一个RESTful服务，用来定位运行在AWS地区（Region）中的中间层服务。由两个组件组成： Eureka服务器和Eureka客户端 。Eureka服务器用作服务注册服务器。Eureka客户端是一个java客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。Netflix在其生产环境中使用的是另外的客户端，它提供基于流量、资源利用率以及出错状态的加权负载均衡。 3.2、Spring Cloud Ribbon 客户端负载均衡
Ribbon，主要提供客户侧的软件负载均衡算法。 Ribbon客户端组件提供一系列完善的配置选项，比如连接超时、重试、重试算法等。Ribbon内置可插拔、可定制的负载均衡组件。下面是用到的一些 负载均衡策略 ：
简单轮询负载均衡
加权响应时间负载均衡
区域感知轮询负载均衡
随机负载均衡
Ribbon中还包括以下功能：
易于与服务发现组件（比如Netflix的Eureka）集成
使用Archaius完成运行时配置
使用JMX暴露运维指标，使用Servo发布
多种可插拔的序列化选择
异步和批处理操作（即将推出）
自动SLA框架（即将推出）
系统管理/指标控制台（即将推出）
ribbon架构示例
一个服务注册中心，eureka server,端口为8761
service-hi工程跑了两个实例，端口分别为8762,8763，分别向服务注册中心注册
sercvice-ribbon端口为8764,向服务注册中心注册
当sercvice-ribbon通过restTemplate调用service-hi的hi接口时，因为用ribbon进行了负载均衡，会轮流的调用service-hi：8762和8763 两个端口的hi接口；
3.3、Spring Cloud Config
俗称的配置中心，配置管理工具包，让你可以把配置放到远程服务器，集中化管理集群配置， 目前支持本地存储、Git以及Subversion 。就是以后大家武器、枪火什么的东西都集中放到一起，别随便自己带，方便以后统一管理、升级装备。
将配置信息中央化保存, 配置Spring Cloud Bus可以实现动态修改配置文件。这个还是静态的，得配合Spring Cloud Bus实现动态的配置更新。
Spring Cloud Config就是我们通常意义上的配置中心。Spring Cloud Config-把应用原本放在本地文件的配置抽取出来放在 中心服务器 ，本质是配置信息从本地迁移到云端。从而能够提供更好的管理、发布能力。 Spring Cloud Config分服务端和客户端，服务端负责将git（svn）中存储的配置文件发布成REST接口，客户端可以从服务端REST接口获取配置。但客户端并不能主动感知到配置的变化，从而主动去获取新的配置，这需要每个客户端通过POST方法触发各自的/refresh。 3.4、Spring cloud Hystrix 熔断器
熔断器，容错管理工具，旨在通过熔断机制控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。比如突然某个小弟生病了，但是你还需要它的支持，然后调用之后它半天没有响应，你却不知道，一直在等等这个响应；有可能别的小弟也正在调用你的武功绝技，那么当请求多之后，就会发生严重的阻塞影响老大的整体计划。这个时候Hystrix就派上用场了， 当Hystrix发现某个小弟不在状态不稳定立马马上让它下线，让其它小弟来顶上来 ，或者给你说不用等了这个小弟今天肯定不行，该干嘛赶紧干嘛去别在这排队了。
断路器(Cricuit Breaker)是一种能够在远程服务不可用时自动熔断(打开开关)，并在远程服务恢复时自动恢复(闭合开关)的设施，Spring Cloud通过Netflix的 Hystrix组件 提供断路器、资源隔离与自我修复功能。 断路器可以防止一个应用程序多次试图执行一个操作，即很可能失败，允许它继续而不等待故障恢复或者浪费 CPU 周期，而它确定该故障是持久的。断路器模式也使应用程序能够检测故障是否已经解决。如果问题似乎已经得到纠正，应用程序可以尝试调用操作。
断路器增加了稳定性和灵活性，以一个系统，提供稳定性，而系统从故障中恢复，并尽量减少此故障的对性能的影响。它可以帮助快速地拒绝对一个操作，即很可能失败，而不是等待操作超时（或者不返回）的请求，以保持系统的响应时间。如果断路器提高每次改变状态的时间的事件，该信息可以被用来监测由断路器保护系统的部件的健康状况，或以提醒管理员当断路器跳闸，以在打开状态。
Netflix开源了Hystrix组件，实现了断路器模式，SpringCloud对这一组件进行了整合。 在微服务架构中，一个请求需要调用多个服务是非常常见的，如下图：
编辑
添加图片注释，不超过 140 字（可选）
较底层的服务如果出现故障，会导致连锁故障。当对特定的服务的调用的不可用达到一个阀值（Hystric 是5秒20次） 断路器将会被打开。
x断路打开后，可用避免连锁故障，fallback方法可以直接返回一个固定值。 在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。 如下图所示：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 . 监控的效果图如下：
3.5、Spring Cloud Zuul 服务网关，智能路由
在微服务架构模式下，后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway作为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。
Spring Cloud体系中支持API Gateway落地的技术就是 Zuul 。Spring Cloud Zuul路由是微服务架构中不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。 它的具体作用 就是服务转发，接收并转发所有内外部的客户端调用。使用Zuul可以作为资源的统一访问入口，同时也可以在网关做一些权限校验等类似的功能 。 Zuul 是在云平台上提供动态路由,监控,弹性,安全等边缘服务的框架。Zuul 相当于是设备和 Netflix 流应用的 Web 网站后端所有请求的前门。当其它门派来找大哥办事的时候一定要先经过zuul,看下有没有带刀子什么的给拦截回去，或者是需要找那个小弟的直接给带过去。
类似Nginx，反向代理的功能，不过netflix自己增加了一些配合其他组件的特性。 3.6、Spring Netflix Archaius
配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。可以实现动态获取配置， 原理是 每隔60s（默认，可配置）从配置源读取一次内容 ，这样修改了配置文件后不需要重启服务就可以使修改后的内容生效，前提使用archaius的API来读取。 3.7、Spring Cloud Bus
事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化， 可与Spring Cloud Config联合实现热部署 。相当于水浒传中日行八百里的神行太保戴宗，确保各个小弟之间消息保持畅通。 分布式消息队列，是对Kafka, MQ的封装；事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现 热部署 。 Spring cloud bus通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其他的消息指令。 Spring bus的一个核心思想是通过分布式的启动器对spring boot应用进行扩展，也可以用来建立一个多个应用之间的通信频道。 目前唯一实现的方式是用AMQP消息代理作为通道，同样特性的设置（有些取决于通道的设置）在更多通道的文档中。 Spring cloud bus被国内很多都翻译为消息总线，也挺形象的。大家可以将它理解为管理和传播所有分布式项目中的消息既可，其实本质是利用了MQ的广播机制在分布式的系统中传播消息，目前常用的有Kafka和RabbitMQ。利用bus的机制可以做很多的事情，其中配置中心客户端刷新就是典型的应用场景之一，我们用一张图来描述bus在配置中心使用的机制。
根据此图我们可以看出利用Spring Cloud Bus做配置更新的步骤:
提交代码触发post给客户端A发送bus/refresh
客户端A接收到请求从Server端更新配置并且发送给Spring Cloud Bus
Spring Cloud bus接到消息并通知给其它客户端
其它客户端接收到通知，请求Server端获取最新配置
全部客户端均获取到最新的配置
3.8 Spring Cloud Security
对Spring Security的封装，并能配合Netflix使用，安全工具包，为你的应用程序添加安全控制， 主要是指OAuth2 。 基于spring security的安全工具包，为你的应用程序添加安全控制。这个小弟很牛鼻专门负责整个帮派的 安全问题 ，设置不同的门派访问特定的资源，不能把秘籍葵花宝典泄漏了。 3.9、Spring Cloud Zookeeper
对Zookeeper的封装，使之能配置其它Spring Cloud的子项目使用；操作Zookeeper的工具包， 用于使用zookeeper方式的服务注册和发现 。 ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。ZooKeeper的目标就是封装好复杂易出错的关键服务，将简单易用的接口和性能高效、功能稳定的系统提供给用户。 操作Zookeeper的工具包，用于使用zookeeper方式的服务发现和配置管理，抱了Zookeeper的大腿。 3.10、Spring Cloud Stream
数据流；数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。 Spring Cloud Stream是创建消息驱动微服务应用的框架。Spring Cloud Stream是基于spring boot创建，用来建立单独的／工业级spring应用，使用spring integration提供与消息代理之间的连接。数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。 一个业务会牵扯到多个任务，任务之间是通过事件触发的，这就是Spring Cloud stream要干的事了。 3.11、Spring Cloud Sleuth
随着服务的越来越多，对调用链的分析会越来越复杂，如服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等，对这些信息进行监控就成为一个问题。在实际的使用中我们需要监控服务和服务之间通讯的各项指标，这些数据将是我们改进系统架构的主要依据。因此分布式的链路跟踪就变的非常重要， Spring Cloud也给出了具体的解决方案：Spring Cloud Sleuth和Zipkin 。 服务跟踪；日志收集工具包，封装了Dapper,Zipkin和HTrace操作。 日志收集工具包，封装了Dapper和log-based追踪以及Zipkin和HTrace操作，为SpringCloud应用实现了一种分布式追踪解决方案。 简介 Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案，并且兼容支持了 zipkin，你只需要在pom文件中引入相应的依赖即可。 服务追踪分析 微服务架构上通过业务来划分服务的，通过 REST调用 ，对外暴露的一个接口， 可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败 。随着业务的不断扩张，服务之间互相调用会越来越复杂。
随着服务的越来越多，对调用链的分析会越来越复杂。它们之间的调用关系也许如下：
术语
Span：基本工作单元，例如，在一个新建的span中发送一个RPC等同于发送一个回应请求给RPC，span通过一个64位ID唯一标识，trace以另一个64位ID表示，span还有其他数据信息，比如摘要、时间戳事件、关键值注释(tags)、span的ID、以及进度ID(通常是IP地址) span在不断的启动和停止，同时记录了时间信息，当你创建了一个span，你必须在未来的某个时刻停止它。
Trace：一系列spans组成的一个树状结构，例如，如果你正在跑一个分布式大数据工程，你可能需要创建一个trace。
Annotation：用来及时记录一个事件的存在，一些核心annotations用来定义一个请求的开始和结束 cs – Client Sent -客户端发起一个请求，这个annotion描述了这个span的开始sr – Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络延迟ss – Server Sent -注解表明请求处理的完成(当请求返回客户端)，如果ss减去sr时间戳便可得到服务端需要的处理请求时间cr – Client Received -表明span的结束，客户端成功接收到服务端的回复，如果cr减去cs时间戳便可得到客户端从服务端获取回复的所有所需时间将Span和Trace在一个系统中使用Zipkin注解的过程图形化：
3.12、Spring Cloud Feign 使用HTTP请求远程服务
在Spring Cloud Netflix栈中，各个微服务都是以HTTP接口的形式暴露自身服务的，因此在调用远程服务时就必须使用HTTP客户端。我们可以使用JDK原生的URLConnection、Apache的Http Client、Netty的异步HTTP Client, Spring的RestTemplate。但是，用起来最方便、最优雅的还是要属Feign了。 Feign是一种声明式、模板化的HTTP客户端。在Spring Cloud中使用Feign, 我们可以做到使用HTTP请求远程服务时能与调用本地方法一样的编码体验，开发者完全感知不到这是远程方法，更感知不到这是个HTTP请求。 通过Feign， 我们能把HTTP远程调用对开发者完全透明，得到与调用本地方法一致的编码体验。这一点与阿里Dubbo中暴露远程服务的方式类似， 区别在于Dubbo是基于私有二进制协议，而Feign本质上还是个HTTP客户端 。如果是在用Spring Cloud Netflix搭建微服务，那么Feign无疑是最佳选择。 Feign是一个声明式的伪Http客户端，它使得写Http客户端变得更简单。使用Feign，只需要创建一个接口并注解。它具有可插拔的注解特性，可使用Feign 注解和JAX-RS注解。Feign支持可插拔的编码器和解码器。Feign默认集成了Ribbon，并和Eureka结合，默认实现了负载均衡的效果。 简而言之：
Feign 采用的是基于接口的注解
Feign 整合了ribbon
3.13、Spring Cloud for Cloud Foundry
Cloud Foundry是VMware推出的业界第一个开源PaaS云平台，它支持多种框架、语言、运行时环境、云平台及应用服务，使开发人员能够在几秒钟内进行应用程序的部署和扩展，无需担心任何基础架构的问题 其实就是与CloudFoundry进行集成的一套解决方案，抱了 Cloud Foundry 的大腿。 3.14、Spring Cloud Cluster
Spring Cloud Cluster将取代Spring Integration。提供在分布式系统中的集群所需要的基础功能支持，如： 选举、集群的状态一致性、全局锁、tokens等 常见状态模式的抽象和实现。 如果把不同的帮派组织成统一的整体，Spring Cloud Cluster已经帮你提供了很多方便组织成统一的工具。 3.15、Spring Cloud Consul
Consul 是一个支持多数据中心分布式高可用的服务发现和配置共享的服务软件, 由 HashiCorp 公司用 Go 语言开发 , 基于 Mozilla Public License 2.0 的协议进行开源. Consul 支持健康检查,并允许 HTTP 和 DNS 协议调用 API 存储键值对. Spring Cloud Consul 封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。 3.16、Spring Cloud Data Flow
Data flow 是一个用于开发和执行大范围数据处理其模式包括ETL，批量运算和持续运算的统一编程模型和托管服务。 对于在现代运行环境中可组合的微服务程序来说，Spring Cloud data flow是一个原生云可编配的服务。使用Spring Cloud data flow，开发者可以为像数据抽取，实时分析，和数据导入/导出这种常见用例创建和编配数据通道 （data pipelines）。 Spring Cloud data flow 是基于原生云对 spring XD的重新设计，该项目目标是简化大数据应用的开发。Spring XD 的流处理和批处理模块的重构分别是基于 spring boot的stream 和 task/batch 的微服务程序。这些程序现在都是自动部署单元而且他们原生的支持像 Cloud Foundry、Apache YARN、Apache Mesos和Kubernetes 等现代运行环境。 Spring Cloud data flow 为基于微服务的分布式流处理和批处理数据通道提供了一系列模型和最佳实践。 3.17、Spring Cloud Task
Spring Cloud Task 主要解决短命微服务的任务管理，任务调度的工作，比如说某些定时任务晚上就跑一次，或者某项数据分析临时就跑几次。 3.18、Spring Cloud Connectors
Spring Cloud Connectors 简化了连接到服务的过程和从云平台获取操作的过程，有很强的扩展性，可以利用Spring Cloud Connectors来构建你自己的云平台。 便于云端应用程序在各种PaaS平台连接到后端，如：数据库和消息代理服务。 3.19、Spring Cloud Starters
Spring Boot式的启动项目，为Spring Cloud提供开箱即用的依赖管理。 3.20、Spring Cloud CLI
基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。 3.21、Netflix Turbine
Turbine是聚合服务器发送事件流数据的一个工具，用来监控集群下hystrix的metrics情况。 四、和Spring Boot 是什么关系 Spring boot 是 Spring 的一套 快速配置脚手架 ，可以基于spring boot 快速开发单个微服务，Spring Cloud是一个基于Spring Boot实现的云应用开发工具；Spring boot专注于快速、方便集成的单个个体，Spring Cloud是关注全局的服务治理框架；spring boot使用了默认大于配置的理念，很多集成方案已经帮你选择好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring boot来实现,可以不基于Spring boot吗？不可以。 Spring boot可以离开Spring Cloud独立使用开发项目， 但是Spring Cloud离不开Spring boot，属于依赖的关系 。 Spring -> Spring Boot > Spring Cloud 这样的关系。 五、Spring Cloud的优势 微服务的框架那么多比如：dubbo、Kubernetes，为什么就要使用Spring Cloud的呢？
产出于Spring大家族，Spring在企业级开发框架中无人能敌，来头很大，可以保证后续的更新、完善。比如dubbo现在就差不多死了
有Spring Boot 这个独立干将可以省很多事，大大小小的活spring boot都搞的挺不错。 作为一个微服务治理的大家伙，考虑的很全面，几乎服务治理的方方面面都考虑到了，方便开发开箱即用。
Spring Cloud 活跃度很高，教程很丰富，遇到问题很容易找到解决方案
轻轻松松几行代码就完成了熔断、均衡负责、服务中心的各种平台功能
Spring Cloud 也有一个缺点， 只能使用Java开发 ,不适合小型独立的项目。
六、Spring Cloud前景 Spring Cloud对于中小型互联网公司来说是一种福音，因为这类公司往往没有实力或者没有足够的资金投入去开发自己的分布式系统基础设施，使用Spring Cloud一站式解决方案能在从容应对业务发展的同时大大减少开发成本。同时，随着近几年 微服务架构和docker容器 概念的火爆，也会让Spring Cloud在未来越来越“云”化的软件开发风格中立有一席之地，尤其是在目前五花八门的分布式解决方案中提供了标准化的、全站式的技术方案， 意义可能会堪比当前Servlet规范的诞生 ，有效推进服务端软件系统技术水平的进步。觉得写的还不错的就点个赞，加个关注呗！点关注，不迷路，持续更新！！！
