什么是 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再转二进制，消耗会更大。

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

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

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

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

2. 通信，可以选择七层的http，四层的tcp/udp

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

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