spring cloud官网
Spring Cloud 2021.0.0 概述(取自官网)Spring Cloud 为开发者提供了快速构建分布式系统中一些常见模式的工具（例如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态）。分布式系统的协调导致了样板模式，使用 Spring Cloud 开发人员可以快速建立实现这些模式的服务和应用程序。它们将适用于任何分布式环境，包括开发人员自己的笔记本电脑、裸机数据中心和托管平台（如 Cloud Foundry）。
Spring Cloud简介Spring Cloud是Spring提供的微服务框架。它利用Spring Boot的开发特性简化了微服务开发的复杂性，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，这些工作都可以借助Spring Boot的开发风格做到一键启动和部署。
Spring Cloud的目标是通过一系列组件，帮助开发者迅速构件一个分布式系统，Spring Cloud 是通过包装其它公司产品来实现的，比如Spring Cloud整合了开源的Netflix很多产品。Spring Cloud提供了微服务治理的诸多组件，例如服务注册和发现、配置中心、熔断器、智能路由、微代理、控制总线、全局锁、分布式会话等。
Spring Cloud组件非常多，涉及微服务开发的诸多场景,Spring Cloud的架构图如图所示。
Spring Cloud实现微服务的治理功能产品很多，下面简单介绍下Spring Cloud各个产品的作用，以及采用的原则，如图所示
Spring Cloud NetflixSpring Cloud Netflix 通过自动配置和绑定到 Spring Environment 和其他 Spring 编程模型习语，为 Spring Boot 应用程序提供 Netflix OSS 集成。通过一些简单的注释，您可以快速启用和配置应用程序中的通用模式，并使用久经考验的 Netflix 组件构建大型分布式系统。提供的模式包括服务发现（Eureka）、断路器（Hystrix）、智能路由（Zuul）和客户端负载平衡（Ribbon）。
Spring Cloud Netflix 功能：
- 服务发现：可以注册 Eureka 实例，客户端可以使用 Spring 管理的 bean 发现实例
- 服务发现：可以使用声明性 Java 配置创建嵌入式 Eureka 服务器
- 断路器：Hystrix 客户端可以使用简单的注解驱动方法装饰器构建
- 断路器：具有声明性 Java 配置的嵌入式 Hystrix 仪表板
- 声明式 REST 客户端：Feign 创建了用 JAX-RS 或 Spring MVC 注释修饰的接口的动态实现
- 客户端负载均衡器：功能区
- 外部配置：从 Spring Environment 到 Archaius 的桥梁（使用 Spring Boot 约定启用 Netflix 组件的本机配置）
- 路由器和过滤器：自动注册 Zuul 过滤器，以及一个简单的配置方法来创建反向代理
就是一个中介,服务提供者在eureka中注册服务,服务消费者调用eureka中的服务,比如,你想出租二手房,你把这个消息登记到出租网站上,小明要租房子,你们一拍即合,这个出租网站也可以出租其他东西,你也可以租用别人出租的东西,所以任一服务既可以是提供者也可是消费者
"Eureka"来源于古希腊词汇，意为“发现了”。在软件领域，Eureka是Netflix在线影片公司开源的一个服务注册和发现组件，和其他的Netflix公司的服务组件（例如负载均衡，熔断器，网关等）一起，被Spring Cloud社区整合为Spring Cloud Netflix模块。
和Zookeeper类似，Eureka是一个用于服务注册和发现的组件，最开始主要应用与亚马逊公司的云计算服务平台AWS，Eureka分为Eureka Server和Eureka Client，Eureka Server为Eureka服务注册中心，Eureka Client为Eureka客户端。
就比如一个人搬一车砖太累,万一这个人累死就车砖就搬不完了,所以就多叫几个人一起搬,才能多快好省,保证系统的稳定性
负载均衡是指将负载分摊到多个执行单元上，常见的负载均衡有两种方式。一种独立进程单元，通过负载均衡策略，将请求转发到不同的执行单元上，例如Nginx。另一种是将负载均衡逻辑以代码的形式封装到服务消费者的客户端上，服务消费者客户端维护了一份服务提供者的信息列表，有了信息表，通过负载均衡策略将请求分摊给多个服务提供者，从而达到负载均衡的目的。
SpringCloud原有的客户端负载均衡方案Ribbon已经被废弃，取而代之的是SpringCloud LoadBalancer，LoadBalancer是Spring Cloud Commons的一个子项目，他属于上述的第二种方式，是将负载均衡逻辑封装到客户端中，并且运行在客户端的进程里。
在Spring Cloud构件微服务系统中，LoadBalancer作为服务消费者的负载均衡器，有两种使用方式，一种是和RestTemplate相结合，另一种是和Feign相结合，Feign已经默认集成了LoadBalancer。
容错,就是当系统出问题时的应对措施,防止系统崩溃
在高并发访问下，比如天猫双11，流量持续不断的涌入，服务之间的相互调用频率突然增加，引发系统负载过高，这时系统所依赖的服务的稳定性对系统的影响非常大，而且还有很多不确定因素引起雪崩，如网络连接中断，服务宕机等。一般微服务容错组件提供了限流、隔离、降级、熔断等手段，可以有效保护我们的微服务系统。
隔离当下游某个服务不可用时,一直调用其会导致系统崩溃,所以要停止调用此服务
微服务系统A调用B，而B调用C，这时如果C出现故障，则此时调用B的大量线程资源阻塞，慢慢的B的线程数量持续增加直到CPU耗尽到100%，整体微服务不可用，这时就需要对不可用的服务进行隔离。
熔断当下游的某个服务出问题时,直接返回此路不通,禁止通行,这样能更快速释放资源
当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
熔断器模型的状态机有3个状态。
- Closed：关闭状态（断路器关闭），所有请求都正常访问。
- Open：打开状态（断路器打开），所有请求都会被降级。熔断器会对请求情况计数，当一定时间内失败请求百分比达到阈值，则触发熔断，断路器会完全打开。
- Half Open：半开状态，不是永久的，断路器打开后会进入休眠时间。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进行休眠计时。
把次要服务降级,全力维护主要业务
降级是指当自身服务压力增大时，系统将某些不重要的业务或接口的功能降低，可以只提供部分功能，也可以完全停止所有不重要的功能。比如，下线非核心服务以保证核心服务的稳定、降低实时性、降低数据一致性，降级的思想是丢车保帅。
举个例子，比如，目前很多人想要下订单，但是我的服务器除了处理下订单业务之外，还有一些其他的服务在运行，比如，搜索、定时任务、支付、商品详情、日志等等服务。然而这些不重要的服务占用了JVM的不少内存和CPU资源，为了应对很多人要下订单的需求，设计了一个动态开关，把这些不重要的服务直接在最外层拒绝掉。这样就有更多的资源来处理下订单服务（下订单速度更快了）
就类似运营商限制你的流量速度
限流，就是限制最大流量。系统能提供的最大并发有限，同时来的请求又太多，就需要限流，比如商城秒杀业务，瞬时大量请求涌入，服务器服务不过来，就只好排队限流了，就跟去景点排队买票和去银行办理业务排队等号道理相同。下面介绍下四种常见的限流算法。
Spring Cloud Gateway 特征Spring Cloud Gateway 特性：
- 基于 Spring framework 5、Project Reactor 和 Spring Boot 2.0
- 能够匹配任何请求属性的路由。
- 谓词和过滤器特定于路由。
- 断路器集成。
- Spring Cloud DiscoveryClient 集成
- 易于编写谓词和过滤器
- 请求速率限制
- 路径重写
给外部提供一个统一的外部接口,外部只需要和网关打交道,并由网关调用内部服务,对内部服务进行更好的保护
网关有很多重要的意义，具体体现在下面几个方面。
- 网关可以做一些身份认证、权限管理、防止非法请求操作服务等，对服务起一定保护作用。
- 网关将所有微服务统一管理，对外统一暴露，外界系统不需要知道微服务架构个服务相互调用的复杂性，同时也避免了内部服务一些敏感信息泄露问题。
- 易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析。
- 客户端只跟服务网关打交道，减少了客户端与各个微服务之间的交互次数。
- 多渠道支持，可以根据不同客户端（WEB端、移动端、桌面端…）提供不同的API服务网关。
- 网关可以用来做流量监控。在高并发下，对服务限流、降级。
- 网关把服务从内部分离出来，方便测试。
微服务网关能够实现，路由、负载均衡等多种功能。类似Nginx，反向代理的功能。在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的URL，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，在API网关中进行权限控制，同时API网关将请求以负载均衡的方式发送给后端服务。微服务网关架构，如下图所示。
主要就是配置太多不好管理,特别是集群时,要更改某些配置,所有服务器的配置都会更改,当场人去世,成本太高,当使用Config组件时,所有服务器都使用同一份配置,只需更改一处,降低运营成本
Spring Cloud Config 为分布式系统中的外部化配置提供服务器端和客户端支持。使用 Config Server，您可以集中管理所有环境中应用程序的外部属性。客户端和服务器上的概念与 SpringEnvironment和PropertySource抽象，因此它们非常适合Spring 应用程序，但可以用于以任何语言运行的任何应用程序。当应用程序通过部署管道从开发到测试再进入生产时，您可以管理这些环境之间的配置，并确保应用程序在迁移时拥有运行所需的一切。服务器存储后端的默认实现使用 git，因此它可以轻松支持配置环境的标记版本，并且可以访问用于管理内容的各种工具。添加替代实现并使用 Spring 配置将它们插入很容易。
配置文件想必大家都不陌生。在Spring Boot项目中，默认会提供一个application.properties或者application.yml文件，我们可以把一些全局性的配置或者需要动态维护的配置写入改文件，不如数据库连接，功能开关，限流阈值，服务地址等。为了解决不同环境下服务连接配置等信息的差异，Spring Boot还提供了基于spring.profiles.active={profile}的机制来实现不同的环境的切换。
随着单体架构向微服务架构的演进，各个应用自己独立维护本地配置文件的方式开始显露出它的不足之处。主要有下面几点。
● 配置的动态更新：在实际应用会有动态更新位置的需求，比如修改服务连接地址、限流配置等。在传统模式下，需要手动修改配置文件并且重启应用才能生效，这种方式效率太低，重启也会导致服务暂时不可用。
● 配置多节点维护：在微服务架构中某些核心服务为了保证高性能会部署上百个节点，如果在每个节点中都维护一个配置文件，一旦配置文件中的某个属性需要修改，可想而知，工作量是巨大的。
● 不同部署环境下配置的管理：前面提到通过profile机制来管理不同环境下的配置，这种方式对于日常维护来说也比较繁琐。
统一配置管理就是弥补上述不足的方法，简单说，最近本的方法是把各个应用系统中的某些配置放在一个第三方中间件上进行统一维护。然后，对于统一配置中心上的数据的变更需要推送到相应的服务节点实现动态跟新，所以微服务架构中，配置中心也是一个核心组件，而Spring Cloud Config就是一个配置中心组件，并且可以Git，SVN，本地文件等作为存储。
我的理解是这样的,甲服务调用乙服务,乙服务调用丙服务…,各服务之间的调用就像是就像一条链子一样,服务众多,调用复杂,一旦出了问题不太好定位,不知道具体是哪个业务出了问题,所以要追踪这条链路上有多少服务参与,这样方便排查
微服务架构是一个分布式架构，它按业务划分服务单元，一个分布式系统往往有很多个服务单元。由于服务单元数量众多，业务的复杂性，如果出现了错误和异常，很难去定位。主要体现在，一个请求可能需要调用很多个服务，而内部服务的调用复杂性，决定了问题难以定位。所以微服务架构中，必须实现分布式链路追踪，去跟进一个请求到底有哪些服务参与，参与的顺序又是怎样的，从而达到每个请求的步骤清晰可见，出了问题，很快定位。
举个例子，在微服务系统中，一个来自用户的请求，请求先达到前端A（如前端界面），然后通过远程调用，到达系统的中间件B、C（如负载均衡、网关等），最后达到后端服务D、E，后端经过一系列的业务逻辑计算最后将数据返回给用户。对于这样一个请求，经历了这么多个服务，怎么样将它的请求过程的数据记录下来呢？这就需要用到服务链路追踪。
Google开源的 Dapper链路追踪组件，并在2010年发表了论文《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》，这篇文章是业内实现链路追踪的标杆和理论基础，具有非常大的参考价值。
目前，链路追踪组件有Google的Dapper，Twitter 的Zipkin，以及阿里的Eagleeye （鹰眼）等，它们都是非常优秀的链路追踪开源组件。
Spring Cloud Sleuth采用的是Google的开源项目Dapper的专业术语。
- Span：基本工作单元，发送一个远程调度任务 就会产生一个Span，Span有一个64位ID唯一标识的，Trace是用另一个64位ID唯一标识的，Span还有其他数据信息，比如摘要、时间戳事件、Span的ID、以及进度ID。
- Trace：一系列Span组成的一个树状结构。请求一个微服务系统的API接口，这个API接口，需要调用多个微服务，调用每个微服务都会产生一个新的Span，所有由这个请求产生的Span组成了这个Trace。
- Annotation：用来及时记录一个事件的，一些核心注解用来定义一个请求的开始和结束 。这些注解包括以下：
- cs - Client Sent -客户端发送一个请求，这个注解描述了这个Span的开始
- sr - Server Received -服务端获得请求并准备开始处理它，如果将其sr减去cs时间戳便可得到网络传输的时间。
- ss - Server Sent （服务端发送响应）–该注解表明请求处理的完成(当请求返回客户端)，如果ss的时间戳减去sr时间戳，就可以得到服务器请求的时间。
- cr - Client Received （客户端接收响应）-此时Span的结束，如果cr的时间戳减去cs时间戳便可以得到整个请求所消耗的时间。
