CGB2005 1009 SpringCloud08 springcloud demo完结 +springboot整合rabbitMQ

复习

zuul



9.35 早上 晚上回看 为什么zuul默认不启动重试 为什么feign默认不启用降级


上午开始

sleuth 链路跟踪

随着系统规模越来越大，微服务之间调用关系变得错综复杂，一条调用链路中可能调用多个微服务，任何一个微服务不可用都可能造整个调用过程失败

spring cloud sleuth 可以跟踪调用链路，分析链路中每个节点的执行情况

添加依赖 自我实现 2,3,4,11

启动顺序 必须按顺序

1.直连zipkin 2.通过rabbitMq服务器中转再连接

更推荐rabbitmq
一个是服务解耦 不知道实际服务器地址 第二个就是流量削峰

开启zipkin

自我实现

向eureka注册正确的ip地址

自我实现 不太熟悉链路跟踪和ip 有空回看

成型项目运行必看!!springcloud 顺序以及启动参数覆盖

开启虚拟机服务器 rabbitmq + 本机(window的)zipkin
现在用的就是配置中心 远程config 涛哥的gitee 非本地 需要config sp12项目拉取

--server.port=2001

配置好后 先启动 eureka注册中心(端口号XXX)-----config(yml)-----zuul(网关 拦截器 并分配给各服务)-----sp020304

在控制台查看链路跟踪日志
通过 zuul 网关，访问 order-service

http://localhost:3001/order-service/112233

四个微服务的控制台日志中，可以看到以下信息：
[服务id,请求id,span id,是否发送到zipkin]

请求id：请求到达第一个微服务时生成一个请求id，该id在调用链路中会一直向后面的微服务传递
span id：链路中每一步微服务调用，都生成一个新的id
[zuul,6c24c0a7a8e7281a,6c24c0a7a8e7281a,false]

[order-service,6c24c0a7a8e7281a,993f53408ab7b6e3,false]

[item-service,6c24c0a7a8e7281a,ce0c820204dbaae1,false]

[user-service,6c24c0a7a8e7281a,fdd1e177f72d667b,false]





如上图 链路跟踪初步完成

继续
深化 利用服务器

为什么要用rabbitmq

如果没有配置过 spring cloud bus，还需要添加 rabbitmq 依赖和连接信息

启动并访问服务，访问 zipkin 查看链路分析
http://localhost:3001/order-service/112233
刷新访问多次，链路跟踪数据中，默认只有 10% 会被收集到zipkin

访问 zipkin
http://localhost:9411/zipkin


对应刚刚的调用失败

http://localhost:3001/order-service/112233

启动服务，访问测试
启动服务

http://eureka1:2001

http://localhost:3001/item-service/35

http://localhost:3001/item-service/decreaseNumber
使用postman，POST发送以下格式数据：
[{“id”:1, “name”:“abc”, “number”:23},{“id”:2, “name”:“def”, “number”:11}]

http://localhost:3001/user-service/7

http://localhost:3001/user-service/7/score?score=100

http://localhost:3001/order-service/123abc

http://localhost:3001/order-service/

第一次没输入token 第二次输入了token



链路分析+zipkin服务器 如上图 完美实现

接下来

选择正确网卡的ip向eureka进行注册.

下午 RabbitMQ

主方法(提供队列)

提供者

消费者 springboot封装了

创建实例是由spring自动扫描处理 全自动 生产者则需要调用
继续

m2工作模式

主方法

提供者

消费者

晚上自己去查

自我实现

启动类(提供队列)

提供者

消费者 两个 负载均衡

ack模式

处理完消息,就会自动发送回执

交换机模式

启动类

提供者

消费者

自我实现 fanout 交换机模式

主启动类(这次是提供交换机了)

提供者

消费者

路由模式

与发布和订阅模式代码类似, 只是做以下三点调整:

使用 direct 交换机
队列和交换机绑定时, 设置绑定键
发送消息时, 指定路由键

主启动类

消费者

direct路由模式 自我实现

主启动类(定义交换机)

提供者

消费者

运行

主题模式

主题模式不过是具有特殊规则的路由模式, 代码与路由模式基本相同, 只做如下调整:

使用 topic 交换机
使用特殊的绑定键和路由键规则

主启动类

提供者

消费者

自我实现 topic交换机 自由度最高

主启动类

提供者

消费者

运行

线程相关的理解

工作模式作为示例 需求 一次请求后 一次立马相应接收


运行

重启

只能接收 消费者无法处理

多线程处理

起码2条线程以上去处理 每次都新建一条线程去处理?

@PostConstruct注解好多人以为是Spring提供的。其实是Java自己的注解。

Java中该注解的说明：@PostConstruct该注解被用来修饰一个非静态的void（）方法。被@PostConstruct修饰的方法会在服务器加载Servlet的时候运行，并且只会被服务器执行一次。PostConstruct在构造函数之后执行，init（）方法之前执行。

通常我们会是在Spring框架中使用到@PostConstruct注解 该注解的方法在整个Bean初始化中的执行顺序：

Constructor(构造方法) -> @Autowired(依赖注入) -> @PostConstruct(注释的方法)

 /*
       - springboot项目完整启动完成
       - 当前对象中需要注入的对象注入完成
        */
    @PostConstruct
    public void test() {
        // new Thread(new Runnable() {
        //     @Override
        //     public void run() {
        //         p.send();
        //     }
        // }).start();

        new Thread(() -> p.send()).start();
    }