springcloud概要

springcloud系列

第一章 Eureka注册中心原理

---

一、Eureka Server和Eureka Client

Eureka Server提供服务注册

	维护注册表、拉取注册表、更新心跳时间，全部发生在内存里！这是Eureka Server非常核心的一个点。

Eureka Server端多级缓存机制

	而且Eureka Server为了避免同时读写内存数据结构造成的并发冲突问题，还采用了多级缓存机制来进一步提升服务请求的响应速度。

各个微服务节点通过配置启动后，会在EurekaServer中进行注册，这样EurekaServer中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观看到。

在拉取注册表的时候：

• 首先从ReadOnlyCacheMap里查缓存的注册表。 若没有，就找ReadWriteCacheMap里缓存的注册表。
• 如果还没有，就从内存中获取实际的注册表数据。
• 在注册表发生变更的时候：会在内存中更新变更的注册表数据，同时过期掉ReadWriteCacheMap。
  此过程不会影响ReadOnlyCacheMap提供人家查询注册表。
• 一段时间内（默认30秒），各服务拉取注册表会直接读ReadOnlyCacheMap 30秒过后，Eureka
  Server的后台线程发现ReadWriteCacheMap已经清空了，也会清空ReadOnlyCacheMap中的缓存
  下次有服务拉取注册表，又会从内存中获取最新的数据了，同时填充各个缓存。

EurekaClient通过注册中心进行访问

它是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒)
注：“心跳”指的是一段定时发送的自定义信息，让对方知道自己“存活”，以确保连接的有效性。大部分 CS 架构的应用程序都采用了心跳机制，服务端和客户端都可以发心跳。通常情况下是客户端向服务器端发送心跳包，服务端用于判断客户端是否在线。

在服务注册与发现中，有一个注册中心。当服务器启动的时候，会把当前自己服务器的信息比如服务地址通讯地址等以别名方式注册到注册中心上。另一方(消费者服务提供者)，以该别名的方式去注册中心上获取到实际的服务通讯地址，然后再实现本地RPC调用RPC远程调用框架核心设计思想:在于注册中心，因为使用注册中心管理每个服务与服务之间的一个依赖关系(服务治理概念)。在任何RPC远程框架中，都会有一个注册中心存放服务地址相关信息(接口地址)

二、 配置中心原理

Nacos 客户端会循环请求服务端变更的数据，并且超时时间设置为30s，当配置发生变化时，请求的响应会立即返回，否则会一直等到 29.5s+ 之后再返回响应
客户端的请求到达服务端后，服务端将该请求加入到一个叫 allSubs 的队列中，等待配置发生变更时 DataChangeTask主动去触发，并将变更后的数据写入响应对象。
与此同时服务端也将该请求封装成一个调度任务去执行，等待调度的期间就是等DataChangeTask 主动触发的，如果延迟时间到了 DataChangeTask 还未触发的话，则调度任务开始执行数据变更的检查，然后将检查的结果写入响应对象（基于文件的MD5）

三、OpenFeign原理

1、在使用Openfeign时首先会在springboot的启动类上添加@EnableFeignClients注解，该注解会导入FeignClientsRegistrar类，会去扫描所有的带有@FeignClient
导入Feign注册组件扫描注解
2、解析到 @FeignClient 修饰类后， Feign 框架通过扩展 Spring Bean Deifinition 的注册逻辑， 最终注册一个 FeignClientFacotoryBean 进入 Spring 容器
注册特殊工厂bean进入容器
3、Spring 容器在初始化其他用到 @FeignClient 接口的类时， 获得的是 FeignClientFacotryBean 产生的一个代理对象 Proxy.
4、基于 java 原生的动态代理机制， 针对 Proxy 的调用， 都会被统一转发给 Feign 框架所定义的一个 InvocationHandler ， 由该 Handler 完成后续的 HTTP 转换， 发送， 接收， 翻译HTTP响应的工作
扫描所有的带有@FeignClient注册一个 FeignClientFacotoryBean产生 java 原生的动态代理对象，转发给InvocationHandler处理HTTP请求

四、 Spring Cloud Gateway 工作流程说明如下：

1. 客户端将请求发送到 Spring Cloud Gateway 上。
2. Spring Cloud Gateway 通过 Gateway Handler Mapping 找到与请求相匹配的路由，将其发送给 Gateway Web Handler。
3. Gateway Web Handler 通过指定的过滤器链（Filter Chain），将请求转发到实际的服务节点中，执行业务逻辑返回响应结果。
4. 过滤器之间用虚线分开是因为过滤器可能会在转发请求之前（pre）或之后（post）执行业务逻辑。
5. 过滤器（Filter）可以在请求被转发到服务端前，对请求进行拦截和修改，例如参数校验、权限校验、流量监控、日志输出以及协议转换等。
6. 过滤器可以在响应返回客户端之前，对响应进行拦截和再处理，例如修改响应内容或响应头、日志输出、流量监控等。
7. 响应原路返回给客户端。

五、 Hystrix之服务熔断理论：

如果与命令相关的线程池和请求队列，或者信号量（不使用线程池的时候）已经被占满， 那么Hystrix也不会执行命令，而是转接到fallback处理逻辑。
需要注意的是，这里Hystrix所判断的线程池并非容器的线程池，而是每个依赖服务的专有线程池。

六 、 Sentinel 的基本概念

资源 是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如由应用程序提供的服务或者是服务里的方法，甚至可以是一段代码。我们可以通过 Sentinel 提供的 API 来定义一个资源，使其能够被 Sentinel 保护起来。通常情况下，我们可以使用方法名、URL 甚至是服务名来作为资源名来描述某个资源。
规则 围绕资源而设定的规则。Sentinel 支持流量控制、熔断降级、系统保护、来源访问控制和热点参数等多种规则，所有这些规则都可以动态实时调整。

sentinel在内部创建了一个责任链，责任链是由一系列ProcessorSlot对象组成的，每个ProcessorSlot对象负责不同的功能，外部请求是否允许访问资源，需要通过责任链的校验，只有校验通过的，才可以访问资源，如果被校验失败，会抛出BlockException异常。