目录

Spring Boot

什么是 Spring Boot？

Spring Boot 有哪些优点？

SpringBootApplication注解

Spring Boot 的启动流程

Spring Boot属性加载顺序

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

如何理解springboot中的starter？

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

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

Springcloud

Springcloud核心组件有哪些？

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

SOA架构特点：

主要区别：

微服务架构特点：

1.通过服务实现组件化

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

3.去中心化

微服务架构原理是什么？

注册中心的原理是什么？

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

配置中心的原理是什么？

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

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

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

Spring Cloud和Dubbo有哪些区别?

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

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

dubbo的核心的配置有哪些

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

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

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

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

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

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

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

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

Dubbo服务的注册流程

Dubbo服务暴露过程

Dubbo服务引入过程

Dubbo服务调用过程

Ribbon负载均衡原理是什么?

Ribbon使用

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

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

ribbon负载均衡分类

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

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

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

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

计算机网络

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

网络七层模型

tcp/ip原理

TCP和UDP

Socket

RestfulHttp和RPC关系

如何理解RPC

RPC和http协议的区别

http和https的区别

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

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

如何理解RPC

安全框架与权限相关

Shiro

Spring Security(SpringSecurityFilterChain

实现 WebSecurityConfigurer Adapter)

Shiro主要功能

Spring Security主要功能

Shiro特点

Spring Security特点

---

Spring Boot

什么是 Spring Boot？

Spring Boot 是 Spring 开源组织下的子项目，是 Spring 组件一站式解决方案，主要是简化了使用 Spring 的难度，简省了繁重的配置，提供了各种启动器，开发者能快速上手。

Spring Boot 有哪些优点？

Spring Boot 主要有如下优点：

容易上手，提升开发效率，为 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中，属性的加载顺序可以根据不同的来源和优先级进行调整。以下是一般情况下属性加载的顺序：

1. 命令行参数（Command Line Arguments）：通过在命令行中使用--key=value的参数形式传递属性值，可以覆盖其他来源中的属性值。

2. 系统属性（System Properties）：可以通过在JVM启动参数中使用-Dkey=value的形式设置系统属性，同样可以覆盖其他来源中的属性值。

3. 环境变量（Environment Variables）：系统环境变量中定义的属性，可以通过System.getenv()方法获取。Spring Boot会自动将环境变量转换成属性。

4. 配置文件（Application Properties/YAML）：Spring Boot支持使用不同的配置文件格式，如.properties和.yaml/.yml文件。配置文件的属性值可以根据不同的配置文件进行覆盖。默认加载的配置文件是application.properties（或application.yml），还可以通过spring.config.name和spring.config.location来指定其他名称和位置的配置文件。

5. 配置文件的Profile相关的属性：可以根据不同的Profile（如开发环境、测试环境、生产环境）来加载对应的属性文件，例如application-dev.properties。

6. 在@Configuration注解修改的类中，通过@PropertySource注解定义的属性

7. 默认属性（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的几个关键点进行进一步解释：

1. 关注领域和功能：

   • 每个Starter都关注于特定领域或功能，例如Web开发、数据库访问、消息队列等。

   • Starter的命名通常基于该领域或功能的名称，例如"spring-boot-starter-web"、"spring-boot-starter-data-jpa"等。

2. 自动配置：

   • Starter提供了自动配置的能力，无需手动编写各种繁琐的配置项。

   • Starter中包含了预定义的默认配置，可以根据类路径上存在的其他组件进行自动配置。

3. 依赖管理：

   • Starter还提供了对相关依赖的管理，以确保所需要的依赖项都能正确地引入到项目中。

   • Starter中包含了推荐的依赖列表，当引入一个Starter时，相关的依赖项也会被自动引入。

4. 可插拔性：

   • Spring Boot提供了一种可插拔的机制，允许开发者通过引入或排除不同的Starter来定制应用程序的功能。

   • 通过添加或删除Starter，可以非常方便地增加或减少应用程序所支持的功能。

5. 快速启动和集成：

   • 引入一个特定的Starter可以让应用程序快速启动并集成所需功能。

   • Starter提供了一种简单而一致的方式来使用和配置功能，大大简化了开发流程。

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

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

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

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进行同步，当服务消费者要调用服务提供者，则向服务注册中心获取服务提供者地址，然后会将服务提供者地址缓存在本地，下次再调用时，则直接从本地缓存中取，完成一次调用

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

服务注册

服务续约

服务下线

服务获取

服务调用

失效剔除

自我保护

服务同步

配置中心的原理是什么？

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

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

1. 配置中心Server端承担起配置刷新的职责

2. 提交配置触发post请求给server端的bus/refresh接口

3. server端接收到请求并发送给Spring Cloud Bus总线

4. Spring Cloud bus接到消息并通知给其它连接到总线的客户端

5. 其它客户端接收到通知，请求Server端获取最新配置

6. 全部客户端均获取到最新的配置

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

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

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

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

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

Zookeeper保证的是CP（一致性，容错性）, 而Eureka则是AP（可用性，容错性）。Eureka自我保护机制太强

Spring Cloud和Dubbo有哪些区别?

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

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

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

 什么是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（最小活跃数策略）等。这些策略用于在服务消费者调用服务提供者时进行负载均衡，以提高系统性能和稳定性。

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 服务调用过程。若有任何问题，欢迎随时提出。

Ribbon负载均衡原理是什么?

1. Ribbon通过ILoadBalancer接口对外提供统一的选择服务器(Server)的功能，此接口会根据不同的负载均衡策略(IRule)选择合适的Server返回给使用者。

2. IRule是负载均衡策略的抽象，ILoadBalancer通过调用IRule的choose()方法返回Server

3. IPing用来检测Server是否可用，ILoadBalancer的实现类维护一个Timer每隔10s检测一次Server的可用状态

4. 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 客户端负载均衡：ribbon

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

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

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

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

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

实现原理

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

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

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

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

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

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

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

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

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

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

计算机网络

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

网络七层模型

tcp/ip原理

TCP和UDP

Socket

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）协议是常见的网络通信协议，它们之间有以下几个主要区别：

1. 技术栈和用途：RPC 是一种远程调用协议，通常用于分布式系统中不同模块或服务之间的通信，以实现函数或方法的调用。RPC 的实现包括多种技术栈，如 gRPC、Thrift、Dubbo 等。而 HTTP 是一种应用层协议，主要用于 Web 浏览器和服务器之间的通信，支持传输超文本和其他资源。它是基于 RESTful 架构风格的主要通信协议。

2. 通信方式：RPC 通常使用二进制的序列化格式进行数据传输，例如 Protocol Buffers、Apache Avro 等。这种二进制格式在数据传输效率和体积上有较大的优势。而 HTTP 通常使用文本格式进行数据传输，例如 JSON 或 XML。文本格式易于理解和调试，但相对而言数据体积较大，传输效率相对较低。

3. 语义和扩展性：RPC 通常倾向于提供更加语义化和精细控制的通信方式。它可以直接调用远程服务上的函数或方法，并返回结果。RPC 支持对分布式系统的透明远程调用，使得调用方可以像调用本地函数一样调用远程服务。相比之下，HTTP 更加面向资源和状态转移。它使用标准的请求-响应模型，通过 HTTP 方法（GET、POST 等）对资源进行操作，并使用状态码表示请求状态。HTTP 具有更好的扩展性和灵活性。

4. 生态系统：由于 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 上常见的两种通信协议，它们之间有几个主要的区别：

1. 安全性: 最明显的区别在于安全性。HTTP 是一种明文传输协议，数据传输是未加密的，因此容易受到中间人攻击，信息可能会被窃听或篡改。而 HTTPS 则是在 HTTP 上加入了 SSL/TLS 加密层，通过使用公钥加密算法保证了数据在传输过程中的机密性和完整性，因此更加安全。

2. 默认端口: HTTP 默认端口是80，而 HTTPS 默认端口是443。这是网络通信中的规范，用于区分不同的应用服务。

3. 证书支持: HTTPS 使用了 SSL/TLS 加密协议，需要使用数字证书来验证服务器的身份。这种机制有效地防止了中间人攻击，用户可以通过数字证书来确认服务器的合法性，确保数据在传输过程中不会被篡改。而 HTTP 不需要使用证书验证。

4. 网络抓包分析: 由于 HTTP 是明文传输，因此通过网络抓包工具（例如Wireshark）可以轻松查看数据内容，而 HTTPS 则由于加密的传输方式，使得抓包分析变得更为困难。

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

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

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

1. 身份验证：HTTPS证书用于验证服务器的身份。证书颁发机构（CA）对服务器的身份进行核实，并将其公钥绑定到数字证书上。客户端在建立连接时会收到服务器的证书，通过验证签发CA的数字签名和证书中的信息，确定服务器身份的合法性。

2. 加密通信：证书中包含了公钥，客户端利用这个公钥与服务器进行通信加密。这样，即使通信被中间人截获，也无法获取有意义的数据。

3. 完整性验证：证书中包含了数字签名，用于验证证书内容的完整性和真实性。如果证书内容在传输过程中被篡改，数字签名会失效，客户端可以通过验证数字签名来检验证书是否被篡改。

4. 加密算法和密钥长度：证书的安全性也依赖于使用的加密算法和密钥长度。合适的加密算法和足够长的密钥长度是保证证书安全性的关键。

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

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

如何理解RPC

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

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

1. 序列化与反序列化，数据传输与接收

2. 通信，可以选择七层的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在我们进行用户认证以及授予权限的时候，通过各种各样的拦截器来控制权限的访问，从而实现安全。

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

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、不跟任何的框架或者容器捆绑，可以独立运行。

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的这两个功能可以不考虑。