Spring Cloud学习笔记

参考：https://blog.csdn.net/u011863024/article/details/114298270

零基础微服务架构理论入门

---

1.什么是微服务

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

2.Spring Cloud简介

SpringCloud=分布式微服务架构的站式解决方案，是多种微服务架构落地技术的集合体，俗称微服务全家桶

微服务父工程的创建

---

创建微服务cloud整体聚合父工程Project，有8个关键步骤：

New Project - maven工程 - create from archetype: maven-archetype-site
聚合总父工程名字
Maven选版本
工程名字
字符编码 - Settings - File encoding
注解生效激活 - Settings - Annotation Processors
Java编译版本选8
File Type过滤 - Settings - File Type

• 作用：
  子模块继承之后，提供作用：
  锁定版本+子modlue不用写groupId和version
  注：dependencyManagement里只是声明依赖，并不实现引入，因此子项目需要显示的声明需要用的依赖。

创建微服务模块套路

---

建Module
改POM
写YML
主启动
业务类

• 消费者订单模块控制层

@Slf4j
@RestController
public class OrderController {

    public static final String PAYMENT_URL = "http://localhost:8001";

    @Resource
    private RestTemplate restTemplate;

    @GetMapping("/consumer/payment/create")
    public CommonResult create(Payment payment){
// 转发到服务提供端的/payment/create接口 进行服务的处理
        return restTemplate.postForObject(PAYMENT_URL+"/payment/create", payment, CommonResult.class);
    }

    @GetMapping("/consumer/payment/get/{id}")
    public CommonResult getPayment(@PathVariable("id") Long id){
        return restTemplate.getForObject(PAYMENT_URL+"/payment/get/"+id, CommonResult.class);
    }
}

工程重构

---

观察cloud-consumer-order80与cloud-provider-payment8001两工程有重复代码（entities包下的实体）（坏味道），重构。

1.新建 - cloud-api-commons

2.POM

        LearnCloud
        com.lun.springcloud
        1.0.0-SNAPSHOT
    
    4.0.0

    cloud-api-commons

3.entities

将cloud-consumer-order80与cloud-provider-payment8001两工程的公有entities包移至cloud-api-commons工程下。

4.maven clean、install cloud-api-commons工程，以供给cloud-consumer-order80与cloud-provider-payment8001两工程调用。

5.订单80和支付8001分别改造

将cloud-consumer-order80与cloud-provider-payment8001两工程的公有entities包移除
引入cloud-api-commons依赖

    com.lun.springcloud
    cloud-api-commons
    ${project.version}

Eureka基础知识

---

1. 什么是服务治理

在传统的RPC远程调用框架中，管理每个服务与服务之间依赖关系比较复杂，管理比较复杂，所以需要使用服务治理，管理服务于服务之间依赖关系，可以实现服务调用、负载均衡、容错等，实现服务发现与注册。

2.什么是服务注册与发现

在服务注册与发现中，有一个注册中心。当服务器启动的时候，会把当前自己服务器的信息比如服务地址通讯地址等以别名方式注册到注册中心上。另一方(消费者服务提供者)，以该别名的方式去注册中心上获取到实际的服务通讯地址，然后再实现本地RPC调用

RPC远程调用框架核心设计思想:在于注册中心，因为使用注册中心管理每个服务与服务之间的一个依赖关系(服务治理概念)。在任何RPC远程框架中，都会有一个注册中心存放服务地址相关信息(接口地址)

image.png

3.Eureka包含两个组件:Eureka Server和Eureka Client

Eureka Server提供服务注册服务

EurekaClient通过注册中心进行访问
它是一个Java客户端，用于简化Eureka Server的交互，客户端同时也具备一个内置的、使用轮询(round-robin)负载算法的负载均衡器。在应用启动后，将会向Eureka Server发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会从服务注册表中把这个服务节点移除（默认90秒)

EurekaServer服务端搭建

---

1.创建工程
2.修改pom.xml
3.添加application.yml

erver:
  port: 7001

eureka:
  instance:
    hostname: locathost #eureka服务端的实例名称
  client:
    #false表示不向注册中心注册自己。
    register-with-eureka: false
    #false表示自己端就是注册中心，我的职责就是维护服务实例，并不需要去检索服务
    fetch-registry: false
    service-url:
      #设置与Eureka server交互的地址查询服务和注册服务都需要依赖这个地址。
      defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/

4.主启动
5.测试运行，浏览器输入http://localhost:7001/回车，会查看到Spring Eureka服务主页。

支付微服务入驻进EurekaServer

---

1.修改cloud-provider-payment8001
2.改POM
添加spring-cloud-starter-netflix-eureka-client依赖
3.写YML
4.主启动
5.测试
6.自我保护机制

Eureka集群原理说明

---

image.png

• Eureka集群环境构建
  创建cloud-eureka-server7002工程

  
  
  image.png
  
  

  找到C:\Windows\System32\drivers\etc路径下的hosts文件，修改映射配置添加进hosts文件
  修改cloud-eureka-server7001配置文件
  修改cloud-eureka-server7002配置文件

service-url:
    #集群指向其它eureka
      defaultZone: http://eureka7002.com:7002/eureka/
    #单机就是7001自己
      #defaultZone: http://eureka7001.com:7001/eureka/

• 支付微服务集群配置

1.新建cloud-provider-payment8002

2.改POM

3.写YML - 端口8002

4.主启动

5.业务类

6.修改8001/8002的Controller，添加serverPort

负载均衡
cloud-consumer-order80订单服务访问地址不能写死

@Slf4j
@RestController
public class OrderController {

    //public static final String PAYMENT_URL = "http://localhost:8001";
    public static final String PAYMENT_URL = "http://CLOUD-PAYMENT-SERVICE";
    
    ...
}

使用@LoadBalanced注解赋予RestTemplate负载均衡的能力

@Configuration
public class ApplicationContextConfig {

    @Bean
    @LoadBalanced//使用@LoadBalanced注解赋予RestTemplate负载均衡的能力
    public RestTemplate getRestTemplate(){
        return new RestTemplate();
    }

}

image.png

• actuator微服务信息完善

主机名称：服务名称修改（也就是将IP地址，换成可读性高的名字）

eureka:
  ...
  instance:
    instance-id: payment8001 #添加此处

修改之后
eureka主页将显示payment8001，payment8002代替原来显示的IP地址。

访问信息有IP信息提示设置：
修改部分 - YML - eureka.instance.prefer-ip-address

eureka:
  ...
  instance:
    instance-id: payment8001 
    prefer-ip-address: true #添加此处

服务发现Discovery

---

对于注册进eureka里面的微服务，可以通过服务发现来获得该服务的信息

@RestController
@Slf4j
public class PaymentController{
    ...
    
    @Resource
    private DiscoveryClient discoveryClient;

    ...

    @GetMapping(value = "/payment/discovery")
    public Object discovery()
    {
        List services = discoveryClient.getServices();
        for (String element : services) {
            log.info("*****element: "+element);
        }

        List instances = discoveryClient.getInstances("CLOUD-PAYMENT-SERVICE");
        for (ServiceInstance instance : instances) {
            log.info(instance.getServiceId()+"\t"+instance.getHost()+"\t"+instance.getPort()+"\t"+instance.getUri());
        }

        return this.discoveryClient;
    }
}

主启动类@EnableDiscoveryClient//添加该注解

Eureka自我保护理论知识

---

保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护。一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据，也就是不会注销任何微服务。

• 导致原因
  一句话：某时刻某一个微服务不可用了，Eureka不会立刻清理，依旧会对该微服务的信息进行保存。

属于CAP里面的AP分支。

• 为什么会产生Eureka自我保护机制?
  为了EurekaClient可以正常运行，防止与EurekaServer网络不通情况下，EurekaServer不会立刻将EurekaClient服务剔除

• 什么是自我保护模式?
  自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务（健康的微服务和不健康的微服务都会保留）也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮、稳定。

• 怎么禁止自我保护
  使用eureka.server.enable-self-preservation = false可以禁用自我保护模式

默认：
eureka.instance.lease-renewal-interval-in-seconds=30

eureka.instance.lease-expiration-duration-in-seconds=90

支付服务注册进zookeeper

---

我们用ZooKeeper代替Eureka功能。
注册中心Zookeeper
zookeeper是一个分布式协调工具，可以实现注册中心功能

ZooKeeper的服务节点是临时节点

Consul 简介

---

Consul是一套开源的分布式服务发现和配置管理系统，由HashiCorp 公司用Go语言开发
提供了微服务系统中的服务治理、配置中心、控制总线等功能。

• 能干嘛？
  服务发现 - 提供HTTP和DNS两种发现方式。
  健康监测 - 支持多种方式，HTTP、TCP、Docker、Shell脚本定制化
  KV存储 - Key、Value的存储方式
  多数据中心 - Consul支持多数据中心
  可视化Web界面

三个注册中心异同点

---

image.png

C：Consistency (强一致性)

A：Availability (可用性)

P：Partition tolerance （分区容错性)

CA - 单点集群，满足—致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

Ribbon入门介绍

---

Spring Cloud Ribbon是基于Netflix Ribbon实现的一套客户端负载均衡的工具。主要功能是提供客户端的软件负载均衡算法和服务调用

Ribbon是本地负载均衡客户端
Nginx是服务端负载均衡
Ribbon：负载均衡 + RestTemplate调用

Ribbon的负载均衡和Rest调用：

Ribbon其实就是一个软负载均衡的客户端组件，它可以和其他所需请求的客户端结合使用，和Eureka结合只是其中的一个实例。

Ribbon在工作时分成两步：

第一步先选择EurekaServer ,它优先选择在同一个区域内负载较少的server。

第二步再根据用户指定的策略，在从server取到的服务注册列表中选择一个地址。

image.png

其中Ribbon提供了多种策略：比如轮询、随机和根据响应时间加权

二说RestTemplate的使用：
getForObject() / getForEntity() - GET请求方法

getForObject()：返回对象为响应体中数据转化成的对象，基本上可以理解为Json。

getForEntity()：返回对象为ResponseEntity对象，包含了响应中的一些重要信息，比如响应头、响应状态码、响应体等。

postForObject() / postForEntity() - POST请求方法

Ribbon负载规则替换

---

官方文档明确给出了警告:
其自定义配置类不能放在@ComponentScan所扫描的当前包下以及子包下，否则我们自定义的这个配置类就会被所有的Ribbon客户端所共享，达不到特殊化定制的目的了。（也就是说不要将Ribbon配置类与主启动类同包）

主启动类添加@RibbonClient

• Ribbon默认负载轮询算法原理
  默认负载轮训算法: rest接口第几次请求数 % 服务器集群总数量 = 实际调用服务器位置下标，每次服务重启动后rest接口计数从1开始。

OpenFeign是什么

---

Feign是一个声明式WebService客户端。使用Feign能让编写Web Service客户端更加简单。它的使用方法是定义一个服务接口然后在上面添加注解。

Feign集成了Ribbon

• Feign和OpenFeign两者区别

Feign是Spring Cloud组件中的一个轻量级RESTful的HTTP服务客户端Feign内置了Ribbon，用来做客户端负载均衡，去调用服务注册中心的服务。

OpenFeign是Spring Cloud在Feign的基础上支持了SpringMVC的注解，如@RequesMapping等等。OpenFeign的@Feignclient可以解析SpringMVc的@RequestMapping注解下的接口，并通过动态代理的方式产生实现类，实现类中做负载均衡并调用其他服务。

• OpenFeign服务调用
  接口+注解：微服务调用接口 + @FeignClient

业务逻辑接口+@FeignClient配置调用provider服务

Hystrix是什么

---

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

"断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝)，向调用方返回一个符合预期的、可处理的备选响应（FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

• 能干嘛
  服务降级
  服务熔断
  接近实对的监控

Hystrix的服务降级熔断限流概念

服务降级：
服务器忙，请稍后再试，不让客户端等待并立刻返回一个友好提示，fallback

哪些情况会出发降级：
程序运行导常
超时
服务熔断触发服务降级
线程池/信号量打满也会导致服务降级

服务熔断：
类比保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示。
服务的降级 -> 进而熔断 -> 恢复调用链路

服务限流：
秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行。

降级配置 - @HystrixCommand
—旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法

主启动类激活：
添加新注解@EnableCircuitBreaker

Hystrix之全局服务降级DefaultProperties

目前问题1 每个业务方法对应一个兜底的方法，代码膨胀
解决方法

1:1每个方法配置一个服务降级方法，技术上可以，但是不聪明

1:N除了个别重要核心业务有专属，其它普通的可以通过@DefaultProperties(defaultFallback = “”)统一跳转到统一处理结果页面

通用的和独享的各自分开，避免了代码膨胀，合理减少了代码量

Hystrix之通配服务降级FeignFallback

目前问题2 统一和自定义的分开，代码混乱

只需要为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦

PaymentHystrixService接口
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT" ,// fallback = PaymentFallbackService.class)//指定PaymentFallbackService类

Hystrix之服务熔断理论

---

熔断机制概述:
熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务出错不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

image.png

 @HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback",commandProperties = {
            @HystrixProperty(name = "circuitBreaker.enabled",value = "true"),// 是否开启断路器
            @HystrixProperty(name = "circuitBreaker.requestVolumeThreshold",value = "10"),// 请求次数
            @HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds",value = "10000"), // 时间窗口期
            @HystrixProperty(name = "circuitBreaker.errorThresholdPercentage",value = "60"),// 失败率达到多少后跳闸
    })

熔断类型
熔断打开：请求不再进行调用当前服务，内部设置时钟一般为MTTR(平均故障处理时间)，当打开时长达到所设时钟则进入半熔断状态。
熔断关闭：熔断关闭不会对服务进行熔断。
熔断半开：部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断。

Hystrix图形化Dashboard搭建

除了隔离依赖服务的调用以外，Hystrix还提供了准实时的调用监控(Hystrix Dashboard)，Hystrix会持续地记录所有通过Hystrix发起的请求的执行信息，并以统计报表和图形的形式展示给用户，包括每秒执行多少请求多少成功，多少失败等。

@EnableHystrixDashboard

image.png

GateWay是什么

---

概述
Cloud全家桶中有个很重要的组件就是网关，在1.x版本中都是采用的Zuul网关;
但在2.x版本中，zuul的升级一直跳票，SpringCloud最后自己研发了一个网关替代Zuul，那就是SpringCloud Gateway—句话：gateway是原zuul1.x版的替代

image.png

SpringCloud Gateway是基于WebFlux框架实现的，而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。

作用

方向代理
鉴权
流量控制
熔断
日志监控

微服务架构中网关的位置

image.png

GateWay非阻塞异步模型

Gateway是基于异步非阻塞模型上进行开发的，性能方面不需要担心。

Zuul 1.x基于Servlet 2.5使用阻塞架构它不支持任何长连接(如WebSocket)Zuul的设计模式和Nginx较像，每次I/О操作都是从工作线程中选择一个执行，请求线程被阻塞到工作线程完成，但是差别是Nginx用C++实现，Zuul用Java实现，而JVM本身会有第-次加载较慢的情况，使得Zuul的性能相对较差。

SpringCloud Gateway具有如下特性

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

Gateway工作流程

---

三大核心概念

Route(路由) - 路由是构建网关的基本模块,它由ID,目标URI,一系列的断言和过滤器组成,如断言为true则匹配该路由；

Predicate(断言) - 参考的是Java8的java.util.function.Predicate，开发人员可以匹配HTTP请求中的所有内容(例如请求头或请求参数),如果请求与断言相匹配则进行路由；

Filter(过滤) - 指的是Spring框架中GatewayFilter的实例,使用过滤器,可以在请求被路由前或者之后对请求进行修改。

yml配置

server:
  port: 9527

spring:
  application:
    name: cloud-gateway
#############################新增网关配置###########################
  cloud:
    gateway:
      routes:
        - id: payment_routh #payment_route    #路由的ID，没有固定规则但要求唯一，建议配合服务名
          uri: http://localhost:8001          #匹配后提供服务的路由地址
          #uri: lb://cloud-payment-service #匹配后提供服务的路由地址
          predicates:
            - Path=/payment/get/**         # 断言，路径相匹配的进行路由

        - id: payment_routh2 #payment_route    #路由的ID，没有固定规则但要求唯一，建议配合服务名
          uri: http://localhost:8001          #匹配后提供服务的路由地址
          #uri: lb://cloud-payment-service #匹配后提供服务的路由地址
          predicates:
            - Path=/payment/lb/**         # 断言，路径相匹配的进行路由
####################################################################

eureka:
  instance:
    hostname: cloud-gateway-service
  client: #服务提供者provider注册进eureka服务列表内
    service-url:
      register-with-eureka: true
      fetch-registry: true
      defaultZone: http://eureka7001.com:7001/eureka

Gateway配置路由的两种方式

代码中注入RouteLocator的Bean

RemoteAddressResolver resolver = XForwardedRemoteAddressResolver
    .maxTrustedIndex(1);

...

.route("direct-route",
    r -> r.remoteAddr("10.1.1.1", "10.10.1.1/24")
        .uri("https://downstream1")
.route("proxied-route",
    r -> r.remoteAddr(resolver, "10.10.1.1", "10.10.1.1/24")
        .uri("https://downstream2")
)

GateWay配置动态路由

默认情况下Gateway会根据注册中心注册的服务列表，以注册中心上微服务名为路径创建动态路由进行转发，从而实现动态路由的功能（不写死一个地址）。

yml配置

需要注意的是uri的协议为lb，表示启用Gateway的负载均衡功能。
lb://serviceName是spring cloud gateway在微服务中自动为我们创建的负载均衡uri。

erver:
  port: 9527

spring:
  application:
    name: cloud-gateway
#############################新增网关配置###########################
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true #开启从注册中心动态创建路由的功能，利用微服务名进行路由
      routes:
        - id: payment_routh #payment_route    #路由的ID，没有固定规则但要求唯一，建议配合服务名
          #uri: http://localhost:8001          #匹配后提供服务的路由地址
          uri: lb://cloud-payment-service #匹配后提供服务的路由地址
          predicates:
            - Path=/payment/get/**         # 断言，路径相匹配的进行路由

        - id: payment_routh2 #payment_route    #路由的ID，没有固定规则但要求唯一，建议配合服务名
          #uri: http://localhost:8001          #匹配后提供服务的路由地址
          uri: lb://cloud-payment-service #匹配后提供服务的路由地址
          predicates:
            - Path=/payment/lb/**         # 断言，路径相匹配的进行路由
####################################################################

GateWay常用的Predicate

Spring Cloud Gateway包括许多内置的Route Predicate工厂。所有这些Predicate都与HTTP请求的不同属性匹配。多个RoutePredicate工厂可以进行组合。

Spring Cloud Gateway创建Route 对象时，使用RoutePredicateFactory 创建 Predicate对象，Predicate 对象可以赋值给Route。Spring Cloud Gateway包含许多内置的Route Predicate Factories。

所有这些谓词都匹配HTTP请求的不同属性。多种谓词工厂可以组合，并通过逻辑and。

常用的Route Predicate Factory

The After Route Predicate Factory
The Before Route Predicate Factory
The Between Route Predicate Factory
The Cookie Route Predicate Factory
The Header Route Predicate Factory
The Host Route Predicate Factory
The Method Route Predicate Factory
The Path Route Predicate Factory
The Query Route Predicate Factory
The RemoteAddr Route Predicate Factory
The weight Route Predicate Factory

spring:
  cloud:
    gateway:
      routes:
      - id: after_route
        uri: https://example.org
        predicates:
        # 这个时间后才能起效
        - After=2017-01-20T17:42:47.789-07:00[America/Denver]

说白了，Predicate就是为了实现一组匹配规则，让请求过来找到对应的Route进行处理。

GateWay的Filter

---

路由过滤器可用于修改进入的HTTP请求和返回的HTTP响应，路由过滤器只能指定路由进行使用。Spring Cloud Gateway内置了多种路由过滤器，他们都由GatewayFilter的工厂类来产生。

自定义全局GlobalFilter：

能干什么：
全局日志记录
统一网关鉴权
…

两个主要接口：
GlobalFilter 重新filter方法实习自定义过滤
Ordered 过滤器优先级

@Component
@Slf4j
public class MyLogGateWayFilter implements GlobalFilter,Ordered
{

    @Override
    public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain)
    {
        log.info("***********come in MyLogGateWayFilter:  "+new Date());

        String uname = exchange.getRequest().getQueryParams().getFirst("uname");

        if(uname == null)
        {
            log.info("*******用户名为null，非法用户，o(╥﹏╥)o");
            exchange.getResponse().setStatusCode(HttpStatus.NOT_ACCEPTABLE);
            return exchange.getResponse().setComplete();
        }

        return chain.filter(exchange);
    }

    @Override
    public int getOrder()
    {
        return 0;
    }
}

Config分布式配置中心介绍

---

分布式系统面临的配置问题

微服务意味着要将单体应用中的业务拆分成一个个子服务，每个服务的粒度相对较小，因此系统中会出现大量的服务。由于每个服务都需要必要的配置信息才能运行，所以一套集中式的、动态的配置管理设施是必不可少的。

是什么

image.png

SpringCloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为各个不同微服务应用的所有环境提供了一个中心化的外部配置。

能干嘛：

集中管理配置文件

不同环境不同配置，动态化的配置更新，分环境部署比如dev/test/prod/beta/release

运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一拉取配置自己的信息

当配置发生变动时，服务不需要重启即可感知到配置的变化并应用新的配置

将配置信息以REST接口的形式暴露 - post/crul访问刷新即可…

SpringCloud Config默认使用Git来存储配置文件

Config配置总控中心搭建

yml

spring:
  application:
    name:  cloud-config-center #注册进Eureka服务器的微服务名
  cloud:
    config:
      server:
        git:
          uri: [email protected]:zzyybs/springcloud-config.git #GitHub上面的git仓库名字
        ####搜索目录
          search-paths:
            - springcloud-config
      ####读取分支
      label: master

配置读取规则

/{label}/{application}-{profile}.yml（推荐）

/{application}-{profile}.yml

/{application}/{profile}[/{label}

label：分支(branch)
name：服务名
profiles：环境(dev/test/prod)

Config客户端配置与测试

bootstrap.yml
bootstrap.yml是系统级的，优先级更加高

Spring Cloud会创建一个Bootstrap Context，作为Spring应用的Application Context的父上下文。

初始化的时候，BootstrapContext负责从外部源加载配置属性并解析配置。这两个上下文共享一个从外部获取的Environment。

要将Client模块下的application.yml文件改为bootstrap.yml,这是很关键的，因为bootstrap.yml是比application.yml先加载的。bootstrap.yml优先级高于application.yml。

Config动态刷新之手动版

避免每次更新配置都要重启客户端微服务3355

动态刷新步骤：

修改3355模块:
POM引入actuator监控
修改YML，添加暴露监控端口配置：

# 暴露监控端点
management:
  endpoints:
    web:
      exposure:
        include: "*"

@RefreshScope业务类Controller修改

需要运维人员发送Post请求刷新3355

curl -X POST "http://localhost:3355/actuator/refresh"

Bus消息总线是什么

---

Spring Cloud Bus配合Spring Cloud Config使用可以实现配置的动态刷新。

Spring Cloud Bus是用来将分布式系统的节点与轻量级消息系统链接起来的框架，它整合了Java的事件处理机制和消息中间件的功能。Spring Clud Bus目前支持RabbitMQ和Kafka。

能干嘛
Spring Cloud Bus能管理和传播分布式系统间的消息，就像一个分布式执行器，可用于广播状态更改、事件推送等，也可以当作微服务间的通信通道。

什么是总线
在微服务架构的系统中，通常会使用轻量级的消息代理来构建一个共用的消息主题，并让系统中所有微服务实例都连接上来。由于该主题中产生的消息会被所有实例监听和消费，所以称它为消息总线。

基本原理
ConfigClient实例都监听MQ中同一个topic(默认是Spring Cloud Bus)。

Bus动态刷新全局广播的设计思想和选型

1.利用消息总线触发一个客户端/bus/refresh,而刷新所有客户端的配置

2.利用消息总线触发一个服务端ConfigServer的/bus/refresh端点，而刷新所有客户端的配置

Bus动态刷新定点通知

不想全部通知，只想定点通知
单一句话 - 指定具体某一个实例生效而不是全部

公式：http://localhost:3344/actuator/bus-refresh/{destination}
/bus/refresh请求不再发送到具体的服务实例上，而是发给config server通过destination参数类指定需要更新配置的服务或实例

Stream为什么被引入

---

屏蔽底层消息中间件的差异，降低切换成本，统一消息的编程模型。
让我们不再关注具体MQ的细节，我们只需要用一种适配绑定的方式，自动的给我们在各种MQ内切换。

什么是Spring Cloud Stream？

官方定义Spring Cloud Stream是一个构建消息驱动微服务的框架。

应用程序通过inputs或者 outputs 来与Spring Cloud Stream中binder对象交互。

通过我们配置来binding(绑定)，而Spring Cloud Stream 的binder对象负责与消息中间件交互。所以，我们只需要搞清楚如何与Spring Cloud Stream交互就可以方便使用消息驱动的方式。

Stream的设计思想

通过定义绑定器Binder作为中间层，实现了应用程序与消息中间件细节之间的隔离。

Binder：

INPUT对应于消费者

OUTPUT对应于生产者

Stream中的消息通信方式遵循了发布-订阅模式

image.png

image.png

Binder - 很方便的连接中间件，屏蔽差异。

Channel - 通道，是队列Queue的一种抽象，在消息通讯系统中就是实现存储和转发的媒介，通过Channel对队列进行配置。

Source和Sink - 简单的可理解为参照对象是Spring Cloud Stream自身，从Stream发布消息就是输出，接受消息就是输入。

编码API和常用注解

image.png

Stream之消息重复消费

运行后有两个问题

有重复消费问题
消息持久化问题

重复消费问题可以使用Stream中的消息分组来解决。

持久化问题：
停止8802/8803并去除掉8802的分组group: A_Group，8803的分组group: A_Group没有去掉。

8801先发送4条消息到RabbitMq。

先启动8802，无分组属性配置，后台没有打出来消息。

再启动8803，有分组属性配置，后台打出来了MQ上的消息。(消息持久化体现)

持久化问题也可以使用Stream中的消息分组来解决。

Sleuth是什么

---

服务跟踪的解决方案，可以追踪各服务之间调用的关系。

完整的调用链路：表示一请求链路，一条链路通过Trace ld唯一标识，Span标识发起的请求信息，各span通过parent id关联起来

image.png

Cloud Alibaba简介

---

为什么会出现SpringCloud alibaba：
Spring Cloud Netflix项目进入维护模式
将模块置于维护模式，意味着Spring Cloud团队将不会再向模块添加新功能

Spring Cloud Alibaba 致力于提供微服务开发的一站式解决方案。此项目包含开发分布式应用微服务的必需组件，方便开发者通过 Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。

Nacos简介

---

一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
Nacos就是注册中心＋配置中心的组合 -> Nacos = Eureka+Config+Bus

Nacos安装

• 从官网下载Nacos
• 解压安装包，直接运行bin目录下的startup.cmd
  命令运行成功后直接访问http://localhost:8848/nacos，默认账号密码都是nacos

Nacos和CAP

image.png

Nacos支持AP和CP模式的切换

何时选择使用何种模式?

—般来说，如果不需要存储服务级别的信息且服务实例是通过nacos-client注册，并能够保持心跳上报，那么就可以选择AP模式。当前主流的服务如Spring cloud和Dubbo服务，都适用于AP模式，AP模式为了服务的可能性而减弱了一致性，因此AP模式下只支持注册临时实例。

如果需要在服务级别编辑或者存储配置信息，那么CP是必须，K8S服务和DNS服务则适用于CP模式。CP模式下则支持注册持久化实例，此时则是以Raft协议为集群运行模式，该模式下注册实例之前必须先注册服务，如果服务不存在，则会返回错误。

Nacos之服务配置中心

在 Nacos Spring Cloud中,dataId的完整格式如下：
${prefix}-${spring-profile.active}.${file-extension}

prefix默认为spring.application.name的值，也可以通过配置项spring.cloud.nacos.config.prefix来配置。

spring.profile.active即为当前环境对应的 profile

file-exetension为配置内容的数据格式，可以通过配置项spring .cloud.nacos.config.file-extension来配置。目前只支持properties和yaml类型。

通过Spring Cloud 原生注解@RefreshScope实现配置自动更新。

• 自带动态刷新

修改下Nacos中的yaml配置文件，再次调用查看配置的接口，就会发现配置已经刷新。

Nacos之命名空间、分组和DataID三者关系

image.png

默认情况：Namespace=public，Group=DEFAULT_GROUP，默认Cluster是DEFAULT
Nacos默认的Namespace是public，Namespace主要用来实现隔离。
比方说我们现在有三个环境：开发、测试、生产环境，我们就可以创建三个Namespace，不同的Namespace之间是隔离的。
Group默认是DEFAULT_GROUP，Group可以把不同的微服务划分到同一个分组里面去
Service就是微服务:一个Service可以包含多个Cluster (集群)，Nacos默认Cluster是DEFAULT，Cluster是对指定微服务的一个虚拟划分。
比方说为了容灾，将Service微服务分别部署在了杭州机房和广州机房，这时就可以给杭州机房的Service微服务起一个集群名称(HZ) ，给广州机房的Service微服务起一个集群名称(GZ)，还可以尽量让同一个机房的微服务互相调用，以提升性能。
最后是Instance，就是微服务的实例。

Nacos集群_架构说明

---

image.png

默认Nacos使用嵌入式数据库实现数据的存储。所以，如果启动多个默认配置下的Nacos节点，数据存储是存在一致性问题的。为了解决这个问题，Nacos采用了集中式存储的方式来支持集群化部署，目前只支持MySQL的存储。

Nacos持久化切换配置

derby到mysql切换配置步骤：

• nacos-server-1.1.4\nacos\conf录下找到nacos-mysql.sql文件，执行脚本。
• nacos-server-1.1.4\nacos\conf目录下找到application.properties，添加以下配置（按需修改对应值）。

spring.datasource.platform=mysql

db.num=1
db.url.0=jdbc:mysql://localhost:3306/nacos_devtest?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
db.user=root
db.password=123456

Nacos集群配置

1.Linux服务器上mysql数据库配置
SQL脚本在哪里 - 目录nacos/conf/nacos-mysql.sql

2.application.properties配置

image.png

添加以下内容，设置数据源

spring.datasource.platform=mysql

db.num=1
db.url.0=jdbc:mysql://localhost:3306/nacos_devtest?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
db.user=root
db.password=1234

3.Linux服务器上nacos的集群配置cluster.conf

image.png

添加内容

192.168.111.144:3333
192.168.111.144:4444
192.168.111.144:5555

注意，这个IP不能写127.0.0.1，必须是Linux命令hostname -i能够识别的IP

4.编辑Nacos的启动脚本startup.sh，使它能够接受不同的启动端口

image.png

平时单机版的启动，都是./startup.sh即可

但是，集群启动，我们希望可以类似其它软件的shell命令，传递不同的端口号启动不同的nacos实例。
命令: ./startup.sh -p 3333表示启动端口号为3333的nacos服务器实例，和上一步的cluster.conf配置的一致。

image.png

image.png

5.Nginx的配置，由它作为负载均衡器
修改nginx的配置文件 - nginx.conf

image.png

修改内容

image.png

按照指定启动

image.png

6.截止到此处，1个Nginx+3个nacos注册中心+1个mysql

Sentinel是什么

---

随着微服务的流行，服务和服务之间的稳定性变得越来越重要。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
Sentinel 的主要特性：

image.png

Hystrix与Sentinel比较：
Hystrix
需要我们程序员自己手工搭建监控平台
没有一套web界面可以给我们进行更加细粒度化得配置流控、速率控制、服务熔断、服务降级

Sentinel
单独一个组件，可以独立出来。
直接界面化的细粒度统一配置。

启动Sentinel8080 -
java -jar sentinel-dashboard-1.7.0.jar

Sentinel流控规则简介

image.png

资源名：唯一名称，默认请求路径。

针对来源：Sentinel可以针对调用者进行限流，填写微服务名，默认default（不区分来源）。

阈值类型/单机阈值：
QPS(每秒钟的请求数量)︰当调用该API的QPS达到阈值的时候，进行限流。

线程数：当调用该API的线程数达到阈值的时候，进行限流。

是否集群：不需要集群。

流控模式：
直接：API达到限流条件时，直接限流。
关联：当关联的资源达到阈值时，就限流自己。
链路：只记录指定链路上的流量（指定资源从入口资源进来的流量，如果达到阈值，就进行限流)【API级别的针对来源】。

流控效果：
快速失败：直接失败，抛异常。

Warm up：根据Code Factor（冷加载因子，默认3）的值，从阈值/codeFactor，经过预热时长，才达到设置的QPS阈值。

排队等待：匀速排队，让请求以匀速的速度通过，阈值类型必须设置为QPS，否则无效。

Sentinel降级简介

image.png

RT（平均响应时间，秒级）
平均响应时间 超出阈值 且 在时间窗口内通过的请求>=5，两个条件同时满足后触发降级。
窗口期过后关闭断路器。
RT最大4900（更大的需要通过-Dcsp.sentinel.statistic.max.rt=XXXX才能生效）。

异常比列（秒级）
QPS >= 5且异常比例（秒级统计）超过阈值时，触发降级;时间窗口结束后，关闭降级。

异常数(分钟级)
异常数(分钟统计）超过阈值时，触发降级;时间窗口结束后，关闭降级

Sentinel熔断降级会在调用链路中某个资源出现不稳定状态时（例如调用超时或异常比例升高)，对这个资源的调用进行限制，让请求快速失败，避免影响到其它的资源而导致级联错误。

当资源被降级后，在接下来的降级时间窗口之内，对该资源的调用都自动熔断（默认行为是抛出 DegradeException）。

Sentinei的断路器是没有类似Hystrix半开状态的

Sentinel热点key

image.png

何为热点？热点即经常访问的数据。很多时候我们希望统计某个热点数据中访问频次最高的 Top K 数据，并对其访问进行限制。比如：

• 商品 ID 为参数，统计一段时间内最常购买的商品 ID 并进行限制

• 用户 ID 为参数，针对一段时间内频繁访问的用户 ID 进行限制
  热点参数限流会统计传入参数中的热点参数，并根据配置的限流阈值与模式，对包含热点参数的资源调用进行限流。

  
  
  image.png

方法testHotKey里面第一个参数只要QPS超过每秒1次，马上降级处理
@SentinelResource(value = "testHotKey", blockHandler = "dealHandler_testHotKey")

参数例外项

普通 - 超过1秒钟一个后，达到阈值1后马上被限流
我们期望p1参数当它是某个特殊值时，它的限流值和平时不一样

image.png

Sentinel系统规则

系统规则

系统保护规则是从应用级别的入口流量进行控制，从单台机器的 load、CPU 使用率、平均 RT、入口 QPS 和并发线程数等几个维度监控应用指标，让系统尽可能跑在最大吞吐量的同时保证系统整体的稳定性。

系统保护规则是应用整体维度的，而不是资源维度的，并且仅对入口流量生效。入口流量指的是进入应用的流量（EntryType.IN），比如 Web 服务或 Dubbo 服务端接收的请求，都属于入口流量。

Sentinel服务熔断只配置fallback

fallback只负责业务异常

Sentinel服务熔断只配置blockHandler

blockHandler只负责sentinel控制台配置违规

Sentinel服务熔断fallback和blockHandler都配置

若blockHandler和fallback 都进行了配置，则被限流降级而抛出BlockException时只会进入blockHandler处理逻辑。

Sentinel服务熔断exceptionsToIgnore

exceptionsToIgnore，忽略指定异常，即这些异常不用兜底方法处理。
@SentinelResource(value = "fallback",fallback = "handlerFallback",blockHandler = "blockHandler",
exceptionsToIgnore = {IllegalArgumentException.class})

Sentinel服务熔断OpenFeign

---

业务类

带@Feignclient注解的业务接口，fallback = PaymentFallbackService.class

熔断框架比较

image.png

Sentinel持久化规则

---

将限流配置规则持久化进Nacos保存，只要刷新8401某个rest地址，sentinel控制台的流控规则就能看到，只要Nacos里面的配置不删除，针对8401上sentinel上的流控规则持续有效。

添加Nacos业务规则配置
添加JSON格式的配置内容：

[{
    "resource": "/rateLimit/byUrl",
    "IimitApp": "default",
    "grade": 1,
    "count": 1, 
    "strategy": 0,
    "controlBehavior": 0,
    "clusterMode": false
}]

resource：资源名称；
limitApp：来源应用；
grade：阈值类型，0表示线程数, 1表示QPS；
count：单机阈值；
strategy：流控模式，0表示直接，1表示关联，2表示链路；
controlBehavior：流控效果，0表示快速失败，1表示Warm Up，2表示排队等待；
clusterMode：是否集群。

分布式事务问题由来

---

单体应用被拆分成微服务应用，原来的三个模块被拆分成三个独立的应用,分别使用三个独立的数据源，业务操作需要调用三三 个服务来完成。此时每个服务内部的数据一致性由本地事务来保证， 但是全局的数据一致性问题没法保证。

一句话：一次业务操作需要跨多个数据源或需要跨多个系统进行远程调用，就会产生分布式事务问题。

Seata术语

---

Seata是一款开源的分布式事务解决方案，致力于在微服务架构下提供高性能和简单易用的分布式事务服务。

一个典型的分布式事务过程

分布式事务处理过程的一ID+三组件模型：

Transaction ID XID 全局唯一的事务ID

三组件概念
TC (Transaction Coordinator) - 事务协调者：维护全局和分支事务的状态，驱动全局事务提交或回滚。
TM (Transaction Manager) - 事务管理器：定义全局事务的范围：开始全局事务、提交或回滚全局事务。
RM (Resource Manager) - 资源管理器：管理分支事务处理的资源，与TC交谈以注册分支事务和报告分支事务的状态，并驱动分支事务提交或回滚。

处理过程：
TM向TC申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的XID；
XID在微服务调用链路的上下文中传播；
RM向TC注册分支事务，将其纳入XID对应全局事务的管辖；
TM向TC发起针对XID的全局提交或回滚决议；
TC调度XID下管辖的全部分支事务完成提交或回滚请求。

image.png

本地@Transactional

全局@GlobalTransactional

Seata之原理简介

---

AT模式如何做到对业务的无侵入

前提
基于支持本地 ACID 事务的关系型数据库。
Java 应用，通过 JDBC 访问数据库。

整体机制
两阶段提交协议的演变：
一阶段：业务数据和回滚日志记录在同一个本地事务中提交，释放本地锁和连接资源。
二阶段：
提交异步化，非常快速地完成。
回滚通过一阶段的回滚日志进行反向补偿。