微服务架构SpringCloud alibaba笔记

前置技术设计点：java8、maven、github、Nginx、RabbitMq、Spring boot   等等。。

微服务架构是一种架构模式，它提倡将单一的应用程序划分成一组小的服务，服务之间互相协调，配合。

微服务需要完成下面技术：

服务注册发现     服务调用     服务熔断    负载均衡    服务降级

服务消息队列   配置中心管理    服务网关    服务监控   全链路追踪    自动化构建部署    服务定时任务调度操作

Spring Boot2.X版和Spring Cloud H版本

Spring Cloud alibaba

服务注册发现:Eureka,Zookeeper,Consul,Nacos.

服务调用：Ribbon,loadBalancer

服务调用2：Feign,OpenFeign

服务降级：Hsytrix,resillience4j, Sentinel

服务网关：Zuui,gateway

服务配置：Config,阿波罗，Nacos

服务总线：Bus  , Nacos

 

Nacos具有配置管理和服务发现两个关键功能

gateway是 spring Cloud生态系统中的网关了，目标是替代zuui

zuui单线程转发请求受限，所以目前不用了。

微服务的应用可以部署在不同地区，不同域名下。此时客户端想要请求到对应的服务，需要有统一的入口，进行统一管理。

解决统一介入，协议适配。黑白名单。解决跨域，解决身份认证

路由：ip,url，一组断言和一组过滤器组成，如果断言路由为True，说明匹配，

断言：匹配对应的url的请求。其实就是加入网关的URL服务 path地址

过滤器：针对一些URL过滤

客户端->geteway handler mapping ->gateway web handler -> filter-filter....->service -》原路返回。

eteway handler mapping ：映射确定与请求相匹配的路由

gateway web handler：网关web处理程序，通过指定的过滤器链将请求发送到我们实际的服务执行业务逻辑中。

路由规则：predicates

path:

spring.cloud.gateway.routes-id:  路由ID，唯一

spring.cloud.gateway.url:   目标url,路由到微服务地址

spring.cloud.gateway.predicates-Pathr=/prouct/**  

Query:

- Query=token   只要包含token的请求，就回进行路由

Method:

- Method=GET   匹配任意Get请求

Detetime

 -After=2021-05-02   到达该时间才会被路由

RemoteAddr=ip地址/0   匹配原唱地址请求。0表示子网掩码

Header=X-Request-Id,\d+     请求头带有X-Request-Id

 

动态路由：可以结合注册中心，将URL配置修改成动态的

将gateway服务注册进入注册中心，url=lb/product-service

spring.cloud.gateway.url:   微服务名

 

服务名称转发：   服务名称转发默认访问方式是   http:网关IP:端口/注册名称/对应资源

discovery:

   locator:

      enabled:true                            #开启基于服务发现的路由规则

         lower-case-service-id:true    #将服务名称转小写

 

网关过滤器

   filters:

自定义网关过滤器要实现两个接口：GatewayFilter,Ordered,

public class CusttomFilter imlentents GatewayFilter,Ordered{

public Mono<Void> filter(ServerMebExchange exchange,GatewayFilterChain chain){

//增加全局业务逻辑

return chan.filter(exchange) //继续执行

}

public int getOrder(){return 0;}

}

全局过滤器:自定义过滤器 需要实现两个接口：  GlobalFilter Ordered

方法和上面一样。只是继承接口不一样

为什么要限流：

用户增长过快

因为某个热点

竞争对象爬虫

恶意的请求

限流算法：计数器算法，漏铜算法，令牌桶算法

计数器算法：

     例如：1分钟内，限制访问量100次。

    缺点：59秒到1分01秒，可以瞬间进入200个请求。

漏铜算法：

   可以粗略的认为就是注水漏水的过程，往桶中心以任意速率流入水，以一定速率流出水，当水超过桶流出量

则丢弃，因为容量是不变的。

缺点：如果桶满了，请求会堆积，会对网关造成压力。后续的请求无法进入，则丢弃。

令牌桶算法：

是对漏铜算法的改进。

以一定的速度生成令牌。

判断桶是否满了，满了丢弃令牌，没满将生成的令牌放入。

请求过来以后-》去令牌桶里面拿令牌，拿到执行业务，没拿到丢弃，或缓存。

gateway默认是令牌桶算法。

如果项目中药使用限流，需要配合redis使用

使用需要配置限流顾虑器：RequestRateLimiter

redis-rete-limiter.replenishRate：1   #令牌生成速率

redis-rate-limiter.buretCapacity  #令牌容量

key0resolver:"#{@pathresoler}"    #使用SpEl表达式按名称引用Bean。pathresoler和注入的方法名一样，注入的对象是限流规则

URL限流，参数限流，IP限流

Sentienl整合限流

Sentienl是什么？ 

随着微服务的流行，服务和服务之间稳定性越来越慢，

Sentinel从流量控制，熔断降级.控制系统的稳定性。

流量控制：访问的服务的数量

熔断降级：所谓的熔断降级就是当检测到调用链路中某个资源出现不稳定的表现，列如请求响应时间长或异常比例升高的时候，

则对这个资源的调用进行限制，让请求快速失败，避免影响其他的资源而导致级联故障。

主要实现方案有三种：Hystrix、resillence4j、Sentienl

资源：它可以可以是程序中的任何资源。只要通过Sentienl API定义的代码。就是资源，能够被Sentienl保护起来

规则：围绕资源的实时状态设定的规则，可以包括流量控制，熔断降级规则以及系统保护原则，所有规则可以动态实时调整。

Sentienl优势：

友好的控制面板、实时监控、支持多种限流、支持多种降级模式、方便扩展开发、支持链路的关联

初体验：下载公网Demo.开通阿里云ahas控制台

在Sentienl可以使用代码编写流控

@RestController
public class TestController {
    @GetMapping("/hello")
    public String Hello() {

        //使用限流规则
        try(Entry entry=SphU.entry("hello")) {
            return "hello sentinel";//被保护的资源
        } catch (BlockException e) {
            e.printStackTrace();
            return "系统繁忙。请稍后";  //被降级的操作处理
        }
    }
    //定义限流规则 PostConstruct注解表示，当前类的构造函数执行完后，执行
    @PostConstruct
    public void initFlowRules(){
        //1、创建存放限流规则的集合
        List<FlowRule> rules=new ArrayList<>();
        //2、创建限流规则。
        FlowRule rule=new FlowRule();
        rule.setResource("hello");  //定义资源，表示Sentubml会对那个资源生效

        rule.setGrade(RuleConstant.FLOW_GRADE_QPS);//定义限流类型 QPS

        rule.setCount(2); //设置qps限流值，每秒能通过的请求个数

        //3、将限流规则存放到集合中
        rules.add(rule);
        //4、加载限流规则
        FlowRuleManager.loadRules(rules);
    }

也可以在介入的控制台设置限流规则

Sentinel 控制台 中-》流控规则-新增规则。

定义资源可以是异常包裹的方式，如上面代码。

也可以是返回布尔值的形式定义资源：

 @GetMapping("/boolean")
    public boolean Hello() {

        if (SphO.entry("Sentinel_Boolean")) {
            //被保护资源
            try {
                System.out.println("hello_Sentinel");
                return true;
            } finally {
                SphO.exit();//限流的出口
            }

        } else {
            //限流降级处理
            System.out.println("系统繁忙");
            return false;
        }

    }

Sentinel和Feign整合

在写Feign调用的过程中，可以在接口类上加入注解

@FeignClient(value="资源名",fallback=异常处理类.class)

异常处理类规则需要先写好。

Sentinel限流规则主要有两种

并发线程数：防止线程耗尽

QPS：当QPS超过某个阀值

controlBehavior:流量控制效果

     直接拒绝（默认）

     Warm Up （预热冷启动的方式，将请求数量缓慢增加） 

    排队等待（让请求匀速通过）

熔断降级：如果我们某个资源被降级了，那么在某个时间内一直无法访问，降级时间过了以后，才可以从新访问。

可以设置:RT  异常比例  异常数。

RT：秒级访问速度

异常比例：某个时间点，异常数量达到比例

异常数：到到一定的异常数量

Sentinel原理

主要功能设计理念：

流量控制：它用于调整网络包的发送数据。根据系统的处理能力对流量进行控制。

资源的调用关系，运行的指标，控制效果。

是让我们自由选择控制的角度，并且灵活组合，达到想要的效果。

熔断降级

除了流量控制以外，及时对调用链路中的不稳定因素进行熔断也是它的使命之一。

sentinel和hystrix的原则是一致的，当检测到调用链路中某个资源出现不稳定的表现，对这个资源进行限制，让请求快速失败。

hystrix通过线程隔离的方式。来对依赖进行了隔离。好处是资源彻底的隔离，缺点是增加线程切换成本。

还需要预先给各个资源线程池大小的分配。

sentinel有两种手段

通过并发线程数进行限制

通过响应时间对资源进行降级

系统负载保护：

同时提供系统维度的 自适应保护能力，防止雪崩，是系统防护中重要的一环

针对这种情况。让系统的入口流量和系统的负载达到一个平衡，保证系统在能力范围之内处理最多的请求。

sentinel的工作机制：

对主流框架提供适配或者显示的API，来定义需要保护的资源，

根据预设的规则，结合对资源的实时统计信息，对流量进行控制。同时，sentinel提供开放的接口，方便定制改变规则。

sentinel提供实时的监控系统，方便了解目前系统的状态