每日一问【1】

CSDN话题挑战赛第2期
参赛话题：Java学习笔记

今天老师给我布置了些问题，我解决完了之后觉得可以给大家分享一下，如果有欠缺和错误的地方请各位大哥劳烦指出来一下，小生在这谢谢各位大哥了。下面就是今天的问题，欢迎各位大佬补充、指点。

问题一、springcloud的组件有哪些？都有什么作用？

• springcloud 主要有六大组件。

1、注册中心：Eureke(ZooKeeper)

• Eureka有客户端和服务端，每一个服务上面都有Eureka客户端，可以把本服务的相关信息注册到Eureka服务端上。
• Eurake客户端：负责将这个服务的信息注册到Eureka服务端中。
• Eureka服务端：相当于一个注册中心，里面有注册表，注册表中保存了各个服务所在的机器和端口号，可以通过Eureka服务端找到各个服务。

2、服务远程调用：Feign （Dubbo）

• 用注解定义一个 FeignClient接口，然后调用那个接口就可以了。
• Feign的一个机制就是使用了动态代理：
  • 首先，如果你对某个接口定义了@FeignClient注解，Feign就会针对这个接口创建一个动态代理。
  • 接着你要是调用那个接口，本质就是会调用 Feign创建的动态代理。
  • Feign的动态代理会根据你在接口上的@RequestMapping等注解，来动态构造出你要请求的服务的地址。
  • 最后针对这个地址，发起请求、解析响应。

3、负载均衡：Ribbon

• 在服务消费者端配置和使用，它的作用就是负载均衡。
• 服务间发起请求的时候，服务消费者方基于Ribbon服务做到负载均衡，从服务提供者存储的多台机器中选择一台，如果一个服务只在一台机器上面，那就用不到Ribbon选择机器了，如果有多台机器，那就需要使用Ribbon选择之后再去使用。
• 默认使用的负载均衡算法是轮询算法，Ribbon会从Eureka服务端中获取到对应的服务注册表，然后就知道相应服务的位置，然后Ribbon根据设计的负载均衡算法去选择一台机器，Feigin就会针对这些机器构造并发送请求。

4、配置中心：Spring Cloud Config

• 为微服务架构中各个微服务提供集中化的外部配置支持。
• Spring Cloud Config 可以将各个微服务的配置文件集中存储在一个外部的存储仓库或系统（例如 Git 、SVN 等）中，对配置的统一管理，以支持各个微服务的运行。
• Spring Cloud Config 包含两个部分：
  • Config Server：也被称为分布式配置中心，它是一个独立运行的微服务应用，用来连接配置仓库并为客户端提供获取配置信息、加密信息和解密信息的访问接口。
  • Config Client：指的是微服务架构中的各个微服务，它们通过 Config Server 对配置进行管理，并从 Config Sever 中获取和加载配置信息。
• Spring Cloud Config 默认使用 Git 存储配置信息，因此使用 Spirng Cloud Config 构建的配置服务器天然就支持对微服务配置的版本管理。我们可以使用 Git 客户端工具方便地对配置内容进行管理和访问。除了 Git 外，Spring Cloud Config 还提供了对其他存储方式的支持，例如 SVN、本地化文件系统等。
• Spring Cloud Config 工作流程如下：
  • 开发或运维人员提交配置文件到远程的 Git 仓库。
  • Config 服务端（分布式配置中心）负责连接配置仓库 Git，并对 Config 客户端暴露获取配置的接口。
  • Config 客户端通过 Config 服务端暴露出来的接口，拉取配置仓库中的配置。
  • Config 客户端获取到配置信息，以支持服务的运行。

5、服务网关：SpirngCloudGateway，Zuul

• 该组件是负责网络路由的，假设你后台部署了几百个服务，现在有个前端兄弟，人家请求是直接从浏览器那儿发过来的。
• 知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。

6、服务监控和保护： Hystrix （Sentinel）

• Hystrix是隔离、熔断以及降级的一个框架，说白了就是Hystrix会搞很多小线程池然后让这些小线程池去请求服务，返回结果。
• Hystrix相当于是个中间过滤区，如果我们的积分服务挂了，那我们请求积分服务直接就返回了，不需要等待超时时间结束抛出异常，这就是所谓的熔断。

总结：

• Eureka：服务启动的时候，服务上的Eureka客户端会把自身注册到Eureka服务端，并且可以通过Eureka服务端知道其他注册的服务。
• Ribbon：服务间发起请求的时候，服务消费者方基于Ribbon服务做到负载均衡，从服务提供者存储的多台机器中选择一台，如果一个服务只在一台机器上面，那就用不到Ribbon选择机器了，如果有多台机器，那就需要使用Ribbon选择之后再去使用。
• Feign：Feign使用的时候会集成Ribbon，Ribbon去Eureka服务端中找到服务提供者的所在的服务器信息，然后根据随机策略选择一个，拼接Url地址后发起请求。
• Hystrix：发起的请求是通过Hystrix的线程池去访问服务，不同的服务通过不同的线程池，实现了不同的服务调度隔离，如果服务出现故障，通过服务熔断，避免服务雪崩的问题 ，并且通过服务降级，保证可以手动实现服务正常功能。
• Zuul：如果前端调用后台系统，统一走zull网关进入，通过zull网关转发请求给对应的服务。
• Spring Cloud Config： 可以为微服务架构中各个微服务需要的（application.properties 或 application.yml ）配置文件提供集中化的外部配置支持。

问题二、项目中跨域是如何解决的？还知道哪些其他的跨域解决方案？

• 方式一： 利用Filter
  • 进行白名单检测 OPTIONS请求，header已设好。
• 方式二： 利用CorsRegistry
  • // 添加映射路径 // 允许的域 // 允许携带cookie // 允许的请求方式 // 允许的请求头。
• 方式三：利用@CrossOrigin注解
  • @CrossOrigin({“http://127.0.0.1:8080”})。

问题三、项目中权限认证怎么做的？

• 基于token的鉴权机制类似于http协议也是无状态的，它不需要在服务端去保留用户的认证信息或者会话信息。
• 流程：
  • 用户使用用户名密码来请求服务器。
  • 服务器进行验证用户的信息。
  • 服务器通过验证发送给用户一个token。
  • 客户端存储token，并在每次请求时附送上这个token值。
  • 服务端验证token值，并返回数据。
• 这个token必须要在每次请求时传递给服务端，它应该保存在请求头里，
  另外，服务端要支持CORS(跨来源资源共享)策略，一般我们在服务端这么做就可以了。

问题四、maven依赖冲突怎么解决，项目中jar包版本是如何管理的？

1、依赖标签

1.1、dependencyManagement

• dependencyManagement中定义的只是依赖的声明，并不实现引入，因此一般只用于依赖管理。

1.2、type

• 依赖的类型,一般就是依赖的文件类型，默认是jar。
• 最常用的就是pom和jar,要和对应依赖的文件类型进行匹配.也就是依赖的工程的打包方式(这个打包方式如果没有声明,默认就是jar)。
• 如果是pom,其实就相当于引入了一个pom文件 相当于在项目中导入了这个pom中的所有依赖。

1.3、scope

• 依赖的范围, 可以限制依赖的传递性和依赖什么时候会被使用,通常有以下六个值：
  • **compile:**默认范围 ， 如果没有指定，则使用。编译依赖项在项目的所有类路径中都可使用。此外这些依赖关系会传播到依赖项目。
  • provided：表示您希望JDK或容器运行时提供依赖项。
  • runtime：表示编译不需要依赖，但执行。Maven在运行时和测试类路径中包含具有此范围的依赖项，但不包括编译类路径。
  • test：表示应用程序的正常使用不需要依赖，只在测试编译和执行阶段可用。
  • system：类似于provided除了你必须提供明确包含它的JAR外。工作始终可用，不会在存储库中查找。
  • import：此范围表示仅受该部分中类型的依赖项支持。
    它表示依赖项将被指定POM部分中的有效依赖项列表替换。由于被它们替换，范围内的依赖项实际上并不参与限制依赖项的传递性。

2、 jar 包管理方式

2.1、建立父工程

• 这是最常见也是最实用的管理版本方式,比如当我们服务拆分成几个单独模块变成微服务时,建立父工程去管理pom就最合适了。
  注意父工程中仅仅只有一个pom。

2.2、引入Springboot父工程

• 可以直接引入Springboot帮我们构建好的模块。打开引入的父工程看,可以直接的看到就是一个pom.也就是说我们所有引入的父工程都只是引入一个pom而已。

2.3、在本工程使用dependencyManagement

• 有时候我们的项目并没有父工程,又是微服务,Spring Cloud这些,这时候一定要进行版本管理。 因为如果Spring Cloud各个组件(网关,注册中心等)的版本没有相互兼容,就容易出现各种各样的问题。
  Spring Cloud本身也帮我们进行了一个版本的整合。
  这个时候就可以直接在本工程使用dependencyManagement进行版本控制。

2.4、直接在pom中进行最基本的版本引用

3、 解决依赖冲突

步骤：

3.1.1、找到冲突的jar包.

• 命令：mvn -Dverbose dependency:tree

3.1.2、统一版本

• 主要有以下三种方式:
  • 1、利用依赖原则统一。
    • ①路径最短者优先.(–>代表依赖)
      举例:A–>B–>C
      B–>x.jar(1.0版本)
      C–>x.jar(1.1版本)
      则最后A中编译的使用的是B中的1.0版本.
    • ②相同路径先声明者优先.
      举例:A–>B A–>C
      B–>x.jar(1.0版本)
      C–>x.jar(1.1版本)
      此时两个依赖路径是相同的,谁先声明(代码放在前面),A就使用谁。
  • 2、多余的依赖进行排除。
  • 3、jar包版本管理方式进行版本统一化。