springCloud – 源码巴士

springboot与springcloud关系

springboot专注于快速，方便的开发单个个体微服务
springcloud关注全局服务治理框架

传统网站架构图：

在这里插入图片描述

springcloud中文社区：https://www.springcloud.cc/spring-cloud-greenwich.html

springclould 架构图：

在这里插入图片描述

基于restful风格 Eureka：

在这里插入图片描述

1.springClould 介绍

springCloud封装了NetFlix公司开发的Eureka模块来实现服务注册和发现
Eureka采用C-S的架构设计，EurekaServer作为服务注册功能的服务器，他是服务注册中心
而系统中的其他微服务，使用Eureka的客户端连接到EurekaServer并维持心跳连接，这样系统维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行，springCloud的一些其他模块（比如Zuul）就可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑

Eureka包含组件：Eureka Server 和Eureka Client

Eureka Server：提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面（ http://eureka7001.com:7001/ ）中直观的看到。

Eureka Client ：是一个Java客户端，用于简化EurekaServer的交互，客户端同时也具备一个内置的，使用轮询算法的负载均衡，在应用启动后，将会向EurekaServer发送心跳（默认周期为30秒）。如果Eureka Server在多个心跳周期没有收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除掉

1.1注册中心Server端主要对外提供了三个功能：

服务注册

在这里插入图片描述

注册中心进行统一的服务治理

续约：服务提供者和注册中心之间的心跳机制，默认30s一次

下线：服务提供者向注册中心发送下线请求，注册中心清除数据，避免发送无效请求给provider

提供注册表
服务消费者在调用服务时，如果 Eureka Client 没有缓存注册表的话，会从 Eureka Server 获取最新的注册表
同步状态
Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态。

1.2 Eureka Client：注册中心客户端

Eureka Client：注册中心客户端
Eureka Client 是一个 Java 客户端，用于简化与 Eureka Server 的交互。Eureka Client 会拉取、更新和缓存 Eureka Server 中的信息。因此当所有的 Eureka Server 节点都宕掉，服务消费者依然可以使用缓存中的信息找到服务提供者，但是当服务有更改的时候会出现信息不一致。
Register: 服务注册
服务的提供者，将自身注册到注册中心，服务提供者也是一个 Eureka Client。当 Eureka Client 向 Eureka Server 注册时，它提供自身的元数据，比如 IP 地址、端口，运行状况指示符 URL，主页等。
Renew: 服务续约 （心跳机制）
Eureka Client 会每隔 30 秒发送一次心跳来续约。通过续约来告知 Eureka Server 该 Eureka Client 运行正常，没有出现问题。默认情况下，如果 Eureka Server 在 长时间90 秒内没有收到 Eureka Client 的续约，Server 端会将实例从其注册表中剔除（服务剔除），此时间可配置，一般情况不建议更改。
- eureka.instance.lease-renewal-interval-in-seconds=30 //CS之间的心跳间隔
- eureka.instance.lease-expiration-duration-in-seconds=90 //服务失效时间
GetRegisty: 获取注册列表信息
Eureka Client 从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟，向Server端拉取数据）更新一次。每次返回注册列表信息可能与 Eureka Client 的缓存信息不同，Eureka Client 自动处理。
- eureka.client.fetch-registry=true //开启服务消费者从注册中心拉取服务列表的功能
- eureka.client.registry-fetch-interval-seconds=30 //服务消费者从注册中心拉取服务列表的间隔
拉取注册表信息的方式：
- 全量拉取 ：启动时通过 peer() 方法全量拉取Server端的注册信息
- 增量拉取 ：运行时通过 replicateToPeers() 方法拉取新增的注册信息
如果由于某种原因导致注册列表信息不能及时匹配，Eureka Client 则会重新获取整个注册表信息。 Eureka Server 缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka Client 和 Eureka Server 可以使用 JSON/XML 格式进行通讯。在默认情况下 Eureka Client 使用压缩 JSON 格式来获取注册列表的信息。

Eureka Client 端启动步骤：

在这里插入图片描述

2.EureKa Server端的自我保护机制：

一句话概括： 好死不如赖活着

EureKa自我保护机制触发条件：每分钟的心跳数小于某个值n，就开启自我保护机制

一句话总结就是：某时刻某一个微服务不可用，eureka不会立即清理，依旧会对该微服务的信息进行保存！

详细介绍：

默认情况下，当eureka server在一定时间内没有收到实例的心跳，便会把该实例从注册表中删除（默认是90秒），但是，如果短时间内丢失大量的实例心跳，便会触发eureka server的自我保护机制，比如在开发测试时，需要频繁地重启微服务实例，但是我们很少会把eureka server一起重启（因为在开发过程中不会修改eureka注册中心），当一分钟内收到的心跳数大量减少时，会触发该保护机制。可以在eureka管理界面看到Renews threshold和Renews(last min)，当后者（最后一分钟收到的心跳数）小于前者（心跳阈值）的时候，触发保护机制，会出现红色的警告：EMERGENCY!EUREKA MAY BE INCORRECTLY CLAIMING INSTANCES ARE UP WHEN THEY’RE NOT.RENEWALS ARE LESSER THAN THRESHOLD AND HENCE THE INSTANCES ARE NOT BEGING EXPIRED JUST TO BE SAFE

在这里插入图片描述

从警告中可以看到，eureka认为虽然收不到实例的心跳，但它认为实例还是健康的，eureka会保护这些实例，不会把它们从注册表中删掉。

该保护机制的目的是避免网络连接故障，在发生网络故障时，微服务和注册中心之间无法正常通信，但服务本身是健康的，不应该注销该服务，如果eureka因网络故障而把微服务误删了，那即使网络恢复了，该微服务也不会重新注册到eureka server了，因为只有在微服务启动的时候才会发起注册请求，后面只会发送心跳和服务列表请求，这样的话，该实例虽然是运行着，但永远不会被其它服务所感知。所以，eureka server在短时间内丢失过多的客户端心跳时，会进入自我保护模式，该模式下，eureka会保护注册表中的信息，不在注销任何微服务，当网络故障恢复后，eureka会自动退出保护模式。自我保护模式可以让集群更加健壮。

但是我们在开发测试阶段，需要频繁地重启发布，如果触发了保护机制，则旧的服务实例没有被删除，这时请求有可能跑到旧的实例中，而该实例已经关闭了，这就导致请求错误，影响开发测试。所以，在开发测试阶段，我们可以把自我保护模式关闭，只需在eureka server配置文件中加上如下配置即可

eureka.server.enable-self-preservation=false【不推荐关闭自我保护机制】

3.CAP理论的核心

RDBMS (MySQL\Oracle\sqlServer) ===> ACID

NoSQL (Redis\MongoDB) ===> CAP

ACID：

A（atomicity）原子性
C（consistency）一致性
I （isolation）隔离性
D（Durability）持久性

CAP原则：CAP（3选2）

C（consistency）强一致性
A（Availability）可用性
P（Partition tolerance）区分容错性

一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求
根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类

CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差
CP：满足一致性，分区容错的系统，通常性能不是特别高
AP：满足可用性，分区容错的系统，通常可能对一致性要求低一些

4.作为分布式服务注册中心，Eureka比Zookeeper好在哪里？

著名的CAP理论指出，一个分布式系统不可能同时满足C (一致性) 、A (可用性) 、P (容错性)，由于分区容错性P再分布式系统中是必须要保证的，因此我们只能再A和C之间进行权衡。

Eureka 缺点 ：

由于集群件的同步复制是通过HTTP的方式进行的，基于网络的不可靠，集群中的Eureka Server间的注册表信息难免存在不同步的时间节点，不满足CAP中的C（数据一致性）

Zookeeper 保证的是 CP —> 满足一致性，分区容错的系统，通常性能不是特别高
Eureka 保证的是 AP —> 满足可用性，分区容错的系统，通常可能对一致性要求低一些

Zookeeper保证的是CP

当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但zookeeper会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30-120s，且选举期间整个zookeeper集群是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zookeeper集群失去master节点是较大概率发生的事件，虽然服务最终能够恢复，但是，漫长的选举时间导致注册长期不可用，是不可容忍的。

Eureka保证的是AP

Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在，就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有之中自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

Eureka不在从注册列表中移除因为长时间没收到心跳而应该过期的服务
Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上 (即保证当前节点依然可用)
当网络稳定时，当前实例新的注册信息会被同步到其他节点中

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

dubbo和springclould的区别

dubbo 基于 RPC：

springclould ：基于restful

restfu是l基于HTTP的4个动作（GET，POST，PUT，DELETE）实现的

5.Ribbon负载均衡(基于客户端)

客户端负载均衡：消费方从服务注册中心获取可用服务列表，然后根据指定负载均衡策略选择合适的服务器。Ribbon就属于该方式。

服务端负载均衡：访问请求通过某种策略转发至服务的提供方；

Ribbon是什么？

Spring Cloud Ribbon 是基于Netflix Ribbon 实现的一套客户端负载均衡的工具。
简单的说，Ribbon 是 Netflix 发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将 Netflix 的中间层服务连接在一起。Ribbon 的客户端组件提供一系列完整的配置项，如：连接超时、重试等。简单的说，就是在配置文件中列出 LoadBalancer (简称LB：负载均衡) 后面所有的及其，Ribbon 会自动的帮助你基于某种规则 (如简单轮询，随机连接等等) 去连接这些机器。我们也容易使用 Ribbon 实现自定义的负载均衡算法！

Ribbon能干嘛？

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-FyMzB9s6-1662453506464)(C:\Users\HP\Desktop\学习方向\springcloud\图片\Ribbon能干嘛.PNG)]

LB，即负载均衡 (LoadBalancer) ，在微服务或分布式集群中经常用的一种应用。
负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA (高用)。常见的负载均衡软件有 Nginx、Lvs 等等。
Dubbo、SpringCloud 中均给我们提供了负载均衡，SpringCloud 的负载均衡算法可以自定义。

负载均衡简单分类：

集中式LB（load balance）

即在服务的提供方和消费方之间使用独立的LB设施，如Nginx(反向代理服务器)，由该设施负责把访问请求通过某种策略转发至服务的提供方！

进程式 LB

将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出一个合适的服务器。
Ribbon 就属于进程内LB，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址！

负载均衡算法结构

在这里插入图片描述

负载均衡算法详解

在这里插入图片描述

6.Feign 负载均衡

feign是对于Ribbon的封装，Feign是声明式Web Service客户端，它让微服务之间的调用变得更简单，类似controller调用service。SpringCloud集成了Ribbon和Eureka，可以使用Feigin提供负载均衡的http客户端

只需要创建一个接口，然后添加注解即可~

Feign，主要是社区版，大家都习惯面向接口编程。这个是很多开发人员的规范。调用微服务访问两种方法

6.1Feign能干什么？

Feign旨在使编写Java Http客户端变得更容易

前面在使用Ribbon + RestTemplate时，利用RestTemplate对Http请求的封装处理，形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用，所以通常都会针对每个微服务自行封装一个客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步的封装，由他来帮助我们定义和实现依赖服务接口的定义，在Feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它 (类似以前Dao接口上标注Mapper注解，现在是一个微服务接口上面标注一个Feign注解)，即可完成对服务提供方的接口绑定，简化了使用Spring Cloud Ribbon 时，自动封装服务调用客户端的开发量。

Feign默认集成了Ribbon

利用Ribbon维护了MicroServiceCloud-Dept的服务列表信息，并且通过轮询实现了客户端的负载均衡，而与Ribbon不同的是，通过Feign只需要定义服务绑定接口且以声明式的方法，优雅而简单的实现了服务调用。

Feign和Ribbon如何选择？

根据个人习惯而定，如果喜欢REST风格使用Ribbon；如果喜欢社区版的面向接口风格使用Feign.

Feign 本质上也是实现了 Ribbon，只不过后者是在调用方式上，为了满足一些开发者习惯的接口调用习惯！

引入问题：服务调用出问题的怎么办？服务发生雪崩怎么办？

7.Hystrix 服务熔断和降级

7.1分布式系统面临的问题 :

复杂分布式体系结构中的应用程序有多个依赖关系，每个依赖关系在某些时候将不可避免失败！

服务雪崩：多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“扇出”，如果扇出的链路上某个微服务的调用响应时间过长，或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。
概括就是：服务不可用，就重试，导致网络流量巨增，导致服务调用者不可用

在这里插入图片描述

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几十秒内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障，这些都表示需要对故障和延迟进行隔离和管理，以达到单个依赖关系的失败而不影响整个应用程序或系统运行。

7.2 什么是Hystrix？

Hystrix是一个应用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时，异常等，Hystrix 能够保证在一个依赖出问题的情况下，不会导致整个体系服务失败，避免级联故障，以提高分布式系统的弹性。

“断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控 (类似熔断保险丝) ，向调用方返回一个服务预期的，可处理的备选响应 (FallBack) ，而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mZWB6PiQ-1662453506466)(C:\Users\HP\Desktop\学习方向\springcloud\图片\hyxtrix的作用.PNG)]

7.3 Hystrix能干嘛？

服务降级
服务熔断
服务限流
接近实时的监控

熔断，降级，限流概括：

熔断：熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路
降级：服务分优先级，为了在整体资源不够的时候，牺牲非核心服务（不可用），保证核心服务稳定；从整体负荷考虑；
限流：限制并发的请求访问量，超过阈值则拒绝；

当一切正常时，请求流可以如下所示：

在这里插入图片描述

随着大容量通信量的增加，单个后端依赖项的潜在性会导致所有服务器上的所有资源在几秒钟内饱和。

应用程序中通过网络或客户端库可能导致网络请求的每个点都是潜在故障的来源。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，从而备份队列、线程和其他系统资源，从而导致更多跨系统的级联故障。
在这里插入图片描述

当使用Hystrix包装每个基础依赖项时，上面的图表中所示的体系结构会发生类似于以下关系图的变化。每个依赖项是相互隔离的，限制在延迟发生时它可以填充的资源中，并包含在回退逻辑中，该逻辑决定在依赖项中发生任何类型的故障时要做出什么样的响应：

在这里插入图片描述

服务熔断是什么？

在这里插入图片描述

熔断机制是应对雪崩效应的一种微服务链路保护机制。

当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阀值缺省是5秒内20次调用失败，就会启动熔断机制。熔断机制的注解是：@HystrixCommand。

服务熔断解决如下问题：

当所依赖的对象不稳定时，能够起到快速失败的目的；
快速失败后，能够根据一定的算法动态试探所依赖对象是否恢复。

Hystrix可用于：提供备用的逻辑，返回兜底的数据

服务降级是什么？

服务降级是指当服务器压力剧增的情况下，根据实际业务情况及流量，对一些服务和页面有策略的不处理，或换种简单的方式处理，从而释放服务器资源以保证核心业务正常运作或高效运作。说白了，就是尽可能的把系统资源让给优先级高的服务。
资源有限，而请求是无限的。如果在并发高峰期，不做服务降级处理，一方面肯定会影响整体服务的性能，严重的话可能会导致宕机某些重要的服务不可用。所以，一般在高峰期，为了保证核心功能服务的可用性，都要对某些服务降级处理。比如当双11活动时，把交易无关的服务统统降级，如查看蚂蚁深林，查看历史订单等等。
服务降级主要用于什么场景呢？当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，可以将一些不重要或不紧急的服务或任务进行服务的延迟使用或暂停使用。
降级的方式可以根据业务来，可以延迟服务，比如延迟给用户增加积分，只是放到一个缓存中，等服务平稳之后再执行；或者在粒度范围内关闭服务，比如关闭相关文章的推荐。

在这里插入图片描述

由上图可得，当某一时间内服务A的访问量暴增，而B和C的访问量较少，为了缓解A服务的压力，这时候需要B和C暂时关闭一些服务功能，去承担A的部分服务，从而为A分担压力，叫做服务降级。

服务降级需要考虑的问题？

那些服务是核心服务，哪些服务是非核心服务
那些服务可以支持降级，那些服务不能支持降级，降级策略是什么
除服务降级之外是否存在更复杂的业务放通场景，策略是什么？

自动降级分类

超时降级：主要配置好超时时间和超时重试次数和机制，并使用异步机制探测回复情况
失败次数降级：主要是一些不稳定的api，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况
故障降级：比如要调用的远程服务挂掉了（网络故障、DNS故障、http服务返回错误的状态码、rpc服务抛出异常），则可以直接降级。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）
限流降级：秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃，此时会使用限流来进行限制访问量，当达到限流阀值，后续请求会被降级；降级后的处理方案可以是：排队页面（将用户导流到排队页面等一会重试）、无货（直接告知用户没货了）、错误页（如活动太火爆了，稍后重试）。

服务熔断和降级的区别

服务熔断—>服务端：某个服务超时或异常，引起熔断~，类似于保险丝(自我熔断)
服务降级—>客户端：从整体网站请求负载考虑，当某个服务熔断或者关闭之后，服务将不再被调用，此时在客户端，我们可以准备一个 FallBackFactory ，返回一个默认的值(缺省值)。会导致整体的服务下降，但是好歹能用，比直接挂掉强。
触发原因不太一样，服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑；管理目标的层次不太一样，熔断其实是一个框架级的处理，每个微服务都需要（无层级之分），而降级一般需要对业务有层级之分（比如降级一般是从最外围服务开始）
实现方式不太一样，服务降级具有代码侵入性(由控制器完成/或自动降级)，熔断一般称为自我熔断。

dashboard （可视化监控面板）：http://localhost:8001/actuator/hystrix.stream

在这里插入图片描述

创建监控页面的步骤：

导入 Hystrix依赖 Eureka依赖 actuator完善监控信息 3个依赖

编写yml配置

server:
  port: 9001

hystrix:
  dashboard:
    proxy-stream-allow-list: localhost

客户端主启动类开启@EnableHystrixDashboard

@SpringBootApplication
@EnableHystrixDashboard  //开启监控依赖
public class DeptConsumerDashboard {
    public static void main(String[] args) {
        SpringApplication.run(DeptConsumerDashboard.class,args);
    }
}

8.Zuul：路由网关

作用：把真实地址隐藏，如http://localhost:8080转换为http://xiaoke.com:服务名

在这里插入图片描述

解决问题：

客户端会多次请求不同的微服务，增加客户端的复杂性
认证复杂，每个服务都要独立认证
难以重构，多个服务可能将会合并成一个或拆分成多个
安全性，微服务不需要向外暴露，通过物理网络隔离

功能：

统一接入：智能路由，AB测试，灰度测试，日志埋点
流量监控：限流处理
安全防护：鉴权，网络物理隔离

什么是zuul?

Zull包含了对请求的路由(用来跳转的)和过滤两个最主要功能：
其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础，而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。Zuul和Eureka进行整合，将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得其他服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。

在这里插入图片描述

注意：Zuul 服务最终还是会注册进 Eureka

提供：代理 + 路由 + 过滤三大功能！

cloud:
  config:
    name: config-client # 需要从git上读取的资源名称，不要后缀
    profile: dev   #读取dev环境
    label: master
    uri: http://localhost:3344

网关限流：

作用：防止短时间内流量剧增导致服务崩溃。

令牌桶：每隔一段时间就往令牌桶放一些令牌（实际情况下需要通过压测来判断需要多少个令牌），拿到令牌的就能继续往下走，拿不到令牌就请求失败。

Nginx与Gateway的区别：

nginx: 流量网关 ：用户访问的总入口，也就是前端页面的容器
gateway：业务网关 针对每一个业务微服务来得，属于业务网关

**流量网关：**与业务网关相反，定义全局性的、跟具体的后端业务应用和服务完全无关的策略网关就是上图右边所示的架构模型——流量网关。流量网关通常只专注于全局的Api管理策略，比如全局流量监控、日志记录、全局限流、黑白名单控制、接入请求到业务系统的负载均衡等，有点类似防火墙。Kong 就是典型的流量网关。
业务网关：对于具体的后端业务应用或者是服务和业务有一定关联性的策略网关就是上图左边的架构模型——业务网关。业务网关针对具体的业务需要提供特定的流控策略、缓存策略、鉴权认证策略等等。

nginx与gateway的区别：

nginx是用C语言写的，自定义扩展的话，要么写C要么写lua
gateway是java语言的一个框架，可以在框架上进行代码的扩展与控制，例如：安全控制，统一异常处理，XXS,SQL注入等；权限控制，黑白名单，性能监控，日志打印等；
gateway的主要功能有，路由，断言，过滤器，利用它的这些特性，可以做流控。
nginx做网关，更多的是做总流量入口，反向代理，负载均衡等，还可以用来做web服务器。

9.服务追踪：zipkin 收集信息

跟踪从网关 - >具体微服务的一整条链路信息

10.Spring Cloud Config 分布式配置

Spring Cloud Config为分布式系统中的外部配置提供服务器和客户端支持。使用Config Server，您可以在所有环境中管理应用程序的外部属性。客户端和服务器上的概念映射与Spring Environment和PropertySource抽象相同，因此它们与Spring应用程序非常契合，但可以与任何以任何语言运行的应用程序一起使用。随着应用程序通过从开发人员到测试和生产的部署流程，您可以管理这些环境之间的配置，并确定应用程序具有迁移时需要运行的一切。服务器存储后端的默认实现使用git，因此它轻松支持标签版本的配置环境，以及可以访问用于管理内容的各种工具。很容易添加替代实现，并使用Spring配置将其插入。

修改 C:\Windows\System32\drivers\etc 下的host文件，模拟分布式主机

127.0.0.1 eureka7001.com
127.0.0.1 eureka7002.com
127.0.0.1 eureka7003.com

原文链接：https://blog.csdn.net/The_xiaoke/article/details/126728332

springboot与springcloud关系

1.springClould 介绍

1.1注册中心Server端主要对外提供了三个功能：

服务注册

提供注册表

同步状态

1.2 Eureka Client：注册中心客户端

Eureka Client：注册中心客户端

Register: 服务注册

Renew: 服务续约 （心跳机制）

GetRegisty: 获取注册列表信息

2.EureKa Server端的自我保护机制：

详细介绍：

3.CAP理论的核心

4.作为分布式服务注册中心，Eureka比Zookeeper好在哪里？

dubbo和springclould的区别

5.Ribbon负载均衡(基于客户端)

Ribbon是什么？

Ribbon能干嘛？

负载均衡简单分类：

6.Feign 负载均衡

6.1Feign能干什么？

Feign和Ribbon如何选择？

引入问题：服务调用出问题的怎么办？服务发生雪崩怎么办？

7.Hystrix 服务熔断和降级

7.1分布式系统面临的问题 :

7.2 什么是Hystrix？

7.3 Hystrix能干嘛？

熔断，降级，限流概括：

服务熔断是什么？

服务降级是什么？

服务降级需要考虑的问题？

自动降级分类

服务熔断和降级的区别

dashboard （可视化监控面板） ：http://localhost:8001/actuator/hystrix.stream

创建监控页面的步骤：

8.Zuul：路由网关

Nginx与Gateway的区别：

nginx与gateway的区别：

9.服务追踪：zipkin 收集信息

10.Spring Cloud Config 分布式配置

Renew: 服务续约（心跳机制）

dashboard （可视化监控面板）：http://localhost:8001/actuator/hystrix.stream