面试笔记系列四之SpringBoot+SpringCloud+计算机网络基础知识点整理及常见面试题

容易上手，提升开发效率，为 Spring 开发提供一个更快、更广泛的入门体验。
开箱即用，约定优于配置，远离繁琐的配置。
提供了一系列大型项目通用的非业务性功能，例如：内嵌服务器、安全管理、运行数据监控、运行状况检查和外部化配置等。
没有代码生成，也不需要XML配置。
避免大量的 Maven 导入和各种版本冲突。

SpringBootApplication注解

SpringBootApplication继承了上面三个注解。SpringBootConfiguration，EnableAutoConfiguration，ComponentScan

1.SpringBootConfiguration

他继承了spring的configuration注解，那就是有一样的功能了，就是声明注解的此类为配置类，spring容器会在这里寻找bean配置初始化的参数

2.EnableAutoConfiguration 自动配置配置，猜测你要用做什么开发，如你在pom里面导入spring-boot-starter-web包，他对自动给你导入相应的web工程必备包，减去了自己导入包的麻烦

3.ComponentScan 可以配置注解扫描的包

Spring Boot 的启动流程

可以简单概括为以下几个步骤：

1. **创建 SpringApplication 实例：** Spring Boot 应用程序的启动入口是 `SpringApplication` 类，通常通过静态的 `run` 方法来启动应用程序。这个方法会创建一个 `SpringApplication` 实例，并传入主配置类（Main Application Class）以及启动参数。

2. **初始化 Spring 应用上下文（ApplicationContext）：** `SpringApplication` 类会加载主配置类（Main Application Class），并通过 Spring 的 `ApplicationContext` 接口创建应用程序上下文。初始化过程中会自动扫描并加载各个 Bean，进行 Bean 的实例化和依赖注入。

3. **执行 Spring Boot 自动配置（Auto-Configuration）：** Spring Boot 提供了自动配置功能，可以根据类路径下的依赖自动配置应用程序所需的 Bean。在初始化应用上下文时，Spring Boot 会根据约定或条件自动配置一些 Bean，简化了配置过程。

4. **执行用户自定义配置：** Spring Boot 会加载应用程序中的自定义配置，例如自定义的 Bean、配置文件等。用户可以通过在主配置类或其他配置类中添加 `@Configuration` 注解来定义自己的 Bean。

5. **执行 SpringApplication 中的运行方法：** 在应用程序上下文初始化完成后，`SpringApplication` 实例会执行其 `run` 方法，启动整个应用程序。这个方法会启动内嵌的 Web 服务器（如 Tomcat、Jetty 等），同时开始监听请求。

6. **启动 Web 服务器：** 如果应用程序是 Web 应用程序，Spring Boot 会启动内嵌的 Web 服务器，并将请求交由 Spring MVC 处理。这样，应用程序就可以处理用户的请求并返回相应内容。

总的来说，Spring Boot 的启动流程包括创建 SpringApplication 实例、初始化应用上下文、执行自动配置和用户自定义配置、执行运行方法以及启动 Web 服务器等步骤。通过自动配置和约定大于配置的原则，Spring Boot 简化了应用程序的开发和部署过程，能快速构建起一个生产级别的应用程序。

Spring Boot属性加载顺序

在Spring Boot中，属性的加载顺序可以根据不同的来源和优先级进行调整。以下是一般情况下属性加载的顺序：

命令行参数（Command Line Arguments）：通过在命令行中使用--key=value的参数形式传递属性值，可以覆盖其他来源中的属性值。
系统属性（System Properties）：可以通过在JVM启动参数中使用-Dkey=value的形式设置系统属性，同样可以覆盖其他来源中的属性值。
环境变量（Environment Variables）：系统环境变量中定义的属性，可以通过System.getenv()方法获取。Spring Boot会自动将环境变量转换成属性。
配置文件（Application Properties/YAML）：Spring Boot支持使用不同的配置文件格式，如.properties和.yaml/.yml文件。配置文件的属性值可以根据不同的配置文件进行覆盖。默认加载的配置文件是application.properties（或application.yml），还可以通过spring.config.name和spring.config.location来指定其他名称和位置的配置文件。
配置文件的Profile相关的属性：可以根据不同的Profile（如开发环境、测试环境、生产环境）来加载对应的属性文件，例如application-dev.properties。
在@Configuration注解修改的类中，通过@PropertySource注解定义的属性
默认属性（Default Properties）：Spring Boot提供了一些内置的默认属性，可以在项目中直接使用。

以上是一般情况下属性加载的顺序，但需要注意的是，并非所有的属性来源和优先级都适用于所有的情况，具体的属性加载顺序还可以根据项目的配置和需求进行自定义（顺序可以修改）。

springboot自动配置原理是什么？（*）

Spring Boot 实现自动配置的核心机制是通过条件化配置和自动扫描来实现。

在 Spring Boot 中，自动配置是通过 @EnableAutoConfiguration 注解来启用的。当应用启动时，@EnableAutoConfiguration 注解会触发自动配置的过程。

Spring Boot 会扫描 classpath 下的特定位置，寻找类路径下的 META-INF/spring.factories 文件，该文件列出了所有可用的自动配置类。Spring Boot 根据这些自动配置类的定义，选择并加载合适的自动配置类。

自动配置类通过 @Conditional 注解来进行条件化配置，根据特定的条件判断是否需要自动配置对应的功能。条件可以是类路径下是否存在特定的类、是否存在特定的 Bean、配置属性是否满足等等。这些条件可以基于 Spring 的 @Conditional 注解进行扩展，也可以自定义条件。

当满足自动配置条件时，自动配置类会配置相应的 Bean，并根据默认策略或自定义策略来进行配置。

可以通过自定义的方式扩展自动配置。通过创建和配置一个类，将其纳入到 Spring Boot 的自动配置机制中，从而在应用启动时自动应用该配置。

总结来说，Spring Boot 的自动配置是通过扫描 META-INF/spring.factories 文件，根据条件对自动配置类进行筛选和加载，并根据配置类的定义来实现自动配置。这种机制可以方便地减少开发者的配置工作，提供默认的配置，同时又允许根据需求进行自定义配置。

如何理解springboot中的starter？

使用spring+springmvc框架进行开发的时候，如果需要引入mybatis框架，那么需要在xml中定义需要的bean对象，这个过程很明显是很麻烦的，如果需要引入额外的其他组件，那么也需要进行复杂的配置，因此在springboot中引入了starter

starter就是一个jar包，写一个@Configuration的配置类，将这些bean定义在其中，然后再starter包的META-INF/spring.factories中写入配置类，那么springboot程序在启动的时候就会按照约定来加载该配置类

开发人员只需要将相应的starter包依赖进应用中，进行相关的属性配置，就可以进行代码开发，而不需要单独进行bean对象的配置

Starter提供了一种快速启动、轻量级的方式来引入和配置特定的功能或模块。

下面是对Spring Boot Starter的几个关键点进行进一步解释：

关注领域和功能：
- 每个Starter都关注于特定领域或功能，例如Web开发、数据库访问、消息队列等。
- Starter的命名通常基于该领域或功能的名称，例如"spring-boot-starter-web"、"spring-boot-starter-data-jpa"等。
自动配置：
- Starter提供了自动配置的能力，无需手动编写各种繁琐的配置项。
- Starter中包含了预定义的默认配置，可以根据类路径上存在的其他组件进行自动配置。
依赖管理：
- Starter还提供了对相关依赖的管理，以确保所需要的依赖项都能正确地引入到项目中。
- Starter中包含了推荐的依赖列表，当引入一个Starter时，相关的依赖项也会被自动引入。
可插拔性：
- Spring Boot提供了一种可插拔的机制，允许开发者通过引入或排除不同的Starter来定制应用程序的功能。
- 通过添加或删除Starter，可以非常方便地增加或减少应用程序所支持的功能。
快速启动和集成：
- 引入一个特定的Starter可以让应用程序快速启动并集成所需功能。
- Starter提供了一种简单而一致的方式来使用和配置功能，大大简化了开发流程。

总的来说，Spring Boot Starter是一种依赖管理和自动配置的机制，为开发人员提供了一种轻便、快速集成特定功能的方法，使得开发Spring Boot应用程序变得更加方便和高效。通过使用Starter，我们可以快速搭建一个具备所需功能的项目，而无需手动处理复杂的依赖和配置。

什么是嵌入式服务器，为什么使用嵌入式服务器？

在springboot框架中，大家应该发现了有一个内嵌的tomcat，在之前的开发流程中，每次写好代码之后必须要将项目部署到一个额外的web服务器中，只有这样才可以运行，这个明显要麻烦很多，而使用springboot的时候，你会发现在启动项目的时候可以直接按照java应用程序的方式来启动项目，不需要额外的环境支持，也不需要tomcat服务器，这是因为在springboot框架中内置了tomcat.jar，来通过main方法启动容器，达到一键开发部署的方式，不需要额外的任何其他操作。

微服务架构产生的原因

微服务架构基于SOA架构演变过来的

在传统的WebService架构中有如下问题:

依赖中心化服务发现机制
使用Soap通讯协议，通常使用XML格式来序列化通讯数据，xml格式非常喜欢重，比较占宽带传输。
服务化管理和治理设施不完善

微服务架构基本概念

微服务架构模式是从SOA架构模式演变过来，比SOA架构模式粒度更加精细，让专业的人去做专业的事情（专注），目的是提高效率，每个服务与服务之间互不影响，微服务架构中

每个服务必须独立部署、互不影响，微服务架构模式体现轻巧、轻量级、适合于互联网公司开发模式。

微服务架构倡导应用程序设计程多个独立、可配置、可运行和可微服务的子服务。

服务与服务通讯协议采用Http协议，使用restful风格API形式来进行通讯，数据交换格式轻量级json格式通讯，整个传输过程中，采用二进制，所以http协议可以跨语言平台，并且可以和其他不同的语言进行相互的通讯，所以很多开放平台都采用http协议接口。

微服务架构与SOA架构的不同

1.微服务架构基于 SOA架构演变过来，继承 SOA架构的优点，在微服务架构中去除 SOA 架构中的 ESB 企业服务总线，采用 http+json（restful）进行传输。

2.微服务架构比 SOA 架构粒度会更加精细，让专业的人去做专业的事情（专注），目的提高效率，每个服务于服务之间互不影响，微服务架构中，每个服务必须独立部署，微服务架构更加轻巧，轻量级。

3.SOA 架构中可能数据库存储会发生共享，微服务强调独每个服务都是单独数据库，保证每个服务于服务之间互不影响。

4.项目体现特征微服务架构比 SOA 架构更加适合与互联网公司敏捷开发、快速迭代版本，因为粒度非常精细。

微服务架构会产生那些问题

分布式事务解决方案(rabbitmq/rocketmq/lcn(已经淘汰)/ Seata)

分布式任务调度平台(XXL-Job、阿里Scheduler)

分布式日志采集系统ELJ+Kafka

分布式服务注册中心 eureka、Zookeeper、consule、nacos等。

分布式服务追踪与调用链Zipkin等。

为什么我们要使用SpringCloud

SpringCloud并不是rpc远程调用框架，而是一套全家桶的微服务解决框架，理念就是解决我们在微服务架构中遇到的任何问题。

SpringCloud第一代与第二代的区别

SpringCloud第一代：

SpringCloud Config 分布式配置中心

SpringCloud Netflix 核心组件

Eureka:服务治理

Hystrix:服务保护框架

Ribbon:客户端负载均衡器

Feign：基于ribbon和hystrix的声明式服务调用组件

Zuul: 网关组件,提供智能路由、访问过滤等功能。

SpringCloud第二代（自己研发）和优秀的组件组合：

Spring Cloud Gateway 网关

Spring Cloud Loadbalancer 客户端负载均衡器

Spring Cloud r4j(Resilience4J) 服务保护

Spring Cloud Alibaba Nacos 服务注册

Spring Cloud Alibaba Nacos 分布式配置中心

Spring Cloud Alibaba Sentinel服务保护

SpringCloud Alibaba Seata分布式事务解决框架

Alibaba Cloud OSS 阿里云存储

Alibaba Cloud SchedulerX 分布式任务调度平台

Alibaba Cloud SMS 分布式短信系统

为什么Alibaba要推出SpringCloud组件

目的就是为了对阿里云的产品实现扩展。

Springcloud

Springcloud核心组件有哪些？

服务注册与发现——Netflix Eureka、Nacos、Zookeeper

客户端负载均衡——Netflix Ribbon、SpringCloud LoadBalancer

服务熔断器——Netflix Hystrix、Alibaba Sentinel、Resilience4J

服务网关——Netflix Zuul、SpringCloud Gateway

服务接口调用——Netflix Feign、 Resttemplate、Openfeign

链路追踪——Netflix Sleuth、Skywalking、Pinpoint

聚合Hystrix监控数据——Netflix Turbine

监控中心---- SpringBoot Admin

配置中心——Spring Cloud Config 、Apollo、nacos

SOA架构和微服务架构的区别

首先SOA和微服务架构一个层面的东西，而对于ESB和微服务网关是一个层面的东西，一个谈到是架构风格和方法，一个谈的是实现工具或组件。

1.SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务，服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用。

2.微服务架构:其实和 SOA 架构类似，微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“业务需要彻底的组件化和服务化”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

SOA架构特点：

系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】

系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决的核心问题是【复用】

业务的服务化：站在企业的角度，把企业职能抽象成可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；“前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

主要区别：

微服务架构特点：

1.通过服务实现组件化

开发者不再需要协调其它服务部署对本服务的影响。

2.按业务能力来划分服务和开发团队

开发者可以自由选择开发技术，提供 API 服务

3.去中心化

每个微服务有自己私有的数据库持久化业务数据
每个微服务只能访问自己的数据库，而不能访问其它服务的数据库
某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。
数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

微服务架构原理是什么？

主要是面向SOA理念，更细小粒度服务的拆分，将功能分解到各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

注册中心的原理是什么？

服务启动后向注册中心注册，注册中心会将注册信息向其他Server进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用

注册中心要解决的问题

服务与服务之间URL地址管理

在我们的微服务架构通讯，服务之间依赖关系非常大，如果通过传统的方式管理我们服务的url地址的情况下，一旦地址发生变化的情况下，还需要人工修改rpc远程调用地址

在我们的微服务架构通讯，服务之间依赖关系非常大，每个服务的url管理地址非常复杂，所在这时候我们采用服务url治理技术，治理的技术可以实现对我们的整个实现动态服务着注册与发现、本地负载均衡、容错等。

注册中心的功能服务注册与发现服务治理

服务注册

服务续约

服务下线

服务获取

服务调用

失效剔除

自我保护

服务同步

配置中心的原理是什么？

在服务运行之前，将所需的配置信息从配置仓库拉取到本地服务，达到统一化配置管理的目的

配置中心是如何实现自动刷新的？

配置中心Server端承担起配置刷新的职责
提交配置触发post请求给server端的bus/refresh接口
server端接收到请求并发送给Spring Cloud Bus总线
Spring Cloud bus接到消息并通知给其它连接到总线的客户端
其它客户端接收到通知，请求Server端获取最新配置
全部客户端均获取到最新的配置

配置中心是如何保证数据安全的?

1.保证容器文件访问的安全性，即保证所有的网络资源请求都需要登录

2.将配置中心里所有配置文件中的密码进行加密，保证其密文性

3.开发环境禁止拉取生产环境的配置文件

用 Nacos、zookeeper和eureka做注册中心有什么区别?

Nacos、Eureka和Zookeeper都是服务注册中心，它们的主要功能是管理分布式系统中各个微服务实例的注册与发现。它们之间的主要区别在于：

1. 语言支持：Nacos是用Java语言开发的，Eureka是用Java语言开发的，Zookeeper则是用C语言开发的。

2. 功能特性：Nacos支持服务发现、配置管理、流量管理、DNS、动态DNS等多种特性，而Eureka只支持服务注册和发现功能，Zookeeper可以实现可靠的数据存储和协调。

3. 应用场景：Nacos适用于Kubernetes、Service Mesh、Spring Cloud等云原生场景，Eureka适用于Spring Cloud生态系统，Zookeeper适用于Hadoop分布式集群等大规模分布式系统场景。

4. CAP理论：Nacos支持使用Raft和Paxos来保证分布式一致性，可以实现CP（Consistency and Partition tolerance），也可以实现AP（Availability and Partition tolerance）。Eureka支持实现AP模型，而Zookeeper是CP模型。

5. 运行模式：Nacos和Eureka都支持自主部署和集群模式，而Zookeeper需要独立部署和启动集群。

总的来看，Nacos是一个全栈解决方案，支持服务发现、配置管理和流量管理等多个功能。Eureka专注于服务注册和发现，适用于Spring Cloud场景。Zookeeper则是一个通用的分布式数据存储和协调系统，适用于大规模分布式系统的场景。

Spring Cloud和Dubbo有哪些区别?

dubbo 是二进制传输，对象直接转成二进制，使用RPC通信。

SpringCloud是http 传输，同时使用http协议一般会使用JSON报文，json再转二进制，消耗会更大。

Dubbo只是实现了服务治理，而Spring Cloud下面有几十个子项目分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud 中的一个子集。

本地负载均衡器：

什么是本地负载均衡器：我们的消费者从我们的注册中心上获取接口调用地址列表，

本地实现负载均衡算法(轮训、随机、hash一致性、权重)等原理：获取接口地址列表，采用算法获取选择一个接口地址地址实现本地rpc远程调用。

Nacos支持Ap和Cp的切换，该如何选择呢？

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

如果需要在服务级别编辑或者存储配置信息，那么 CP 是必须，K8S服务和DNS服务则适用于CP模式。

CP模式下则支持注册持久化实例，此时则是以 Raft 协议为集群运行模式，该模式下注册实例之前必须先注册服务，如果服务不存在，则会返回错误。

模式切换代码

curl -X PUT '$NACOS_SERVER:8848/nacos/v1/ns/operator/switches?entry=serverMode&value=CP'
10、Nacos读取配置文件的有哪几种方案？
Data ID
方案：指定spring.profile.active和配置文件的DataID来使不同环境下读取不同的配置

Group
方案：通过Group实现环境区分

Namespace
方案：通过建立不同NameSpace来区分

什么是Spring Cloud Sentinel？

Sentinel 是面向分布式服务架构的流量控制组件，主要以流量为切入点，从流量控制、熔断降级、系统自适应保护等多个维度来帮助您保障微服务的稳定性。官方地址：https://github.com/alibaba/Sentinel/wiki/%E4%BB%8B%E7%BB%8D https://sentinelguard.io/zh-cn/docs/introduction.html

Sentinel 基本概念有哪些？

资源是 Sentinel 的关键概念。它可以是 Java 应用程序中的任何内容，例如，由应用程序提供的服务，或由应用程序调用的其它应用提供的服务，甚至可以是一段代码。在接下来的文档中，我们都会用资源来描述代码块。只要通过 Sentinel API 定义的代码，就是资源，能够被 Sentinel 保护起来。大部分情况下，可以使用方法签名，URL，甚至服务名称作为资源名来标示资源。

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

Sentinel有哪些优点？

丰富的适用场景：哨兵在阿里巴巴得到了广泛的应用，几乎覆盖了近10年双11（11.11）购物节的所有核心场景，比如需要限制突发流量的“秒杀”满足系统能力、消息削峰填谷、不依靠业务断路、流量控制等。

实时监控：Sentinel 还提供实时监控能力。可以实时查看单台机器的运行时信息，以及以下 500 个节点的集群运行时信息。

广泛的开源生态：Sentinel 提供与 Spring、Dubbo 和 gRPC 等常用框架和库的开箱即用集成。

多语言支持：Sentinel 为 Java、Go和C++提供了本机支持。

丰富的 SPI 扩展：Sentinel 提供简单易用的 SPI 扩展接口，可以让您快速自定义逻辑，例如自定义规则管理、适配数据源等。

Sentinel有哪几种流控模式？

直接（默认）：api达到限流条件，直接限流

关联：当关联的资料达到阈值时，就限流自己。当与A关联的资源B达到阈值后，就限流A

链路：链路流控模式指的是，当从某个接口过来的资源达到限流条件时，开启限流；它的功能有点类似于针对来源配置项，区别在于：针对来源是针对上级微服务，而链路流控是针对上级接口，也就是说它的粒度更细；

Sentinel有哪几种流控效果呢？

直接（默认的流控处理）:该方式是默认的流量控制方式，当QPS超过任意规则的阈值后，新的请求就会被立即拒绝，拒绝方式为抛出FlowException

预热(Warm Up)：阈值除以coldFactor(默认为3)，经过预热时长后才达到阈值，案例，阀值为10+预热时长设置5秒。系统初始化的阀值为10 3 约等于3,即阀值刚开始为3；然后过了5秒后阀值才慢慢升高恢复到10

排队等待：匀速器（RuleConstant.CONTROL_BEHAVIOR_RATE_LIMITER
）方式。这种方式严格控制了请求通过的间隔时间，也即是让请求以均匀的速度通过，对应的是漏桶算法

Sentinel 有哪些降级规则（熔断策略）？

慢调用比例 (SLOW_REQUEST_RATIO
)：选择以慢调用比例作为阈值，需要设置允许的慢调用 RT（即最大的响应时间），请求的响应时间大于该值则统计为慢调用。当单位统计时长（statIntervalMs
）内请求数目大于设置的最小请求数目，并且慢调用的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求响应时间小于设置的慢调用 RT 则结束熔断，若大于设置的慢调用 RT 则会再次被熔断。

异常比例 (ERROR_RATIO
)：当单位统计时长（statIntervalMs
）内请求数目大于设置的最小请求数目，并且异常的比例大于阈值，则接下来的熔断时长内请求会自动被熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。异常比率的阈值范围是 [0.0, 1.0]
，代表 0% - 100%。

异常数 (ERROR_COUNT
)：当单位统计时长内的异常数目超过阈值之后会自动进行熔断。经过熔断时长后熔断器会进入探测恢复状态（HALF-OPEN 状态），若接下来的一个请求成功完成（没有错误）则结束熔断，否则会再次被熔断。

分布式事务存在的问题？

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

什么是Spring Cloud Seata？

Seata 是一款开源的分布式事务解决方案，致力于提供高性能和简单易用的分布式事务服务。Seata 将为用户提供了 AT、TCC、SAGA 和 XA 事务模式，为用户打造一站式的分布式解决方案。

分布式事务的处理过程是怎样的？

分布式事务处理过程的唯一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 下管辖的全部分支事务完成提交或回滚请求。

Seata分布式事务框架实现原理？

Seata有三个组成部分：事务协调器

TC：协调者、事务管理器

TM：发起方、资源管理器

RM：参与方

Seata实现原理

1.TM（发起方）连接到我们的TC事务协调者，创建一个全局的事务的xid，保存到ThreadLoacl中；

2.TM（发起方）和RM(参与方)都被Seata的数据数据源实现代理，在原生的sql之前和之后保存原来和修改后日志到undo_log中，方便后期实现回滚。

3.TM（发起方）使feign客户端调用接口时候，在ThreadLoacl中获取xid，设置到请求头中； 4.RM(参与方)从请求中获取到该xid，设置到ThreadLoacl中，同时也会向seataserver注册该分支事务。

5.TM(发起方)将当前本地事务的结果，告诉给协调者TC，协调者TC在通知所有的分支是否回滚。 6. TM(发起方)如果调用接口成功之后抛出异常的情况下，告诉给协调者TC，协调者TC在通知所有的分支根据根据全局的xid和分支事务的id 查询分支数据源的undo_log日志表逆向生成sql语句实现回滚，同时删除对应的undo_log日志

7. TM(发起方)如果调用接口成功之后没有抛出任何的异常，告诉给协调者TC，协调者TC在通知所有的分支根据根据全局的xid和分支事务的id 查询分支数据源的删除对应的undo_log日志表

Ribbon负载均衡原理是什么?

Ribbon通过ILoadBalancer接口对外提供统一的选择服务器(Server)的功能，此接口会根据不同的负载均衡策略(IRule)选择合适的Server返回给使用者。
IRule是负载均衡策略的抽象，ILoadBalancer通过调用IRule的choose()方法返回Server
IPing用来检测Server是否可用，ILoadBalancer的实现类维护一个Timer每隔10s检测一次Server的可用状态
IClientConfig主要定义了用于初始化各种客户端和负载均衡器的配置信息，器实现类为DefaultClientConfigImpl

Ribbon使用

@LoadBalancer 放在客户端上

通过Spring Cloud Ribbon的封装，我们在微服务架构中使用客户端负载均衡调用非常简单，只需要如下两步：

    ▪️服务提供者只需要启动多个服务实例并注册到一个注册中心或是多个相关联的服务注册中心。

    ▪️服务消费者直接通过调用被@LoadBalanced注解修饰过的RestTemplate来实现面向服务的接口调用。

了解客户端负载均衡器中应具备的几种能力。

ServiceInstance choose(String serviceId) 根据传入的服务名serviceId，从负载均衡器中选择对应服务的实例

T execute(String serviceId, LoadBalancerRequest request) 使用从负载均衡器中挑选出的服务实例来执行请求内容

URI reconstructURI(ServiceInstance instance, URI original) 为系统构建一个合适的host:port形式的URI吗，在分布式系统中，我们使用逻辑上的服务名称作为host来构建URI（替代服务实例的host:port形式）进行请求，比如http://myservice/path/to/service。在该操作的定义中，ServiceInstance对象是带有host和port的具体服务实例，URI对象则是使用逻辑服务名定义为host的URI，而返回的URI则是通过ServiceInstance的服务实例详情拼接出的具体host:post形式的请求地址。

Ribbon实现的负载均衡自动化配置需要满足下面两个条件：

@ConditionalOnClass(RestTemplate.class) RestTemplate类必须存在于当前工程的环境中 @ConditionalOnBean(LoadBalancerClient.class) 在Spring的Bean工程中必须有LoadBalancerClient的实现Bean 在该自动化配置类中，主要做了下面三件事：

创建了一个LoadBalancerInterceptor的Bean，用于实现客户端发起请求时进行拦截，以实现客户端负载均衡创建了一个RestTemplateCustomizer的Bean，用于给RestTemplate增加LoadBalancerInterceptor拦截器维护了一个被@LoadBalanced注解修饰的List，并在这里进行初始化，通过调用RestTemplateCustomizer的实例来给需要客户端负载均衡的RestTemplate增加LoadBalancerInterceptor拦截器Spring Cloud Ribbon7种负载均衡策略

ribbon负载均衡分类

硬件负载均衡：F5，价格昂贵不考略在内服务端负载均衡：nginx、lvs 客户端负载均衡：

Nginx是属于服务器端的负载均衡，Ribbon是属于客户端的负载均衡

1、随机策略——RandomRule

2、轮询策略——RoundRobinRule 注：Ribbon默认策略

3、重试策略——RetryRule

在一个配置时间段内，当选择server不成功，则一直尝试选择一个可用的server

4、最低并发策略——BestAvailableRule

最优可用，判断最优其实用的是并发连接数。选择并发连接数较小的server发送请求。

5、可用过滤策略——AvailabilityFilteringRule 过滤掉那些因为一直连接失败的被标记为circuit tripped的后端server，并过滤掉那些高并发的的后端server（active connections 超过配置的阈值）

性能仅次于最低并发策略。

6、响应时间加权策略——WeightedResponseTimeRule 每隔30秒计算一次服务器响应时间，以响应时间作为权重，响应时间越短的服务器被选中的概率越大。

7、区域权衡策略——ZoneAvoidanceRule

Ribbon的负载均衡策略使用建议一般情况下，推荐使用最低并发策略，这个性能比默认的轮询策略高很多。

OpenFeign客户端

OpenFeign 是一个声明式的 HTTP 客户端，专门用于简化使用 RESTful API。它与 Spring Cloud 等微服务框架结合使用，提供了一种优雅的方式来定义、调用和管理 HTTP API。

### 主要特点和功能包括：

1. **声明式 API 定义**：使用 Java 接口和注解定义远程服务的 HTTP API，使得开发者可以专注于业务逻辑而非底层的 HTTP 请求和响应处理。

2. **集成了负载均衡**：与 Spring Cloud Ribbon 集成，能够在调用远程服务时实现负载均衡，分发请求到多个实例。

3. **支持多种编解码器**：支持常见的 JSON、XML 等数据格式的编解码器，可以方便地处理请求和响应数据。

4. **支持动态 URL 和查询参数**：能够在运行时动态地构建 URL 和查询参数，灵活地适应不同的请求需求。

5. **易于扩展和定制**：通过自定义注解、拦截器等方式，可以对 Feign 的行为进行扩展和定制，满足复杂的业务场景。

6. **与 Spring Cloud 整合**：作为 Spring Cloud 的一部分，与 Eureka、Consul 等服务注册与发现组件无缝集成，支持服务间的自动发现和调用。

### 使用场景：
- **微服务架构**：适合于基于微服务的应用，简化了服务之间的通信和调用。
- **RESTful API 的调用**：能够优雅地处理 RESTful 风格的 API，减少手动 HTTP 请求和响应的处理代码量。

总之，OpenFeign 提供了一种优雅而强大的方式来定义和调用 RESTful API，使得在复杂的分布式系统中，服务之间的通信变得更加简单和可靠。

当使用 OpenFeign 调用 RESTful API 时，通常需要定义一个接口来描述远程服务的 HTTP API，然后通过 Feign 客户端来调用这些接口方法。以下是一个简单的示例代码，展示如何使用 OpenFeign 发起 HTTP 请求：

假设我们有一个远程的 RESTful 服务，提供了一个获取用户信息的 API。

```java
import org.springframework.cloud.openfeign.FeignClient;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.PathVariable;

@FeignClient(name = "user-service", url = "http://localhost:8080") // 指定服务名和URL
public interface UserFeignClient {

@GetMapping("/users/{userId}") // 定义GET请求的路径
User getUserById(@PathVariable("userId") Long userId); // 定义方法，获取用户信息
}
```

在这个例子中：

- `@FeignClient` 注解用于指定 Feign 客户端的配置，包括服务名和基础 URL。`name` 属性定义了服务名，`url` 属性指定了服务的基础 URL。
- `@GetMapping` 注解用于定义 HTTP GET 请求的路径，这里是 `/users/{userId}`，其中 `{userId}` 是一个路径参数。
- `getUserById` 方法定义了远程服务的具体调用方法，使用了 `@PathVariable` 注解来绑定方法参数 `userId` 到路径上的 `{userId}`。

接下来，我们可以在其他 Spring 组件中直接注入 `UserFeignClient` 接口，并调用其定义的方法来发起 HTTP 请求，如下所示：

```java
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;

@Service
public class UserService {

private final UserFeignClient userFeignClient;

@Autowired
public UserService(UserFeignClient userFeignClient) {
this.userFeignClient = userFeignClient;
}

public User getUserById(Long userId) {
return userFeignClient.getUserById(userId);
}
}
```

在这个示例中，`UserService` 类通过构造函数注入 `UserFeignClient`，并在 `getUserById` 方法中调用了 `UserFeignClient` 接口定义的方法 `getUserById`。

通过上述方式，我们可以利用 OpenFeign 声明式地定义和调用远程服务的 HTTP API，而不需要手动编写大量的 HTTP 请求和响应处理代码，使得服务间的通信更加简单和可维护。

微服务熔断降级机制是什么?

微服务框架是许多服务互相调用的，要是不做任何保护的话，某一个服务挂了，就会引起连锁反应，导致别的服务也挂。Hystrix 是隔离、熔断以及降级的一个框架。如果调用某服务报错（或者挂了），就对该服务熔断，在 5 分钟内请求此服务直接就返回一个默认值，不需要每次都卡几秒，这个过程，就是所谓的熔断。但是熔断了之后就会少调用一个服务，此时需要做下标记，标记本来需要做什么业务，但是因为服务挂了，暂时没有做，等该服务恢复了，就可以手工处理这些业务。这个过程，就是所谓的降级。

什么是Hystrix？实现原理是什么?

Hystrix是一个延迟和容错库，旨在隔离对远程系统、服务和第三方库的访问点，停止级联故障，并在不可避免发生故障的复杂分布式系统中实现快速恢复。主要靠Spring的AOP实现

实现原理

正常情况下，断路器关闭，服务消费者正常请求微服务

一段事件内，失败率达到一定阈值，断路器将断开，此时不再请求服务提供者，而是只是快速失败的方法（断路方法）

断路器打开一段时间，自动进入“半开”状态，此时，断路器可允许一个请求方法服务提供者，如果请求调用成功，则关闭断路器，否则继续保持断路器打开状态。

断路器hystrix是保证了局部发生的错误，不会扩展到整个系统，从而保证系统的即使出现局部问题也不会造成系统雪崩

注册中心挂了，或者服务挂了，应该如何处理?

注册中心挂了，可以读取本地持久化里的配置

服务挂了应该配有服务监控中心感知到服务下线后可以通过配置的邮件通知相关人员排查问题。

说说你对RPC、RMI如何理解?

RPC 远程过程调用协议，通过网络从远程计算机上请求调用某种服务。

RMI:远程方法调用能够让在客户端Java虚拟机上的对象像调用本地对象一样调用服务端java 虚拟机中的对象上的方法。

什么是Dubbo？请简要介绍Dubbo框架。

- Dubbo是一种高性能的开源RPC框架，用于构建分布式服务框架。它提供了服务治理、负载均衡、容错处理等功能，帮助简化分布式应用开发。

Dubbo有哪些核心组件？请简要介绍各个组件的作用。

- Dubbo的核心组件包括：Provider（服务提供者）、Consumer（服务消费者）、Registry（服务注册中心）、Monitor（监控中心）、Container（服务容器）、Cluster（集群容错）、Protocol（通信协议）、Proxy（服务代理）等。

dubbo的核心的配置有哪些

Dubbo 是一个功能强大的分布式服务框架，其核心配置主要包括以下几个方面：

1. **Provider 配置（服务提供者）**：
- 服务接口定义、服务实现类
- 服务暴露的协议（如dubbo、rmi、hessian等）
- 服务的注册中心配置（如Zookeeper、Redis、Nacos等）
- 服务的负载均衡策略、集群容错策略
- 服务的线程池配置、超时时间、最大并发数等

2. **Consumer 配置（服务消费者）**：
- 引用的服务接口、服务版本、负载均衡策略、集群容错策略
- 服务的注册中心配置
- 服务的超时时间、重试次数、异步调用等

3. **Registry 配置（服务注册中心）**：
- 注册中心地址
- 注册中心类型（Zookeeper、Redis、Nacos等）
- 注册中心的连接超时时间、会话超时时间等

4. **Protocol 配置（通信协议）**：
- Dubbo 支持多种通信协议，如dubbo、rmi、http等
- 可配置协议的端口号、序列化方式、编解码器等

5. **Monitor 配置（监控中心）**：
- 监控中心的地址
- Dubbo 提供了监控中心用于监控服务的调用情况、性能指标等

6. **Cluster 配置（集群容错）**：
- 配置集群容错策略，如Failover、Failfast、Failback、Failsafe等

7. **Provider/Consumer 共享配置**：
- 共享的通用配置，如服务超时时间、重试次数、线程池、负载均衡等

以上是 Dubbo 的核心配置，通过正确配置这些方面，可以实现 Dubbo 服务提供者和消费者之间的通讯、服务注册与发现、负载均衡、集群容错等功能，从而构建稳定可靠的分布式系统。

Dubbo 的整体架构设计有哪些分层

Dubbo 的整体架构设计主要包括以下几个分层：

1. **服务接口层**：
- 该层定义了服务接口，包括服务的方法定义和参数类型。
- 服务提供者和消费者都通过该层来定义服务接口，实现服务的解耦。

2. **配置层**：
- 该层负责处理 Dubbo 的各种配置项，包括服务提供者和消费者的配置信息。
- 配置层可以通过 XML 配置文件或注解来配置各种参数，如注册中心地址、协议、超时时间等。

3. **服务代理层**：
- 该层负责生成服务代理对象，用于处理服务的远程调用和通信。
- 服务消费者通过代理层来调用远程服务，实现远程过程调用（RPC）。

4. **服务注册层**：
- 该层负责将服务提供者发布到注册中心，以便消费者可以发现和调用这些服务。
- 注册中心可以是 Zookeeper、Redis、Nacos 等，用于实现服务的注册与发现。

5. **集群层**：
- 该层负责处理集群容错机制，包括失败自动切换、快速失败、失败安全等策略。
- 集群层可以保证服务提供者出现故障时的自动切换和恢复，提高系统的可靠性。

6. **监控层**：
- 该层负责服务的监控和统计，包括服务的调用次数、响应时间、失败率等指标。
- 监控层可以通过监控中心实现对服务的监控和管理，帮助运维人员进行故障排查和性能优化。

以上是 Dubbo 的整体架构设计中的主要分层。每个分层都有不同的功能和责任，通过分层设计可以使 Dubbo 框架具有高内聚、低耦合的特性，方便扩展和维护。希望这些信息能帮助你更好地理解 Dubbo 的架构设计。如果有任何其他问题，请随时提出！

Dubbo中的负载均衡策略有哪些？请列举并简要解释。

- Dubbo中常见的负载均衡策略包括：Random（随机策略）、RoundRobin（轮询策略）、LeastActive（最小活跃数策略），一致性hash，加权等。这些策略用于在服务消费者调用服务提供者时进行负载均衡，以提高系统性能和稳定性。

Dubbo中的服务注册中心有什么作用？常见的注册中心有哪些？

- 服务注册中心用于管理服务提供者和消费者之间的注册与发现。常见的Dubbo注册中心包括Zookeeper、Redis、Nacos等。它们可以帮助服务提供者注册自己的服务，并使消费者能够动态地发现和调用这些服务。

Dubbo中的服务治理是什么？如何实现服务治理？

- 服务治理是指对分布式系统中的服务进行管理和控制，包括服务注册、发现、路由、负载均衡、容错处理等。在Dubbo中，通过使用注册中心、集群容错、负载均衡等功能，可以实现服务治理，以确保服务的可用性、性能和稳定性。

这些是一些Dubbo常见的面试题及其解答，希望能帮助你更好地准备面试。如果有任何其他问题，欢迎继续提问！

Dubbo中的服务提供者和消费者是如何通信的？

- 在Dubbo中，服务提供者和消费者之间的通信通过远程过程调用（RPC）实现。服务提供者将自己提供的服务注册到注册中心，而消费者从注册中心获取服务提供者的地址，然后通过通信框架进行调用。

Dubbo的集群容错机制有哪些？请简要描述它们的作用。

- Dubbo中的集群容错机制包括：Failover（失败自动切换）、Failfast（快速失败）、Failsafe（失败安全）、Failback（失败自动恢复）等。这些机制用于处理服务提供者发生故障或异常时的情况，以保证系统的稳定性和可靠性。

Dubbo 提供了多种集群容错方案，用于处理服务提供者的故障或异常情况，保证系统的稳定性和可靠性。以下是 Dubbo 中常见的几种集群容错方案：

1. **Failover 失败自动切换**：默认的集群容错方案。当调用失败时，Dubbo 会自动切换到另一个可用的服务提供者进行重试，直至调用成功或达到最大重试次数。

2. **Failfast 快速失败**：快速失败策略，一旦调用失败立即抛出异常，快速返回结果。适用于对实时性要求较高的场景。

3. **Failback 失败自动恢复**：记录失败请求，定时重发。适用于后台任务处理场景，不适用于高实时性要求的场景。

4. **Failsafe 失败安全**：忽略失败的调用，直接返回空结果，适用于读操作，对于写操作可能会造成数据不一致。

这些集群容错方案可以根据业务场景的不同选择合适的方式来处理服务提供者的故障，保障系统的稳定性。在配置 Dubbo 时，可以根据实际需求选择适合的集群容错方案来提高系统的可靠性。

Dubbo中如何配置服务提供者和消费者？

- 在Dubbo中，可以通过XML配置文件或注解来配置服务提供者和消费者的相关信息，包括服务的接口、实现类、注册中心地址、负载均衡策略、集群容错策略等。这些配置项可以帮助Dubbo框架正确地管理和调度服务。

Dubbo与Spring Cloud相比有什么优缺点？

- Dubbo是一种基于RPC的轻量级框架，适合构建高性能、低延迟的分布式系统。而Spring Cloud是基于RESTful的微服务框架，更加适合构建弹性、面向HTTP的微服务架构。Dubbo在性能和扩展性方面具有优势，但相对而言，Spring Cloud更加易于上手并与Spring框架集成更好。

Dubbo服务的注册流程

Dubbo 服务的注册流程涉及到服务提供者将自己的服务注册到注册中心，以便消费者可以发现并调用这些服务。以下是 Dubbo 服务的注册流程的基本步骤：

1. **服务提供者启动**：
- 首先，服务提供者启动，并加载相应的 Dubbo 配置，包括注册中心地址、服务接口定义、服务实现类等。

2. **服务提供者将服务注册到注册中心**：
- 服务提供者将自己提供的服务信息注册到指定的注册中心，通常是 Zookeeper、Redis、Nacos 等。
- 注册中心会保存服务提供者的信息，包括服务接口、IP 地址、端口号等。

3. **消费者启动**：
- 接着，服务消费者启动，并同样加载 Dubbo 配置，包括注册中心地址、要消费的服务接口等。

4. **消费者从注册中心订阅服务**：
- 消费者向注册中心订阅自己需要的服务，注册中心会返回服务提供者的信息给消费者。
- 消费者根据服务提供者信息建立连接，准备发起远程调用。

5. **消费者发起远程调用**：
- 当消费者需要调用某个服务时，Dubbo会动态生成代理对象，通过代理对象来进行远程调用。
- 远程调用的过程中，Dubbo会处理网络通信、序列化、反序列化等细节，将调用请求发送给服务提供者。

6. **服务提供者响应调用**：
- 服务提供者接收到调用请求后，执行相应的服务逻辑，然后将结果返回给消费者。
- 结果经过网络传输到消费者端，Dubbo框架进行反序列化处理，将结果反馈给消费者。

通过以上流程，Dubbo 实现了服务提供者和消费者之间的注册与发现，实现了分布式系统中不同节点之间的远程通信。这种注册流程保证了服务提供者和消费者之间的解耦，并提供了动态的服务发现和调用机制。希望以上步骤可以帮助你更好地理解 Dubbo 服务的注册流程。若有任何问题，欢迎继续提问。

Dubbo服务暴露过程

Dubbo 服务的暴露过程指的是服务提供者将自己的服务接口暴露出去，以便消费者可以通过 Dubbo 协议进行远程调用的过程。以下是 Dubbo 服务的暴露过程的基本步骤：

1. **服务提供者配置**：
- 首先，服务提供者需要配置好服务接口、具体实现类、注册中心地址、通信协议等信息。

2. **服务提供者启动**：
- 服务提供者启动时，Dubbo 框架会加载提供的服务接口和实现类，并根据配置信息进行初始化。

3. **服务注册与暴露**：
- Dubbo 会将服务提供者的信息注册到指定的注册中心，这里包括服务接口、IP 地址、端口号等。
- 同时，Dubbo 会根据配置使用相应的协议（如Dubbo协议、HTTP、RMI等）将服务接口暴露出去，供消费者调用。

4. **服务监听端口**：
- Dubbo 会在服务提供者的服务器上监听指定的端口，等待消费者的调用请求。

5. **服务发布**：
- 一旦服务提供者成功启动并将服务暴露出去，消费者就可以通过 Dubbo 协议与服务提供者进行通信和远程调用。

6. **消费者调用服务**：
- 随后，消费者可以通过 Dubbo 框架生成服务接口的代理对象，并使用代理对象进行远程调用服务的方法。

7. **远程调用过程**：
- Dubbo 框架会通过网络将调用请求发送到服务提供者的服务器上，并在服务提供者端执行相应的服务逻辑。
- 服务提供者将调用结果返回给消费者，消费者端将结果反序列化后返回给调用方。

通过以上暴露过程，Dubbo 实现了服务提供者的服务接口在远程进行暴露，使得消费者可以方便地进行远程调用。Dubbo 提供了完整的服务暴露、注册和调用流程，帮助开发者构建分布式系统并实现服务之间的远程通信。希望以上步骤能帮助你更好地理解 Dubbo 服务的暴露过程。如有任何疑问，请随时提出。

Dubbo服务引入过程

Dubbo 服务引入过程指的是消费者引入并调用远程服务的过程。在 Dubbo 中，消费者需要引入提供者的服务接口，并通过 Dubbo 框架生成代理对象来实现远程调用。以下是 Dubbo 服务引入过程的基本步骤：

1. **消费者配置**：
- 首先，消费者需要配置好需要调用的服务接口、注册中心地址、通信协议等信息。

2. **消费者启动**：
- 消费者启动时，Dubbo 框架会加载消费者需要调用的服务接口，并根据配置信息进行初始化。

3. **从注册中心订阅服务**：
- 消费者向注册中心订阅自己需要调用的远程服务。注册中心会返回服务提供者的信息，包括服务接口、IP 地址、端口号等。

4. **生成服务代理对象**：
- Dubbo 框架会根据服务接口动态生成代理对象（Proxy），代理对象负责封装远程调用的细节，包括网络通信、序列化、反序列化等。

5. **远程调用服务**：
- 消费者通过生成的代理对象来调用远程服务的方法，实际上是通过 Dubbo 框架来进行远程调用。开发者可以像调用本地方法一样调用远程服务的方法。

6. **调用过程**：
- 代理对象将调用请求发送给服务提供者的服务器，服务提供者执行相应的服务逻辑，并将结果返回给消费者。
- Dubbo 框架会处理网络通信和数据传输细节，确保调用的可靠性和安全性。

通过以上引入过程，Dubbo 实现了消费者引入和调用远程服务的流程，使得消费者可以方便地远程调用服务提供者的方法。Dubbo 提供了完整的服务引入、代理生成、远程调用等功能，帮助开发者实现分布式系统中不同节点之间的远程通信。

Dubbo服务调用过程

Dubbo 服务调用过程是指消费者通过 Dubbo 框架调用远程服务的具体步骤。以下是 Dubbo 服务调用过程的基本流程：

1. **消费者引入服务**：
- 首先，消费者需要引入远程服务的接口定义，通常是在消费者项目中引入服务提供者定义的接口。

2. **生成代理对象**：
- 消费者通过 Dubbo 框架生成代理对象，代理对象是服务接口的本地代理，负责封装远程调用细节。

3. **发起远程调用**：
- 消费者通过代理对象调用远程服务的方法，就像调用本地方法一样，Dubbo 框架会负责将调用请求发送到远程服务提供者。

4. **网络通信**：
- Dubbo 框架处理网络通信细节，将调用请求通过网络发送到服务提供者的服务器。

5. **服务提供者处理请求**：
- 服务提供者接收到调用请求后，执行相应的服务逻辑，然后将结果返回给消费者。

6. **返回结果**：
- Dubbo 框架将调用结果从服务提供者处获取，并将结果返回给消费者端。

7. **结果处理**：
- 消费者端接收到结果后，Dubbo 框架负责处理结果的反序列化，并将结果返回给调用方。

通过上述过程，Dubbo框架实现了消费者调用远程服务的功能，封装了底层的网络通信和调用细节。Dubbo 提供了高性能的远程调用能力，使得分布式系统中不同节点之间的服务调用变得更加便捷和高效。希望以上信息能帮助您理解 Dubbo 服务调用过程。若有任何问题，欢迎随时提出。

计算机网络

四层负载均衡和七层负载均衡

网络七层模型

tcp/ip原理

TCP和UDP

Socket

常见的网络状态码

常见的网络状态码包括：

1. **1xx（信息性状态码）**：表示请求已被接受，继续处理。

2. **2xx（成功状态码）**：表示请求已成功被服务器接收、理解、并接受。

3. **3xx（重定向状态码）**：表示需要客户端采取进一步的操作才能完成请求。

4. **4xx（客户端错误状态码）**：表示客户端的请求有错误，例如请求地址不存在或请求参数错误。

5. **5xx（服务器错误状态码）**：表示服务器在处理请求时发生了错误。

常见的状态码包括：

- **200 OK**：请求成功。

- **301 Moved Permanently**：永久重定向，请求的资源已经被分配了新的 URL。

- **400 Bad Request**：客户端请求的语法错误。

- **401 Unauthorized**：请求要求用户的身份认证。

- **403 Forbidden**：服务器理解请求客户端的请求，但是拒绝执行此请求。

- **404 Not Found**：服务器无法找到请求的资源。

- **500 Internal Server Error**：服务器内部错误，无法完成请求。

- **503 Service Unavailable**：服务器当前无法处理请求，通常用于临时的维护或过载。

这些状态码是HTTP协议中定义的标准状态码，通过状态码可以快速了解请求的处理结果。

Nginx和网关相关

1 、网关的实现方式，如何重新网关鉴权？

微服务网关是整个微服务API请求的入口，可以实现日志拦截、权限控制、解决跨域问题、
限流、熔断、负载均衡、黑名单与白名单拦截、授权等。

使用已有的网关产品：
- Nginx 或 Apache HTTP Server：这些服务器可以通过配置实现基本的请求鉴权，如基于IP、Basic Auth、或OAuth2等。
- API Gateway框架：如Kong, Zuul, Spring Cloud Gateway等，这些框架通常提供内置的鉴权机制和插件支持，你可以配置或定制化鉴权逻辑。
自定义网关开发：
- 编写中间件：在你的网关处理逻辑中添加中间件（Middleware），检查每个请求的鉴权信息（如JWT Token, OAuth token等）。
- 集成认证服务：集成第三方认证服务（如Auth0, Okta等），在网关层进行身份验证和授权，确保请求经过认证。
实现步骤：
- 接收请求：网关接收客户端请求。
- 解析鉴权信息：解析请求中的鉴权信息（如HTTP头部中的Token）。
- 验证鉴权信息：验证该信息是否有效，通常需要调用认证服务或验证JWT Token等。
- 根据验证结果处理请求：
  - 如果鉴权成功，继续处理请求，转发到目标服务。
  - 如果鉴权失败，返回错误响应（如401 Unauthorized）。
示例代码：
- 在Java中，你可以使用Spring Cloud Gateway来实现鉴权功能。以下是一个简单的示例，展示如何在Spring Cloud Gateway中添加鉴权过滤器：

import org.springframework.cloud.gateway.filter.GatewayFilter;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

@Component
public class AuthFilter implements GatewayFilter {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String authHeader = exchange.getRequest().getHeaders().getFirst("Authorization");
        if (authHeader == null || !authHeader.startsWith("Bearer ")) {
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }
        
        // Here you would validate the token, e.g., call an authentication service
        String token = authHeader.substring(7); // remove "Bearer "
        if (isValidToken(token)) {
            return chain.filter(exchange);
        } else {
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }
    }

    private boolean isValidToken(String token) {
        // Implement your token validation logic here
        return true; // Replace with actual validation logic
    }
}

在此示例中，我们在网关层添加了一个简单的鉴权过滤器，检查请求头中的Authorization字段。

通过上述方式，你可以定制网关的鉴权逻辑，确保只有经过认证的请求可以访问后端服务。

2 、nginx如何代理，如何设置安全相关的？

Nginx可以通过配置文件来设置代理和安全相关的功能。以下是关于如何配置Nginx进行代理和增强安全性的基本指导：

代理配置

Nginx可以用作反向代理，将客户端的请求转发到后端的应用服务器上。例如，假设你希望将所有来自客户端的请求代理到后端服务器（如应用服务器或API服务器）上，可以按照以下步骤配置：

server {
    listen 80;
    server_name your_domain.com;

    location / {
        proxy_pass http://backend_server;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # Optional: Set additional headers or parameters as needed
        # proxy_set_header Authorization "Basic abc123";
    }
}

proxy_pass: 指定后端服务器的地址，可以是IP地址或域名。
proxy_set_header: 设置转发请求时的头部信息，如Host、X-Real-IP和X-Forwarded-For等。这些头部信息对于后端服务器识别客户端请求很有用。

安全相关设置

HTTPS配置

为了增强安全性，推荐使用HTTPS来加密传输中的数据。配置Nginx支持HTTPS通常需要以下步骤：

获取SSL证书：可以通过证书颁发机构（CA）获取有效的SSL证书。
配置Nginx使用SSL：修改Nginx配置文件以添加SSL支持。

示例配置：

server {
    listen 443 ssl;
    server_name your_domain.com;

    ssl_certificate /path/to/your_domain.crt;
    ssl_certificate_key /path/to/your_domain.key;

    location / {
        proxy_pass http://backend_server;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        
        # SSL related settings
        # Add additional settings as needed
    }
}

访问控制

Nginx可以配置访问控制规则，例如IP地址过滤、Basic认证等。

IP地址过滤示例：

server {
    listen 80;
    server_name your_domain.com;

    location / {
        allow 192.168.1.0/24;
        deny all;
        
        proxy_pass http://backend_server;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Basic认证示例：

server {
    listen 80;
    server_name your_domain.com;

    location / {
        auth_basic "Restricted Content";
        auth_basic_user_file /path/to/.htpasswd;
        
        proxy_pass http://backend_server;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

在上述示例中，auth_basic_user_file指定了用于Basic认证的密码文件，可以通过htpasswd工具生成。

总结

通过配置Nginx，你可以有效地设置反向代理和增强网站的安全性。这些配置不仅帮助你保护应用程序和数据，还能提升系统的性能和可靠性。根据具体需求，可以进一步调整和优化配置，以满足特定的安全需求和性能要求。

正向代理和反向代理

Nginx反向代理和正向代理是两种不同的代理服务器配置，它们的作用和使用场景有所不同。

1. **正向代理**：
- 在客户端和目标服务器之间充当中间人的服务器。
- 客户端向正向代理服务器发送请求，然后代理服务器将请求转发给目标服务器，并将目标服务器的响应返回给客户端。
- 客户端通常知道目标服务器的存在，但不能直接访问它，因此通过正向代理服务器进行间接访问。
- 常见的应用包括突破访问限制（如访问被封锁的网站）、隐藏客户端真实IP地址等。

2. **反向代理**：
- 在服务器端充当目标服务器的门面，接收客户端的请求并将其转发给后端的多个服务器。
- 客户端向反向代理服务器发送请求，而不知道实际处理请求的后端服务器。
- 反向代理服务器根据配置的负载均衡算法选择合适的后端服务器处理请求，并将处理结果返回给客户端。
- 常见的应用包括负载均衡、提供统一的入口点、安全保护后端服务器等。

区别总结：
- **方向不同**：正向代理代理客户端，而反向代理代理服务器端。
- **可见性**：对于正向代理，客户端知道要访问的目标服务器，但不直接访问；而对于反向代理，客户端只知道代理服务器，不知道实际处理请求的后端服务器。
- **应用场景**：正向代理用于隐藏客户端的真实IP地址、突破访问限制等；反向代理用于负载均衡、统一入口点、安全保护后端服务器等。

Nginx服务器

Nginx 是一个高性能的开源反向代理服务器，常用于处理 HTTP、HTTPS、SMTP、POP3 和 IMAP 协议的流量。它主要作用在于以下几个方面：

1. **反向代理**：接收客户端的请求，然后将请求转发给后端的多个服务器，从而分担服务器的负载，提高网站的性能和可靠性。

2. **负载均衡**：能够按照预定的算法（如轮询、IP hash等）将请求分发到多台服务器，从而实现负载均衡，确保各服务器的负载相对均衡。

43 **Web服务器**：能够直接处理静态内容的请求，例如 HTML 文件、图像文件等，提供基本的 Web 服务功能。

53 **缓存加速**：通过缓存静态内容或静态文件，减少后端服务器的负载，提高响应速度。

总之，Nginx 在现代 Web 架构中扮演了非常重要的角色，其高性能、高并发能力以及灵活的配置使其成为许多网站和应用的首选服务器软件之一。

RestfulHttp和RPC关系

互补

rpc不止通信一个功能，

http中有用信息占比较少，

rpc肯定比http

一、区别：

1、传输协议

RPC，可以基于TCP协议，也可以基于HTTP协议

HTTP，基于HTTP协议

2、传输效率

RPC，使⽤用⾃自定义的TCP协议，可以让请求报⽂文体积更更⼩小，或者使⽤用HTTP2协议，也可以很好的减少报⽂文的体积，提⾼高传输效率

HTTP，如果是基于HTTP1.1的协议，请求中会包含很多⽆无⽤用的内容，如果是基于HTTP2.0，那么简单的封装以下是可以作为⼀一个RPC来使⽤用的，这时标准RPC框架更更多的是服务治理理

3、性能消耗，主要在于序列列化和反序列列化的耗时

RPC，可以基于thrift实现⾼高效的⼆二进制传输

HTTP，⼤大部分是通过json来实现的，字节⼤大⼩小和序列列化耗时都⽐比thrift要更更消耗性能

4、负载均衡

RPC，基本都⾃自带了了负载均衡策略略

HTTP，需要配置Nginx，HAProxy来实现

5、服务治理（下游服务新增，重启，下线时如何不不影响上游调⽤用者）

RPC，能做到⾃自动通知，不不影响上游

HTTP，需要事先通知，修改Nginx/HAProxy配置

二、总结：

RPC主要⽤用于公司内部的服务调⽤用，性能消耗低，传输效率⾼高，服务治理理⽅方便便。HTTP主要⽤用于对外的异构环境，浏览器器接⼝口调⽤用，APP接⼝口调⽤用，第三⽅方接⼝口调⽤用等。

如何理解RPC

RPC（Remote Procedure Call 远程过程调用）是一种计算机通信协议，用于实现不同节点之间的远程通信。通过RPC，可以让一个程序调用另一个节点（通常是远程的）上的函数或方法，就像调用本地函数一样，而不必关心底层通信细节。

下面是对 RPC 的一些关键理解：

1. **远程调用**：RPC允许客户端程序调用远程服务器上的函数或方法，而无需了解底层网络通信细节。客户端代码调用远程方法时，RPC系统会处理网络通信、数据传输、序列化和反序列化等操作。

2. **封装性**：RPC封装了网络通信细节，使得客户端和服务器端的开发者可以将重点放在应用逻辑的实现上，而不必过多关注网络传输的细节。

3. **类似本地调用**：RPC让远程调用看起来就像本地方法调用一样，使得分布式系统编程更加直观和易用。

4. **序列化**：在RPC中，参数和返回值需要在客户端和服务器之间进行传输，通常需要进行序列化（将数据转换为字节流）和反序列化（将字节流转换为数据）操作。

5. **通信协议**：RPC系统使用特定的通信协议（如HTTP、TCP等）来在客户端和服务器之间传输数据，确保数据的可靠性和安全性。

6. **异步调用**：某些RPC系统支持异步调用，即客户端可以不必等待远程方法的执行完成，而是在后台进行其他处理，提高系统的并发性能。

总的来说，RPC是一种方便、高效的远程通信方式，使得分布式系统开发更加简单和直观。通过RPC，不同节点间的通信变得更加容易，并且能够得到类似本地调用的开发体验。希望以上解释对于理解RPC有所帮助。若有其他问题，请随时提出。

RPC和http协议的区别

RPC（Remote Procedure Call）和 HTTP（Hypertext Transfer Protocol）协议是常见的网络通信协议，它们之间有以下几个主要区别：

技术栈和用途：RPC 是一种远程调用协议，通常用于分布式系统中不同模块或服务之间的通信，以实现函数或方法的调用。RPC 的实现包括多种技术栈，如 gRPC、Thrift、Dubbo 等。而 HTTP 是一种应用层协议，主要用于 Web 浏览器和服务器之间的通信，支持传输超文本和其他资源。它是基于 RESTful 架构风格的主要通信协议。
通信方式：RPC 通常使用二进制的序列化格式进行数据传输，例如 Protocol Buffers、Apache Avro 等。这种二进制格式在数据传输效率和体积上有较大的优势。而 HTTP 通常使用文本格式进行数据传输，例如 JSON 或 XML。文本格式易于理解和调试，但相对而言数据体积较大，传输效率相对较低。
语义和扩展性：RPC 通常倾向于提供更加语义化和精细控制的通信方式。它可以直接调用远程服务上的函数或方法，并返回结果。RPC 支持对分布式系统的透明远程调用，使得调用方可以像调用本地函数一样调用远程服务。相比之下，HTTP 更加面向资源和状态转移。它使用标准的请求-响应模型，通过 HTTP 方法（GET、POST 等）对资源进行操作，并使用状态码表示请求状态。HTTP 具有更好的扩展性和灵活性。
生态系统：由于 RPC 和 HTTP 在应用场景上的差异，它们分别拥有自己的生态系统。RPC 生态系统通常包含与之配套的服务注册中心、服务发现、负载均衡等组件，以实现透明的服务调用。而 HTTP 生态系统更加注重于 Web 领域，有丰富的 Web 框架、工具和标准支持，如 Spring、Express、Swagger 等。

总之，RPC 和 HTTP 是两种不同的协议，用于不同的通信场景和目的。RPC 更加适合于分布式系统内部的函数调用和服务间通信，而 HTTP 则更适用于 Web 应用的请求和响应。选择合适的协议需要根据具体需求和系统设计进行评估。

http和https的区别

HTTP（Hypertext Transfer Protocol）和 HTTPS（Hypertext Transfer Protocol Secure）是 Web 上常见的两种通信协议，它们之间有几个主要的区别：

安全性: 最明显的区别在于安全性。HTTP 是一种明文传输协议，数据传输是未加密的，因此容易受到中间人攻击，信息可能会被窃听或篡改。而 HTTPS 则是在 HTTP 上加入了 SSL/TLS 加密层，通过使用公钥加密算法保证了数据在传输过程中的机密性和完整性，因此更加安全。
默认端口: HTTP 默认端口是80，而 HTTPS 默认端口是443。这是网络通信中的规范，用于区分不同的应用服务。
证书支持: HTTPS 使用了 SSL/TLS 加密协议，需要使用数字证书来验证服务器的身份。这种机制有效地防止了中间人攻击，用户可以通过数字证书来确认服务器的合法性，确保数据在传输过程中不会被篡改。而 HTTP 不需要使用证书验证。
网络抓包分析: 由于 HTTP 是明文传输，因此通过网络抓包工具（例如Wireshark）可以轻松查看数据内容，而 HTTPS 则由于加密的传输方式，使得抓包分析变得更为困难。

总体而言，HTTPS在安全性上明显优于HTTP，在涉及用户隐私和数据传输安全方面得到了更好的保护。因此，在对数据安全要求较高的网络通信场景中，推荐使用HTTPS协议。

https中的证书如何保证安全性的

HTTPS中的证书是通过基于公钥基础设施（PKI）体系的数字证书来保证通信的安全性。证书的发放和验证过程使用了非对称加密和数字签名等技术，具体保证安全性的方式包括：

身份验证：HTTPS证书用于验证服务器的身份。证书颁发机构（CA）对服务器的身份进行核实，并将其公钥绑定到数字证书上。客户端在建立连接时会收到服务器的证书，通过验证签发CA的数字签名和证书中的信息，确定服务器身份的合法性。
加密通信：证书中包含了公钥，客户端利用这个公钥与服务器进行通信加密。这样，即使通信被中间人截获，也无法获取有意义的数据。
完整性验证：证书中包含了数字签名，用于验证证书内容的完整性和真实性。如果证书内容在传输过程中被篡改，数字签名会失效，客户端可以通过验证数字签名来检验证书是否被篡改。
加密算法和密钥长度：证书的安全性也依赖于使用的加密算法和密钥长度。合适的加密算法和足够长的密钥长度是保证证书安全性的关键。

总体来说，HTTPS证书的有效性和安全性可追溯到信任的证书颁发机构（CA），通过CA的认证和数字签名的验证，能够确保服务器的身份和通信内容不受窃听、篡改以及伪装。因此，HTTPS证书系统为互联网通信提供了基本的安全保障。

浏览器发出一个请求到收到相应经历了哪些步骤

如何理解RPC

远程过程调用 RPC要求在调用方中放置被调用的方法的接口。调用方只要调用了这些接口，就相当于调用了被调用方的实际方法，十分易用。于是，调用方可以像调用内部接口一样调用远程的方法，而不用封装参数名和参数值等操作。

包含 1. 动态代理，封装调用细节

序列化与反序列化，数据传输与接收
通信，可以选择七层的http，四层的tcp/udp
1. 异常处理等
  
  首先，调用方调用的是接口，必须得为接口构造一个假的实现。显然，要使用动态代理。这样，调用方的调用就被动态代理接收到了。第二，动态代理接收到调用后，应该想办法调用远程的实际实现。这包括下面几步：识别具体要调用的远程方法的IP、端口将调用方法的入参进行序列化通过通信将请求发送到远程的方法中这样，远程的服务就接收到了调用方的请求。它应该：反序列化各个调用参数定位到实际要调用的方法，然后输入参数，执行方法按照调用的路径返回调用的结果

安全框架与权限相关

安全框架，简单说是对访问权限进行控制，应用的安全性包括用户认证（Authentication）和用户授权（Authorization）两个部分。

用户认证指的是验证某个用户是否为系统中的合法主体，也就是说用户能否访问该系统。

用户认证一般要求用户提供用户名和密码，系统通过校验用户名和密码来完成认证过程。

用户授权指的是验证某个用户是否有权限执行某个操作。在一个系统中，不同用户所具有的权限是不同的。比如对一个文件来说，有的用户只能进行读取，而有的用户可以进行修改。

一般来说，系统会为不同的用户分配不同的角色，而每个角色则对应一系列的权限。

Shiro

Apache Shiro是一个强大且易用的Java安全框架，能够非常清晰的处理身份验证、授权、管理会话以及密码加密。

利用其易于理解的API，可以快速、轻松地获得任何应用程序，从最小的移动应用程序到最大的网络和企业应用程序。

Shiro 主要分为两个部分就是认证和授权，在个人感觉来看就是查询数据库做相应的判断而已，Shiro只是一个框架而已，其中的内容需要自己的去构建，前后是自己的，中间是Shiro帮我们去搭建和配置好的。

Spring Security(SpringSecurityFilterChain

实现 WebSecurityConfigurer Adapter)

Spring Security是一个能够为基于Spring的企业应用系统提供声明式的安全访问控制解决方案的安全框架。

它提供了一组可以在Spring应用上下文中配置的Bean，充分利用了Spring IoC（控制反转），DI（依赖注入）和AOP（面向切面编程）功能，为应用系统提供声明式的安全访问控制功能，减少了为企业系统安全控制编写大量重复代码的工作。

众所周知，想要对对Web资源进行保护，最好的办法莫过于Filter，要想对方法调用进行保护，最好的办法莫过于AOP。所以Spring Security在我们进行用户认证以及授予权限的时候，通过各种各样的拦截器来控制权限的访问，从而实现安全。

它所有的架构也是基于认证和授权这两个核心功能去实现的。

OAuth2 协议

OAuth2 是一种开放标准的授权协议，用于授权第三方应用访问用户在另外一个服务上的资源，而无需将用户的凭据（比如用户名和密码）提供给第三方应用。OAuth2 协议为用户和资源拥有者提供了一种安全的授权机制，同时允许客户端应用访问受限的资源。

OAuth2 协议的核心角色包括以下几个：

1. **资源拥有者（Resource Owner）**：
资源拥有者是指拥有资源的用户。在 OAuth2 中，资源拥有者可以授权第三方应用访问其在资源服务器上受保护的资源。

2. **客户端（Client）**：
客户端是请求访问资源的第三方应用。它通常代表资源拥有者请求授权，并代表资源拥有者访问资源服务器。

3. **授权服务器（Authorization Server）**：
授权服务器负责验证资源拥有者的身份，以及颁发令牌（Token）给客户端应用。令牌用于代表资源拥有者访问资源服务器上的受保护资源。

4. **资源服务器（Resource Server）**：
资源服务器存储受保护的资源，并处理授权服务器颁发的令牌，以验证请求并返回受保护资源。

OAuth2 协议通常涉及以下几种授权方式：

- **授权码模式（Authorization Code Grant）**：用于通过服务器端应用获取访问令牌。
- **密码模式（Resource Owner Password Credentials Grant）**：资源拥有者提供用户名和密码获取访问令牌，通常用于受信任的客户端应用。
- **客户端凭证模式（Client Credentials Grant）**：客户端应用以自己的身份获取访问令牌，适用于客户端本身需要访问资源的情况。

OAuth2 的设计旨在提供一种安全的授权方式，使得用户和资源拥有者可以控制对其资源的访问权限，同时保护了用户的凭据不被第三方应用获取，提高了系统的安全性。OAuth2 协议广泛用于各种互联网服务和 API 访问的授权机制。

Shiro主要功能

三个核心组件：Subject, SecurityManager 和 Realms。

Subject：即“当前操作用户”。但是，在Shiro中，Subject这一概念并不仅仅指人，也可以是第三方进程、后台帐户（Daemon Account）或其他类似事物。它仅仅意味着“当前跟软件交互的东西”。

Subject代表了当前用户的安全操作，SecurityManager则管理所有用户的安全操作。

SecurityManager：它是Shiro框架的核心，典型的Facade模式，Shiro通过SecurityManager来管理内部组件实例，并通过它来提供安全管理的各种服务。

Realm：Realm充当了Shiro与应用安全数据间的“桥梁”或者“连接器”。也就是说，当对用户执行认证（登录）和授权（访问控制）验证时，Shiro会从应用配置的Realm中查找用户及其权限信息。

从这个意义上讲，Realm实质上是一个安全相关的DAO：它封装了数据源的连接细节，并在需要时将相关数据提供给Shiro。当配置Shiro时，你必须至少指定一个Realm，用于认证和（或）授权。配置多个Realm是可以的，但是至少需要一个。

Shiro内置了可以连接大量安全数据源（又名目录）的Realm，如LDAP、关系数据库（JDBC）、类似INI的文本配置资源以及属性文件等。如果缺省的Realm不能满足需求，你还可以插入代表自定义数据源的自己的Realm实现。

Spring Security主要功能

Spring Security对Web安全性的支持大量地依赖于Servlet过滤器。这些过滤器拦截进入请求，并且在应用程序处理该请求之前进行某些安全处理。

Spring Security提供有若干个过滤器，它们能够拦截Servlet请求，并将这些请求转给认证和访问决策管理器处理，从而增强安全性。根据自己的需要，可以使用适当的过滤器来保护自己的应用程序。

如果使用过Servlet过滤器且令其正常工作，就必须在Web应用程序的web.xml文件中使用<filter> 和<filter-mapping>元素配置它们。虽然这样做能起作用，但是它并不适用于使用依赖注入进行的配置。

FilterToBeanProxy是一个特殊的Servlet过滤器，它本身做的工作并不多，而是将自己的工作委托给Spring应用程序上下文中的一个Bean来完成。被委托的Bean几乎和其他的Servlet过滤器一样，实现javax.servlet.Filter接口，但它是在Spring配置文件而不是web.xml文件中配置的。

实际上，FilterToBeanProxy代理给的那个Bean可以是javax.servlet.Filter的任意实现。这可以是 Spring Security的任何一个过滤器，或者它可以是自己创建的一个过滤器。但是正如本书已经提到的那样，Spring Security要求至少配置四个而且可能一打或者更多的过滤器。

Shiro特点

1、易于理解的 Java Security API；

2、简单的身份认证（登录），支持多种数据源（LDAP，JDBC，Kerberos，ActiveDirectory 等）；

3、对角色的简单的签权（访问控制），支持细粒度的签权；

4、支持一级缓存，以提升应用程序的性能；

5、内置的基于 POJO 企业会话管理，适用于 Web 以及非 Web 的环境；

6、异构客户端会话访问；

7、非常简单的加密 API；

8、不跟任何的框架或者容器捆绑，可以独立运行。

shiro 三大组件

Apache Shiro 是一个强大且易用的 Java 安全框架，提供了身份验证、授权、加密和会话管理等功能。在 Shiro 中，有三大核心组件：

1. **Subject（主体）**：Subject 是指使用应用程序的用户或者系统，可以是一个人、一个第三方服务、一个后台任务等。Subject 可以是实际的用户，也可以是一个代表用户的虚拟实体。Subject 主要负责执行安全操作，如登录、注销、检查角色和权限等。

2. **SecurityManager（安全管理器）**：SecurityManager 是 Shiro 的核心组件，负责所有的安全操作。它管理着所有的 Subject，负责对 Subject 进行身份验证、授权、会话管理等操作。SecurityManager 是整个 Shiro 框架的核心，负责协调各个组件的工作。

3. **Realm（域）**：Realm 是 Shiro 用于验证用户身份和授权的组件。它是连接应用程序与安全数据（如用户、角色和权限）的桥梁。Realm 从数据源中获取安全数据，并将其提供给 Shiro 进行身份验证和授权。应用程序可以配置多个 Realm，用于支持不同的身份验证和授权策略。

这三个组件共同构成了 Shiro 的核心架构，通过它们的协作，可以实现灵活且强大的安全功能。

要在 Spring 框架中结合 Apache Shiro 实现一个基于 OAuth2 的权限系统，可以按照以下步骤进行：

### 步骤一：集成 Spring 和 Shiro
1. 在 Spring 项目中引入 Spring 和 Shiro 的相关依赖，并配置相应的配置文件。
2. 配置 Shiro 的安全管理器、Realm、Session 等组件。

### 步骤二：实现 OAuth2 认证和授权
1. 集成 Spring Security OAuth2 或其他 OAuth2 框架用于实现 OAuth2 认证和授权功能。
2. 配置 OAuth2 的相关参数，包括客户端信息、授权码模式、令牌存储等。

### 步骤三：定义用户、角色和权限模型
1. 设计用户、角色和权限的数据表结构，并在数据源中创建相应的表。
2. 编写对应的实体类和持久化层代码，用于操作用户、角色和权限数据。

### 步骤四：实现 Shiro 的 Realm
1. 定义自己的 Realm 类，继承自 Shiro 的 AuthorizingRealm。
2. 在 Realm 中重写 doGetAuthenticationInfo 和 doGetAuthorizationInfo 方法，用于认证和授权用户。

### 步骤五：配置 Shiro 拦截器和权限控制
1. 配置 Shiro 的过滤器链，定义拦截器和权限控制逻辑。
2. 基于用户的角色和权限信息，控制用户对不同资源的访问权限。

### 步骤六：前端界面和交互
1. 设计前端界面和交互，包括登录页、用户管理、角色管理、权限管理等功能。
2. 前端页面与后端服务进行交互，实现用户的认证和授权操作。

### 注意事项：
- 确保正确配置 Spring 和 Shiro 的相关组件，保证整个系统的安全性和稳定性。
- 涉及到的 OAuth2 和 Shiro 的配置参数需要仔细调试和测试，确保系统能够正常运行并且符合预期的权限控制逻辑。

以上是在 Spring 框架中结合 Apache Shiro 实现一个基于 OAuth2 的权限系统的一般步骤，具体的实现还需要根据具体需求和业务逻辑进行定制化开发。

shiro框架的filter，几种releam的区别

在 Apache Shiro 框架中，与认证和授权相关的功能由 Filter 和 Realm 来实现。下面简要介绍一下这两者的作用和区别：

### 1. Filter

Filters（过滤器）在 Apache Shiro 中负责处理 HTTP 请求，并执行认证（authentication）和授权（authorization）等操作。每个 Filter 都代表一个特定的功能，例如身份验证、授权、记住我等。常见的 Filter 包括：

在 Apache Shiro 框架中，有几个核心的 Filter 负责处理身份验证和授权操作，它们是：

1. **AuthenticationFilter**：
- 负责处理用户身份验证相关的操作。在用户登录时，该 Filter 被用来验证用户提交的用户名和密码，并将用户身份信息提交给 Realm 进行验证。

2. **AuthorizationFilter**：
- 负责处理用户授权相关的操作。在用户访问受保护资源时，该 Filter 用于验证用户是否具有足够的权限进行操作，通常是检查用户是否具有特定的角色或权限。

3. **RolesAuthorizationFilter**：
- 继承自 AuthorizationFilter，专门用于基于角色进行授权验证。通过配置角色名称，可以确保只有具有指定角色的用户才能访问受保护的资源。

4. **PermissionsAuthorizationFilter**：
- 继承自 AuthorizationFilter，专门用于基于权限进行授权验证。通过配置权限字符串，可以确保只有具有特定权限的用户才能执行特定的操作。

5. **LogoutFilter**：
- 负责处理用户退出登录操作。当用户请求退出时，该 Filter 清除用户的会话信息，使用户完全注销。

这些核心 Filter 可以根据具体的应用需求进行配置和组合，确保应用程序在处理身份验证和授权时的安全性和可靠性。通过合理配置 FilterChain，可以指定这些 Filter 的执行顺序和作用范围，从而实现灵活的安全策略和管理。

每个 Filter 可以配置不同的 URL 匹配规则，用于确定在何种情况下以及如何处理请求。通过配置 FilterChain 来指定 Filter 的执行顺序和作用范围。

### 2. Realm

Realm（域）是 Shiro 中用于进行身份验证和授权的组件。它负责从数据源（如数据库、LDAP 等）中获取安全数据（如用户信息、角色、权限等），并与 Shiro 进行交互。Realm 实现了 org.apache.shiro.realm.Realm 接口，开发者可以根据需要实现自定义的 Realm。

Realm 的主要作用包括：

- **身份验证**：通过用户提供的凭据（如用户名和密码）验证用户的身份。
- **授权**：获取用户的角色和权限信息，决定用户是否有权执行特定操作。

JDBC Realm：
- JDBC Realm 是通过 JDBC（Java Database Connectivity）与关系型数据库交互来获取用户认证和授权信息的。它通常用于将用户信息存储在数据库中，例如用户名、加密密码、角色和权限等。
LDAP Realm：
- LDAP Realm 使用 LDAP（Lightweight Directory Access Protocol）协议来获取和管理用户的认证和授权信息。LDAP 是一种常见的企业级目录服务协议，适合于需要集中管理用户身份信息的场景。
Active Directory Realm：
- Active Directory Realm 是专门用于与 Microsoft Active Directory 集成的 Realm。它通过 LDAP 协议与 Active Directory 进行通信，从中获取用户身份信息并执行身份验证和授权操作。
Text-based Realm：
- Text-based Realm 可以从简单的文本文件（如属性文件）中获取用户信息来进行身份验证和授权。这种 Realm 类型适用于小型应用或者测试环境，不需要复杂的用户存储和管理系统。
Custom Realm：
- 自定义 Realm 是开发者根据特定需求实现的一种 Realm。通过实现 Apache Shiro 框架中的 Realm 接口，可以集成任何用户数据源，如 NoSQL 数据库、Web 服务或者其他自定义的身份认证系统。

### 区别与联系

- **作用范围**：Filter 是处理 HTTP 请求的组件，控制请求的流程和安全策略；Realm 则是获取安全数据并进行认证和授权的核心组件。
- **实现方式**：开发者通常需要自定义 Realm 来适配特定的用户数据源，而 Filter 则通过配置来定义应用程序的安全策略。
- **关联性**：Filter 和 Realm 是紧密关联的，通过 Filter 调用 Realm 进行用户认证和授权操作，实现安全功能。

总结来说，Filter 和 Realm 在 Apache Shiro 中分别承担了不同的角色和责任，通过协作实现了全面的安全管理功能，确保应用程序的安全性和可靠性。

Spring Security特点

除了不能脱离Spring，shiro的功能它都有。

而且Spring Security对Oauth、OpenID也有支持,Shiro则需要自己手动实现。Spring Security的权限细粒度更高（还未发现高在哪里）。

注：

OAuth在"客户端"与"服务提供商"之间，设置了一个授权层（authorization layer）。"客户端"不能直接登录"服务提供商"，只能登录授权层，以此将用户与客户端区分开来。"客户端"登录授权层所用的令牌（token），与用户的密码不同。用户可以在登录的时候，指定授权层令牌的权限范围和有效期。

"客户端"登录授权层以后，"服务提供商"根据令牌的权限范围和有效期，向"客户端"开放用户储存的资料。

OpenID 系统的第一部分是身份验证，即如何通过 URI 来认证用户身份。目前的网站都是依靠用户名和密码来登录认证，这就意味着大家在每个网站都需要注册用户名和密码，即便你使用的是同样的密码。

如果使用 OpenID ，你的网站地址（URI）就是你的用户名，而你的密码安全的存储在一个 OpenID 服务网站上（你可以自己建立一个 OpenID 服务网站，也可以选择一个可信任的 OpenID 服务网站来完成注册）。

与OpenID同属性的身份识别服务商还有ⅥeID,ClaimID,CardSpace,Rapleaf,Trufina ID Card等，其中ⅥeID通用账户的应用最为广泛。

总结

个人认为现阶段需求，权限的操作粒度能控制在路径及按钮上，数据粒度通过sql实现。Shrio简单够用。

至于OAuth，OpenID 站点间统一登录功能，现租户与各个产品间单点登录已经通过cookies实现，所以Spring Security的这两个功能可以不考虑。

根据oauth2 使用spring+ Spring Security实现一个权限系统

要在 Spring 框架中使用 Spring Security 实现一个基于 OAuth2 的权限系统，可以按照以下步骤进行：

### 步骤一：集成 Spring Security OAuth2
1. 引入 Spring Security 和 Spring Security OAuth2 的相关依赖，并配置相应的配置文件。
2. 配置 OAuth2 的相关参数，包括客户端信息、授权码模式、令牌存储等。

### 步骤二：定义用户、角色和权限模型
1. 设计用户、角色和权限的数据表结构，并在数据源中创建相应的表。
2. 编写对应的实体类和持久化层代码，用于操作用户、角色和权限数据。

### 步骤三：配置 Spring Security
1. 配置 Spring Security 的认证和授权策略，包括基于数据库的用户认证、用户授权和角色控制。
2. 定义拦截器、过滤器链等相关配置，用于对请求进行安全控制和访问权限的验证。

### 步骤四：前端界面和交互
1. 设计前端界面和交互，包括登录页、用户管理、角色管理、权限管理等功能。
2. 前端页面与后端服务进行交互，实现用户的认证和授权操作。

### 步骤五：测试和调试
1. 确保正确配置 Spring Security OAuth2 的相关组件，保证整个系统的安全性和稳定性。
2. 测试各种场景下的权限控制逻辑，确保系统能够正常运行并且符合预期的权限管理要求。

### 注意事项：
- 确保正确配置 Spring Security OAuth2 的相关参数，特别是与数据库交互的信息，确保安全的存储用户、角色和权限数据。
- 对于不同类型的客户端（如 Web 应用、移动应用、第三方服务），需要配置不同的授权方式和访问策略，确保系统的灵活性和安全性。

以上是在 Spring 框架中使用 Spring Security 实现一个基于 OAuth2 的权限系统的一般步骤，具体的实现还需要根据具体需求和业务逻辑进行定制化开发。

DelegatingFilterProxy和FilterChainProxy以及SercurityFilterChain的作用和原理

DelegatingFilterProxy、FilterChainProxy 和 SecurityFilterChain 是 Spring Security 中用于处理过滤器链的重要组件，它们各自扮演着不同的角色和功能作用。

1. **DelegatingFilterProxy**：DelegatingFilterProxy 是一个 Spring Framework 提供的标准过滤器（Filter），它充当了 Spring 容器和 Servlet 容器之间的桥梁。在 Spring Security 中，DelegatingFilterProxy 被用于将 Filter 的初始化工作委托给 Spring 容器来完成，从而实现了 Spring Security 和 Servlet 容器的整合。DelegatingFilterProxy 会在 Servlet 容器启动时进行初始化，并将具体的安全过滤器链代理到 Spring 应用上下文中的实际过滤器链中。

2. **FilterChainProxy**：FilterChainProxy 是 Spring Security 提供的用于管理和执行过滤器链的核心组件。它用于维护和执行关联到特定请求的过滤器链，每个过滤器链由一组安全过滤器（SecurityFilter）组成，用于处理特定类型的请求或安全逻辑。FilterChainProxy 根据请求的 URL 和相关的安全规则，决定选取哪个过滤器链来处理请求，并依次调用该链上的安全过滤器。

3. **SecurityFilterChain**：SecurityFilterChain 是实际的安全过滤器链，它包含了一系列的安全过滤器（如身份验证过滤器、会话管理过滤器、授权过滤器等），并定义了这些过滤器的执行顺序和逻辑。每个 SecurityFilterChain 都关联到一个特定的请求模式（如 /admin/*）和安全配置，用于处理特定路径或模式的请求。在 Spring Security 中，可以配置多个 SecurityFilterChain 来处理不同类型的请求。

整体来说，DelegatingFilterProxy 负责将过滤器的初始化委托给 Spring 容器，FilterChainProxy 负责管理和执行实际的过滤器链，而 SecurityFilterChain 则定义了具体的安全过滤器和执行顺序。通过它们的协作，Spring Security 实现了灵活且强大的安全过滤器链管理，能够根据请求的特征和安全配置，动态地调用适当的过滤器链来处理请求。

Spring Security 6 中的安全过滤器（Security Filters）是 Spring Security 的核心组件之一，它们负责实现了身份验证、授权、会话管理等安全功能。每个安全过滤器都有不同的作用和原理，它们按照一定的顺序组成了安全过滤器链（Security Filter Chain）。默认情况下，Spring Security 包含了一组核心的安全过滤器，共有 15 个。以下是这些核心安全过滤器的作用、原理以及默认配置：

1：DisableEncoderUrlFilter
禁止URL重新编码，默认程序启动就会加载。

2：WebAsynManagerIntegrationFilter
将WebAsyncManager与SpringSecurity上下文进行集成。默认程序启动就会加载。

将web的异步处理管理器与SpringSecurity上下文进行集成

3：SecurityContextHolderFilter
获取安全上下文，默认程序启动就会加载。

4：HeaderWriterFilter
处理头信息加入响应中，默认程序启动就会加载。

5：CsrfFilter
处理CSRF攻击，默认程序启动就会加载。

6：LogoutFilter
处理注销登录，默认程序启动就会加载。

7：UsernamePasswordAuthenticationFilter
处理表单登录，默认程序启动就会加载。

8：DefaultLoginPageGeneratingFilter
配置默认登录页面，默认程序启动就会加载。

9：DefaultLogoutPageGeneratingFilter
配置默认注销页面，默认程序启动就会加载。

10：BasicAuthenticationFilter
处理 HttpBasic登录，默认程序启动就会加载。

11：RequestCacheAwareFilter
处理请求缓存，默认程序启动就会加载。

12：SecurityContextHolderAwareRequestFilter
包装原始请求，默认程序启动就会加载。

13：AnonymousAuthenticationFilter
配置匿名认证，默认程序启动就会加载。

14：ExceptionTranslationFilter
处理认证/授权中的异常，默认程序启动就会加载。

15：AuthorizationFilter
处理当前用户是否有权限访问目标资源，默认程序启动就会加载。

JWT（JSON Web Token）

JWT（JSON Web Token）是一种基于JSON的开放标准（RFC 7519），用于在网络上传输信息的一种方式。JWT由三部分组成：Header（头部）、Payload（负载）和Signature（签名）。其生成的token可以被传递和验证，通常用于在不同系统之间安全地传递信息，实现用户认证和授权机制。

生成JWT Token的过程大致如下：
1. 创建一个包含必要信息的JSON对象，作为Payload部分。Payload可以包含一些标准的声明（比如iss、exp等），也可以包含自定义的信息。
2. 创建一个包含算法和令牌类型信息的JSON对象，作为Header部分。
3. 使用指定的算法（如HMAC SHA256、RSA等）对Header和Payload进行签名生成Signature部分。
4. 将Header、Payload和Signature连接起来，使用Base64编码生成最终的JWT Token。
5. 将生成的Token发送给需要验证的服务端。

在服务端接收到Token后，可以通过以下步骤进行验证：
1. 对接收到的Token进行Base64解码，得到Header、Payload和Signature三个部分。
2. 使用同样的算法和密钥对Header和Payload进行签名，得到一个新的Signature。
3. 将两个Signature进行比较，如果一致，则说明Token未被篡改，可以信任其中的信息。

JWT广泛应用于Web开发中，特别是在前后端分离的场景中常用于用户认证和授权。它的优点包括轻量级、易于传递、可自定义内容、支持跨域等特点。但需要注意的是，JWT中的信息虽然经过Base64编码，但未加密，因此在传输时需要注意安全性。

JWT结构

一个JWT由三部分组成，它们用.分隔开来：

Header（头部）：包含了Token的元数据和描述信息，例如使用的加密算法（如HMAC SHA256或RSA）、令牌类型（JWT）等。Header通常是Base64Url编码后的JSON字符串。

示例：
```
{
  "alg": "HS256",
  "typ": "JWT"
}
```
Payload（载荷）：包含了Claims，即JWT持有的实际信息，例如用户的身份数据和其他元数据。Claims分为三种类型：
- 注册声明（Registered Claims）：预定义的标准Claims，如iss（签发者）、sub（主题）、exp（过期时间）等。
- 公共声明（Public Claims）：自定义的Claims，可以根据需要定义，但建议避免冲突。
- 私有声明（Private Claims）：自定义的Claims，用于在同意使用它们的各方之间共享信息，不注册在IANA中或是注册中定义的。
示例：
```
{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}
```
Signature（签名）：使用Header中指定的算法和密钥对Header和Payload进行签名，以确保Token在传输过程中没有被篡改。签名是对Base64Url编码后的Header和Payload计算得到的。

示例：
```
HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret
)
```

JWT工作流程

生成Token：用户登录成功后，服务器根据用户的信息生成JWT，并将其作为响应的一部分发送给客户端。
传递Token：客户端收到JWT后，将其存储在本地（通常是在内存或LocalStorage中），并在将来的请求中将JWT放置在请求头部的Authorization字段中发送给服务器。
```
Authorization: Bearer <token>
```
验证Token：服务器接收到请求后，解析JWT，验证其签名以及有效期（过期时间），并根据Payload中的Claims来验证用户的身份和授权信息。
使用Token：服务器根据验证结果决定是否授权用户访问请求的资源。如果验证通过，服务器处理请求并返回相应的数据或操作。

JWT的优势

无状态性：服务器不需要在后端存储会话信息，因为JWT本身包含了所有必要的信息。
扩展性：适用于分布式系统和微服务架构，因为每个服务可以验证Token而无需访问共享存储或数据库。
安全性：JWT使用签名来验证发送方的身份和内容的完整性，有效防止数据被篡改。

使用场景

单点登录（SSO）：在多个应用之间共享用户身份信息，实现用户无缝登录不同系统。
API安全：作为RESTful API的身份验证和授权机制，用于保护API端点免受未经授权的访问。

总体来说，JWT因其简单性、灵活性和安全性，已经成为许多Web应用和服务之间安全通信的首选解决方案之一。

鉴权过滤器

在Java中，你可以使用Spring Cloud Gateway来实现鉴权功能。以下是一个简单的示例，展示如何在Spring Cloud Gateway中添加鉴权过滤器：

import org.springframework.cloud.gateway.filter.GatewayFilter;
import org.springframework.cloud.gateway.filter.GatewayFilterChain;
import org.springframework.stereotype.Component;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;

@Component
public class AuthFilter implements GatewayFilter {

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        String authHeader = exchange.getRequest().getHeaders().getFirst("Authorization");
        if (authHeader == null || !authHeader.startsWith("Bearer ")) {
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }
        
        // Here you would validate the token, e.g., call an authentication service
        String token = authHeader.substring(7); // remove "Bearer "
        if (isValidToken(token)) {
            return chain.filter(exchange);
        } else {
            exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED);
            return exchange.getResponse().setComplete();
        }
    }

    private boolean isValidToken(String token) {
        // Implement your token validation logic here
        return true; // Replace with actual validation logic
    }
}

在此示例中，我们在网关层添加了一个简单的鉴权过滤器，检查请求头中的Authorization字段。

通过上述方式，你可以定制网关的鉴权逻辑，确保只有经过认证的请求可以访问后端服务。