SpringCloud

基于Spring Cloud Alibaba实现的微服务，解决方案设计架构如图所示：

集群、分布式、微服务、SpringCloud

集群是个物理状态，分布式是个工作方式

• 分布式：一个业务分拆多个子业务，部署在不同的服务器上
• 集群：同一个业务，部署在多个服务器上

分布式是指将不同的业务分布在不同的地方。而集群指的是将几台服务器集中在一起，实现同一业务
分布式中的每一个节点，都可以做集群。而集群并不一定就是分布式的
集群实质是将几台服务器集中在一起，实现同一业务
节点：集群中的一个服务器
集群，有一个组织性，一台服务器垮了，其它的服务器可以顶上来。
分布式的每一个节点，都完成不同的业务，一个节点垮了，那这个业务就不可访问了。
简单说，分布式是以缩短单个任务的执行时间来提升效率的，而集群则是通过提高单位时间内执行的任务数来提升效率。
好的设计应该是分布式和集群的结合，先分布式再集群，具体实现就是业务拆分成很多子业务，然后针对每个子业务进行集群部署，这样每个子业务如果出了问题，整个系统完全不会受影响。

微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。
系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。
微服务的意思也就是将模块拆分成一个独立的服务单元通过接口来实现数据的交互。
微服务与分布式的细微差别是，微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。
分布式和微服的架构很相似，只是部署的方式不一样而已。

---

微服务是一种架构风格
一个应用拆分为一组小型服务
每个服务运行在自己的进程内，也就是可独立部署和升级
服务之间使用轻量级HTTP交互
服务围绕业务功能拆分
可以由全自动部署机制独立部署
去中心化，服务自治。服务可以使用不同的语言、不同的存储技术

Spring Cloud就是微服务系统架构的一站式解决方案
SpringCloud基于SpringBoot提供了一整套微服务的解决方案，包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件，它是各个微服务架构落地技术的集合体,俗称微服务全家桶
建Module
改POM
写YML
主启动
业务类

脑裂问题

脑裂问题，就是同一个集群中的不同节点，对于集群的状态，有了不一样的理解。体现在集群中不同的节点对于master的选择出现了分歧，出现了多个master竞争。

“脑裂”问题可能的成因

1.网络问题：集群间的网络延迟导致一些节点访问不到master，认为master挂掉了从而选举出新的master，并对master上的分片和副本标红，分配新的主分片

2.节点负载：主节点的角色既为master又为data，访问量较大时可能会导致ES停止响应造成大面积延迟，此时其他节点得不到主节点的响应认为主节点挂掉了，会重新选取主节点。

3.内存回收：data节点上的ES进程占用的内存较大，引发JVM的大规模内存回收，造成ES进程失去响应。

脑裂导致的问题：
1）数据不完整性（同时读写共享资源，导致数据损坏）。
2）服务异常（共享资源被瓜分，服务起不来）。
脑裂问题解决方案：

1.减少误判：discovery.zen.ping_timeout节点状态的响应时间，默认为3s，可以适当调大，如果master在该响应时间的范围内没有做出响应应答，判断该节点已经挂掉了。调大参数（如6s，discovery.zen.ping_timeout:6），可适当减少误判。

2.选举触发 discovery.zen.minimum_master_nodes:1

该参数是用于控制选举行为发生的最小集群主节点数量。

当备选主节点的个数大于等于该参数的值，且备选主节点中有该参数个节点认为主节点挂了，进行选举。官方建议为（n/2）+1，n为主节点个数（即有资格成为主节点的节点个数）

增大该参数，当该值为2时，我们可以设置master的数量为3，这样，挂掉一台，其他两台都认为主节点挂掉了，才进行主节点选举。

3.角色分离：即master节点与data节点分离，限制角色

架构

结合SpringCloud Alibaba我们最终的技术搭配方案：

SpringCloud Alibaba - Nacos : 注册中心 (服务发现/注册)

SpringCloud Alibaba- Nacos: 配置中心 (动态配置管理)

SpringCloud - Ribbon: 负载均衡

SpringCloud - Feign: 声明式HTTP客户端(调用远程服务)

SpringCloud Alibaba - Sentinel: 服务容错(限流、降级、熔断)

SpringCloud - Gateway: API 网关 (webflux 编程模式)

SpringCloud - Sleuth:调用链监控

SpringCloud Alibaba - Seata: 原Fescar, 即分布式事务解决方案

OpenFeign

Feign	OpenFiegn
Feign是SpringCloud组件中一个轻量级RESTful的HTTP服务客户端，Feign内置了Ribbon，用来做客户端负载均衡，去调用服务注册中心的服务。Feign的使用方式是：使用Feign的注解定义接口，调用这个接口，就可以调用服务注册中心的服务	OpenFeign 是SpringCloud在Feign的基础上支持了SpringMVC的注解，如@RequestMapping等。OpenFeign 的@FeignClient可以解析SpringMVC的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。

OpenFeign 超时控制是什么？
默认Feign 客户端只等待1秒钟，但是服务端处理需要超过1秒钟，导致Feign 客户端不想等待了，直接返回报错。
为了避免这样的情况，有时候我们需要设置Feign客户端的超时控制。

Feign提供了日志打印功能，我们在项目中可以通过配置来调整日志级别，从而了解Feign中http请求的细节 ，也就是说feign提供的日志功能可以对接口的调用情况进行监控和输出。
日志级别：

      NONE: 默认的，不显示任何日志

      BASIC：仅记录请求方法、URL、响应状态码以及执行时间

      HEADERS：除了BASIC中定义的信息以外，还有请求和响应的头信息

      FULL： 除了HEADERS中定义的信息之外，还有请求和响应的正文及元数据

Gateway

演化原由：单体应用拆分成多个服务后，对外需要一个统一入口，解耦客户端与内部服务
网关核心功能是路由转发，因此不要有耗时操作在网关上处理，让请求快速转发到后端服务上
网关还能做统一的熔断、限流、认证、日志监控等

Spring Cloud Gateway 功能特征

基于Spring Framework 5, Project Reactor 和 Spring Boot 2.0 进行构建；
动态路由：能够匹配任何请求属性；
集成 Spring Cloud 服务发现功能；
可以对路由指定 Predicate（断言）和 Filter（过滤器）；
易于编写的 Predicate（断言）和 Filter（过滤器）；
集成Hystrix的断路器功能；
请求限流功能；
支持路径重写。

网关的职能

网关的分类与功能

最重要的几个概念

Predicate 的使用:通过时间匹配、通过 Cookie 匹配、通过请求 ip 地址进行匹配、通过请求路径匹配、通过请求方式匹配、通过请求参数匹配、组合使用

常用4种限流算法介绍
1、计数器（固定窗口）算法
计数器算法是使用计数器在周期内累加访问次数，当达到设定的限流值时，触发限流策略。下一个周期开始时，进行清零，重新计数。
此算法在单机还是分布式环境下实现都非常简单，使用redis的incr原子自增性和线程安全即可轻松实现。
这个算法通常用于QPS限流和统计总访问量，对于秒级以上的时间周期来说，会存在一个非常严重的问题，那就是临界问题。

假设1min内服务器的负载能力为100，因此一个周期的访问量限制在100，然而在第一个周期的最后5秒和下一个周期的开始5秒时间段内，分别涌入100的访问量，虽然没有超过每个周期的限制量，但是整体上10秒内已达到200的访问量，已远远超过服务器的负载能力，由此可见，计数器算法方式限流对于周期比较长的限流，存在很大的弊端。
2、滑动窗口算法
滑动窗口算法是将时间周期分为N个小周期，分别记录每个小周期内访问次数，并且根据时间滑动删除过期的小周期。
如下图，假设时间周期为1min，将1min再分为2个小周期，统计每个小周期的访问数量，则可以看到，第一个时间周期内，访问数量为75，第二个时间周期内，访问数量为100，超过100的访问则被限流掉了

由此可见，当滑动窗口的格子划分的越多，那么滑动窗口的滚动就越平滑，限流的统计就会越精确。
此算法可以很好的解决固定窗口算法的临界问题。
3、漏桶算法
漏桶算法是访问请求到达时直接放入漏桶，如当前容量已达到上限（限流值），则进行丢弃（触发限流策略）。漏桶以固定的速率进行释放访问请求（即请求通过），直到漏桶为空。

4、令牌桶算法
令牌桶算法是程序以r（r=时间周期/限流值）的速度向令牌桶中增加令牌，直到令牌桶满，请求到达时向令牌桶请求令牌，如获取到令牌则通过请求，否则触发限流策略

限流实现

在 Spring Cloud Gateway 上实现限流是个不错的选择，只需要编写一个过滤器就可以了。有了前边过滤器的基础，写起来很轻松。
Spring Cloud Gateway 已经内置了一个RequestRateLimiterGatewayFilterFactory，我们可以直接使用。
目前RequestRateLimiterGatewayFilterFactory的实现依赖于 Redis，所以我们还要引入spring-boot-starter-data-redis-reactive。实现令牌桶算法限流

Filter的使用
生命周期：pre 在业务逻辑之前、post 在业务逻辑之后
种类：GatewayFilter 单一、GlobalFilter 全局

filter有着非常重要的作用，在“pre”类型的过滤器可以做参数校验、权限校验、流量监控、日志输出、协议转换等，在“post”类型的过滤器中可以做响应内容、响应头的修改，日志的输出，流量监控等。首先需要弄清一点为什么需要网关这一层，这就不得不说下filter的作用了。

Nacos

Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现，配置管理和服务管理平台，他是使用 java 编写的，需要依赖 java 环境

Nacos

1、配置
为什么需要配置？概念。

在系统开发过程中，开发者通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。
目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物理运行环境进行适配。
配置管理一般包含在系统部署的过程中，由系统管理员或者运维人员完成。
配置变更是调整系统运行时的行为的有效手段。
2、配置管理
对配置的多维度管理。

系统配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动。

3、配置项
一个键值对 Key = Value。

一个具体的可配置的参数与其值域（一个键值对），通常以 param-key=param-value 的形式存在。
例如我们常配置系统的日志输出级别（logLevel=INFO|WARN|ERROR） 就是一个配置项。
4、配置集
多个键值对，一般指一个配置文件。

一组相关或者不相关的配置项的集合称为配置集（多个键值对/一个配置文件）。
在系统中，一个配置文件通常就是一个配置集，包含了系统各个方面的配置。
例如，一个配置集可能包含了数据源、线程池、日志级别等配置项。
5、配置集 ID
给这个配置文件起一个全局唯一的 ID。

Nacos 中的某个配置集的 ID。
配置集 ID 是组织划分配置的维度之一。
Data ID 通常用于组织划分系统的配置集。
一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。
Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。
此命名规则非强制。
6、配置分组
多个配置文件放在一起，形成组，一般用于区分项目。
例如，某学校多应用之间的区分，教师应用 TEACHER_GROUP，学生应用
STUDENT_GROUP。

Nacos 中的一组配置集，是组织配置的维度之一。
通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。
当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。
配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。
7、配置快照
缓存配置信息。

Nacos 的客户端 SDK 会在本地生成配置的快照。
当客户端无法连接到 Nacos Server 时，可以使用配置快照显示系统的整体容灾能力。
配置快照类似于 Git 中的本地 commit，也类似于缓存，会在适当的时机更新，但是并没有缓存过期（expiration）的概念。

8、命名空间
区分环境，比如：dev、test、prod 等等。

用于进行租户粒度的配置隔离。
不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。
Namespace 的常用场景之一是不同环境的配置的区分隔离。
例如开发测试环境和生产环境的资源（如配置、服务）隔离等。

9、最佳实践

通常我们可以这样定义 Namespace，Group，DataId：
Namespace：代表不同的「环境」，如：开发、测试， 生产等；
Group：代表某个「项目」，如：XX物流项目，XX教育项目；
DataId：每个项目下往往有若干个「应用」，每个配置集(DataId)是一个应用的「主配置文件」

Nacos原理总结：
1、Nacos 客户端会循环请求服务端，并且超时时间设置为30s，
服务端会把请求放到一个队列中，使用延时队列来实现，延时设为客户端设置的超时时间减掉500ms，
这里为什么要减掉500ms？是服务端响应客户端时，防止客户端超时。
如果配置一直不变，那么服务端就会等到指定延时时间，然后响应客户端，
但是，当配置发生变化时，服务端就不会等待指定延时时间，而是会直接响应客户端。

2、Nacos 客户端能够实时感知到服务端配置发生了变化。
实时感知是建立在客户端拉和服务端“推”的基础上，
但是这里的服务端“推”需要打上引号，因为服务端和客户端直接本质上还是通过 http 进行数据通讯的，
之所以有“推”的感觉，是因为服务端主动将变更后的数据通过 http 的 response 对象提前写入了。

Nacos的实现原理

图中的流程是大家所熟悉的，不同的是在Nacos 中，服务注册时在服务端本地会通过轮询注册中心集群节点地址进行服务得注册，在注册中心上，即Nacos Server上采用了Map保存实例信息，当然配置了持久化的服务会被保存到数据库中，在服务的调用方，为了保证本地服务实例列表的动态感知，Nacos与其他注册中心不同的是，采用了 Pull/Push同时运作的方式。

Sentinel

Sentinel概述
Sentinel (分布式系统的流量防卫兵) 是阿里开源的一套用于服务容错的综合性解决方案。它以流量为切入点, 从流量控制、熔断降级、系统负载保护等多个维度来保护服务的稳定性。
Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景, 例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。

Sentinel核心分为两个部分:
核心库（Java 客户端）：能够运行于所有 Java 运行时环境，同时对Dubbo /Spring Cloud 等框架也有较好的支持。
控制台（Dashboard）：基于 Spring Boot 开发，打包后可以直接运行。

Sentinel 基本概念:

• 资源
  • 资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。在接下来的文档中，我们都会用资源来描述代码块。
  • 只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。
• 规则
  • 围绕资源的实时状态设定的规则，可以包括流量控制规则、熔断降级规则以及系统保护规则。所有规则可以动态实时调整。

服务降级限流
什么是熔断：
​ A 服务调用 B 服务的某个功能，由于网络不稳定问题，或者 B 服务卡机，导致功能时间超长，如果这样子的次数太多，我们可以直接将 B 断路了，（A 不在请求 B 接口）凡是调用 B 服务的直接返回降级数据，不必等待 B 的 超时执行，这样 B 的故障问题，就不会级联影响到 A。

什么是降级：
​ 整个网站处于流量高峰期服务器压力剧增，根据当前自身业务情况以及流量，对一些服务和页面进行有策略的降级/停止服务，所有的调用直接返回降级数据以此缓解服务器资源的压力，以保证核心业务的正常运行，同时也保持了客户和大部分客户等到正确的响应

异同：
​ 相同点
​ 1、为了保证集群大部分服务的可用性和可靠性，防止崩溃，牺牲小我
​ 2、用户最终都是体验到某个功能不可用
​ 不同点：
​ 1、熔断是被调用方的故障，触发系统的主动规则
​ 2、降级是基于全局的考虑停止一些正常服务，释放资源

什么是限流
​ 对打入的服务的请求流量进行控制，使服务能够承担不超过自己能力的流量压力

流控模式：

直接：针对当前资源进行处理
关联：当前资源关联一个B资源，请求发给B，如果B达到阈值，对当前资源进行限流。
链路：以调用链路为单位做限流处理，如：A --> B --> C这个链路的总体流量只按入口A的请求量作为计算。

流控效果：
(1)、快速失败：当求情达到阈值时，直接抛出异常Blocked by Sentinel(flow limiting)，服务器返回状态码429
(2)、Warm UP：预热/冷启动
当系统长期处于低水位的情况下，当流量突然增加时，直接把系统拉升到高水位可能瞬间把系统压垮。通过"冷启动"，让通过的流量缓慢增加，在一定时间内逐渐增加到阈值上限，给冷系统一个预热的时间，避免冷系统被压垮。warm up冷启动主要用于启动需要额外开销的场景，例如建立数据库连接等。
(3)、排队等待： 让请求以匀速通过，阈值类型必须设置为QPS，单机阈值设为5，表明1秒内通过5个，每200ms通过一次。