SpringBoot 框架相关 微服务相关

Spring-是一个框架，核心技术IOC、AOP实现解耦和

• IOC控制反转:

• 指导开发人员在容器中，代码之管理对象，给属性赋值，管理依赖。
• IOC技术实现使用的DI(依赖注入)：开发人员在项目中只需要提供对象的名称，对象的创建，查找，赋值都是由容器内部自己实现的。
• Spring使用的DI技术，底层使用的就是反射机制。

• AOP面向切面编程-底层是动态代理

• 作用：

  • 在目标类不能修改代码的情况下，增加功能
  • 减少重复代码、专注业务功能的实现
  • 解耦合：业务功能和日志，事务这些非业务功能的耦合

• JDK动态代理

  • 使用jdk反射包中的类实现创建代理对象的功能
  • 目标类必须实现接口

• CGLIB代理

  • 使用第三方的工具库，实现代理对象的创建
  • 要求：目标类必须能够继承，不能是final
  • 继承，子类是代理

• SpringMVC执行流程

• 1. 请求发送给前端控制器（DispatcherServlet)
• 2. 前端控制器委托给相应的页面控制器（XXController）
• 3. 页面控制器调用模型层（service dao)
• 4. 模型层处理完成后返回数据给页面控制器
• 5. 页面控制器返回ModelAndView给前端控制器（DispatcherServlet)
• 6. 前端控制器定位相应的视图并渲染（将数据代入到视图中，填充视图） ==> ViewResolver
• 7. 渲染结果返回给前端控制器
• 8. 前端控制器响应结果给用户

• SpringBoot 的启动机制
  SpringBoot启动类中有3个注解
  SpringBootConfiguration：声明是一个springBoot配置类、
  EnableAutoConfiguration：开启自动配置类、
  ComponentScan：组件扫描

spring-boot 应用启动时，扫描所有的包，在META-INF下找spring.factories, 定位到自动配置类，自动配置类读取application.properties, 自动配置所需要的spring bean。

SpringBoot启动类中有一个SpringApplication.run的静态方法。

1. 执行核心refreshContext方法，用来刷新容器，读取配置文件，解释注解；
2. EnableAutoConfiguration中的Import注解引入了AutoConfigurationImportSelector.class这个类；
3. 通过这个类中的SpringFactoriesLoader加载/META/INFO/spring.factories配置文件对应的bean加入到spring容器中，完成自动装配。

• 消息中间件

1. 利用可靠的消息的消息传递机制、进行系统和系统之间的通讯
2. 通过提供消息传递和消息的排队机制、可以在分布式系统环境下扩展进程间的通讯

• SpringMVC配置原理

1. 由客户端发送请求到dispatcherServlet
2. 然后通过dispatcherServlet控制器分配对应的handlerMapping，找到处理请求对应的controller
3. Controller调用业务逻辑处理之后返回ModelAndView
4. DispatcherServlet将返回的modelAndView找到对应的viewResoler视图解析器进行解析，
5. 并将解析后的结果返回给客户端

• Redis分布式锁-执行Reddssion

1. 在高并发的情况下、可以生产唯一ID作为值，用key和value来判断，从而释放锁
2. 先用setnx来争抢锁，抢到之后，用expire给锁加过期时间，防止锁忘记释放
3. 如在setnx之后执行erpire之前进程意外终止的，锁得不到释放的话，可以将setnx和expire合成一条命令执行；

SpringCloud

概念：对一个大服务的拆分，每个服务运行其独立的进程，服务直接相互交互，独立部署，各自服务的技术自由可自由选择。
将应用分解后，每个微服务专注单一的功能，通过定义良好的接口清晰表述服务边界，由于体积小，复杂度低，易于维护以及扩展，提高开发效率。

• Feign 服务调用

• 是一个声明式的Web Service客户端，它的目的就是让Web Service调用更加简单。Feign提供了HTTP请求的模板
• 通过编写简单的接口和插入注解，就可以定义好HTTP请求的参数、格式、地址等信息。

• Gateway 网关

• 这是spring cloud提供的第二代网关，基于webflux以及reactor编程。以前的web模式的方式不能集成进来。主要用来集中处理请求，路由各个服务。
• springMVC提供了CorsFilter-CrossOrigin

• Sentinel 服务治理

• Sentinel 是面向分布式服务架构的流量控制组件，主要以流量为切入点，从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。
• Sentinel以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。

• Nacos Discovery 服务注册与发现

• Nacos Discovery 可以让你将服务自动注册到 Nacos 服务端并且能够动态感知和刷新某个服务实例的服务列表。
• 适配 Spring Cloud 服务注册与发现标准，默认集成了 Ribbon 。存放整个微服务的url地址的信息，能够实现动态感知。

• 客户端负载均衡器Ribbon

• 从注册中心上获取调用地址列表，本地实现负载均衡算法，获取接口地址列表，采用算法获取选择一个接口地址实现本地rpc远程调用。
• 负载均衡算法：一致性hash算法、轮训、权重、随机

RockerMQ-openMeassges协议（阿里、滴滴等）-支持消息持久化-以文件的方式存储
解耦、异步（处理数据更加高效）、削峰

RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。

消息队列协议（由于TCP/IP、UDP 的报文头、包含cookie、数据加密解密等功能比较复杂，大部分http请求都是短连接，在实际过程中一个请求到响应很有可能会中断，而消息中间件最主要的就是用来长期获取消息的过程，追求高性能，保证数据的可靠性就可以了）

概念：阿里开源的队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点，支持海量堆积，支持指定次数和时间间隔的失败消息重发，
支持consumer端tag过滤，延迟消息等。

• 如何避免消息重复消费?

• RocketMQ不保证消息不重复，如果需要保证严格的不重复消费，需要自己在业务端去重，接口幂等性保障，
• 消费端处理业务消息需要要吃幂等性可以用Redis、关系数据库等来配合验证消息是否被消费。

• 如何保证顺序？

• 生产者端，要保证在存储消息时，要保证放在同一队列，设置存放队列的hash值一致
• 消费者端，要保证是单线程，执行时从一个队列中取出进行消费
• 严格顺序消息模式下，消费者收到的所有消息均是有顺序的。

• RocketMQ如何保证消息的可靠性传输？

• produce端-生产者：

  • 不采用一次性发送，使用同步或则异步方式发送，做好消息重试，但是重试的Message key必须要是唯一的。
  • 投递的日志需要保存：关键字段，投递时间，投递状态，重试次数，请求体，响应体。

• broker端-消息存储端

  • 双主双从架构，NamerServer需要多节点
  • 同步双写、异步刷盘(同步刷盘则可靠性更高，但是性能差点，根据业务选择)。

• consumer端-消费端

  • 消息消费必须要保留日志，消息的元数据和消息体做好幂等性处理。

• 消息发生大量堆积应该怎么处理(大量堆积在broker里面) 线上故障了，怎么处理？

• 临时topic队列扩容，并提高消费能力，
• 如果增加Consumer数量，堆积的topic里面的message queue数量固定，过多的consumer不能分配到message queue。
• 编写临时的处理分发程序，从旧topic快速读取到临时的新topic中，新topic的queue数量扩容多倍，然后再启动更多的consumer进行再临时的新的topic里消费

• 消息的高可用-集群模式

• 主从共享数据-数据丢失、无法恢复
• 主从同步-多个副本-消耗性能
• 多主集群同步（任意节点都可以写入）
• 多主集群转发-比如买票系统（元数据共享->存储数据的相关描述及记录存放的位置）====减少数据存储避免空间浪费

• 消息的高可靠-比如一个系统突然崩溃、报错异常、不影响线上的任务运行、出错率低；

• 消息的传输：通过协议保证系统间数据解析的正确性。
• 消息的可靠存储：通过持久化来保证消息的可靠性。