2024最新Java基础面试题大全（四）

1、前后端分离是如何实现的

通过 Ajax 和 negix 实现

前后端工程师约定好数据交互接口，实现并行开发和测试；在运行阶段前后端分离模式需要对web应用进行分离部署，前后端之前使用HTTP或者其他协议进行交互请求。

2、如何解决跨域问题

解决跨域问题

1、 通过jsonp跨域
2、 document.domain + iframe跨域
3、 location.hash + iframe
4、 window.name + iframe跨域
5、 postMessage跨域
6、 跨域资源共享（CORS）
7、 nginx代理跨域
8、 nodejs中间件代理跨域
9、 WebSocket协议跨域

3、微服务如何落地

1、组件化服务：先进行设计、服务的切分一定要业务互不影响，但可以相互调用。

2、按照需求分布团队：正常的话，三到四个人，维护一个服务。根据业务进行划分，设计出一个优秀的开发计划

3、服务间的调用：分布式微服务设计需要解决，通信和数据传递的问题，通信有 RPC 调用，从进程内转换到进程间，这样并不占优势，所以我们会使用中间件 MQ 和 RestFul 等方式。

4、服务治理：我们需要用到 服务发现注册，Eureka、Zookeeper、Consul、Nacos 等技术，由服务注册中心统一管理，再使用服务调用 OpenFeign LoadBalancer等技术实现负载等机制。

5、容错机制：对于一个高可用的微服务架构少不了容错机制，避免某个服务宕机而影响整个微服务，避免雪崩

4、RPC 与 HTTP 的区别

RPC 与 HTTP 区别 图解

无论是微服务还是分布式服务（都是SOA，都是面向服务编程），都面临着服务间的远程调用

• RPC：Remote Produce Call远程过程调用，类似的还有RMI（Remote Methods Invoke 远程方法调用，是JAVA中的概念，是JAVA十三大技术之一）。自定义数据格式，基于原生TCP通信，速度快，效率高。早期的webservice，现在热门的dubbo，都是RPC的典型

  • RPC的框架：webservie(cxf)、dubbo
  • RMI的框架：hessian

• Http：http其实是一种网络传输协议，基于TCP，规定了数据传输的格式。现在客户端浏览器与服务端通信基本都是采用Http协议。也可以用来进行远程服务调用。缺点是消息封装臃肿。

  现在热门的Rest风格，就可以通过http协议来实现。

  • http的实现技术：HttpClient

• 相同点：底层通讯都是基于socket，都可以实现远程调用，都可以实现服务调用服务

• 不同点：
  RPC：框架有：dubbo、cxf、（RMI远程方法调用）Hessian
  当使用RPC框架实现服务间调用的时候，要求服务提供方和服务消费方 都必须使用统一的RPC框架，要么都dubbo，要么都cxf

  跨操作系统在同一编程语言内使用
  优势：调用快、处理快

  http：框架有：httpClient
  当使用http进行服务间调用的时候，无需关注服务提供方使用的编程语言，也无需关注服务消费方使用的编程语言，服务提供方只需要提供restful风格的接口，服务消费方，按照restful的原则，请求服务，即可

  跨系统跨编程语言的远程调用框架
  优势：通用性强

总结：对比RPC和http的区别
1 RPC要求服务提供方和服务调用方都需要使用相同的技术，要么都hessian，要么都dubbo 而http无需关注语言的实现，只需要遵循rest规范
2 RPC的开发要求较多，像Hessian框架还需要服务器提供完整的接口代码(包名.类名.方法名必须完全一致)，否则客户端无法运行
3 Hessian只支持POST请求
4 Hessian只支持JAVA语言

5、怎么理解RestFul

RestFul

（1）每一个URI代表一种资源；

（2）客户端和服务器之间，传递这种资源的某种表现层；

（3）客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

6、怎么设计良好的 API

设计API

要明确、让API 表面积尽可能小、减少样板、降低依赖、返回有意义的错误代码、异常有真正含义、对所有的事情建立文档、编写测试、允许用户选择、而不能给用户太多选择（提供默认）

7、服务如何拆分

8、CAP 原则

Consistency：一致性

Availability：可用性

Partiton Tolerance：分区容忍

总结：数据重要 CP，不重要 AP

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，因此，根据CAP原理将 NoSQL 数据库分成了满足 CA 原则，满足 CP 原则和满足 AP 原则三大类：

​ CA - 单点集群，满足一致性，可用性的系统，通常在可扩展上不太强大 （Eureka）违背了一致性，满足高可用

​ CP - 满足一致性，分区容忍必的系统，通常性别能不是特别高 （Zookeeper / Consul） 违背了可用性，只满足一致性

​ AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些

9、如何实现数据的一致性

https://www.jianshu.com/p/b264a196b177

传统应用的事务管理
1.1 本地事务
1.2 分布式事务
1.2.1 两阶段提交（2PC）
1.2.2 三阶段提交（3PC）

微服务下的事务管理

实现微服务下数据一致性的方式
3.1 可靠事件通知模式
3.1.1 同步事件
3.1.2 异步事件

10、怎么做到全局的微服务治理

spring cloud是关注全局的微服务协调整理治理框架,是分布式微服务架构下的一站式解决方案,是各个架构落地技术的集合体.

Spring Cloud Config：配置管理开发工具包，可以让你把配置放到远程服务器，目前支持本地存储、Git以及Subversion。

Spring Cloud Bus：事件、消息总线，用于在集群（例如，配置变化事件）中传播状态变化，可与Spring Cloud Config联合实现热部署。

Spring Cloud Netflix：针对多种Netflix组件提供的开发工具包，其中包括Eureka、Hystrix、Zuul、Archaius等。

Netflix Eureka：云端负载均衡，一个基于 REST 的服务，用于定位服务，以实现云端的负载均衡和中间层服务器的故障转移。

Netflix Hystrix：容错管理工具，旨在通过控制服务和第三方库的节点,从而对延迟和故障提供更强大的容错能力。

Netflix Zuul：边缘服务工具，是提供动态路由，监控，弹性，安全等的边缘服务。

Netflix Archaius：配置管理API，包含一系列配置管理API，提供动态类型化属性、线程安全配置操作、轮询框架、回调机制等功能。

Spring Cloud for Cloud Foundry：通过Oauth2协议绑定服务到CloudFoundry，CloudFoundry是VMware推出的开源PaaS云平台。

Spring Cloud Sleuth：日志收集工具包，封装了Dapper,Zipkin和HTrace操作。

Spring Cloud Data Flow：大数据操作工具，通过命令行方式操作数据流。

Spring Cloud Security：安全工具包，为你的应用程序添加安全控制，主要是指OAuth2。

Spring Cloud Consul：封装了Consul操作，consul是一个服务发现与配置工具，与Docker容器可以无缝集成。

Spring Cloud Zookeeper：操作Zookeeper的工具包，用于使用zookeeper方式的服务注册和发现。

Spring Cloud Stream：数据流操作开发包，封装了与Redis,Rabbit、Kafka等发送接收消息。

Spring Cloud CLI：基于 Spring Boot CLI，可以让你以命令行方式快速建立云组件。

11、服务雪崩如何出现，怎么解决

当一个请求依赖多个服务的时候：正常情况下的访问，没有任何问题，但是，当请求的服务中出现无法访问、异常、超时等问题时，那么用户的请求将会被阻塞，如果多个用户的请求中，都存在无法访问的服务，那么他们都将陷入阻塞的状态中。

Hystrix的引入，可以通过服务熔断和服务降级来解决这个问题。

12、如何做到配置的动态更新

Spring Cloud 默认实现了配置中心动态刷新的功能，在公共模块 spring-cloud-context 包中。目前比较流行的配置中心 Spring Cloud Config 动态刷新便是依赖此模块，而Nacos动态刷新机制是在此模块上做了扩展，比Spring Cloud Config功能更强大丰富。

首先 Spring Cloud Config 动态刷新需要依赖 Spring Cloud Bus，而 Nacos 则是在后台修改后直接推送到各服务。
其次，Spring Cloud Config的刷新机制针对所有修改的变量，只有有改动，后台就会获取。而Nacos则是支持粒度更细的方式，只有 refresh 属性为 true 的配置项，才会在运行的过程中变更为新的值。这时Nacos特有的方式。

相同点：两种配置中心动态刷新的范围都是以下两种：

• @ConfigurationProperties 注解的配置类
• @RefreshScope 注解的bean

13、如何快速的定位问题，追踪问题

在微服务复杂的链式调用中，我们会比单体架构更难以追踪与定位问题。因此，在设计的时候，需要特别注意。一种比较好的方案是，当 RESTful API 接口出现非 2xx 的 HTTP 错误码响应时，采用全局的异常结构响应信息。其中，code 字段用来表示某类错误的错误码，在微服务中应该加上“{biz_name}/”前缀以便于定位错误发生在哪个业务系统上。我们来看一个案例，假设“用户中心”某个接口没有权限获取资源而出现错误，我们的业务系统可以响应“UC/AUTH_DENIED”，并且通过自动生成的 UUID 值的 request_id 字段，在日志系统中获得错误的详细信息。 、、、、、、、、、、、、、、000000000

HTTP/1.1 400 Bad Request
Content-Type: application/json
{
    "code": "INVALID_ARGUMENT",
    "message": "{error message}",
    "cause": "{cause message}",
    "request_id": "01234567-89ab-cdef-0123-456789abcdef",
    "host_id": "{server identity}",
    "server_time": "2014-01-01T12:00:00Z"
}