java 面试问答———微服务篇（2024523此时微软谷歌亚马逊已经宣布去微化）

 针对微软去微服务，回到单体架构，我的一些思考，为啥我们的技术架构总是被美牵着鼻子走，人家提出微服务，我们就跟风走微服务，人家提出去微服务，我们也跟风？那有人说：因为c语言是外国人写的。。。。人家是鼻祖，那我无话可说，毕竟是人家发展的早，这个时候我们应该说我们要走“中国特色社会主义道路”， 软件服务架构是不是也创建一个介于微服务与单体直接架构呢？（不是多模块哈，多模块绕着走.. 。。。。）

1，简述什么是微服务？

答案：微服务是一种分布式架构，分布式架构就是把服务拆分，在我们传统单体架构中，我们把所有服务都写在一起，随着业务的增加，我们的单体架构中服务也逐渐臃肿，后维护很不方便。 微服务局势把模块拆分，把我们整个项目拆分许多独立的子项目，每个子项目独立开发、部署，子项目也是独立的功能，这些独立的子项目就形成了微服务。

2，详细说说微服务的优缺点？

答案： 优点： 1，不用服务使用不同技术，技术多样性；

                        2，隔离性。一个服务不可用不会导致其他服务不可用；

                        3，部署简单， 服务都是独立部署的，哪个服务出问题，只需修改重部署。

           缺点： 1，运维成本增加

                       2， 问题调查困难（链路跟踪）

                       3，分布式部署，服务器资源耗费增加，需要多机申请机器资源、

2， 简单说说分布式和微服务的区别？

答案：1，含义不同 
微服务架构：微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
2、概念层面不同 
微服务架构：微服务是设计层面的东西，一般考虑如何将系统从逻辑上进行拆分，也就是垂直拆分。微服务可以是分布式的，即可以将不同服务部署在不同计算机上，当然如果量小也可以部署在单机上。
分布式架构：分布式是部署层面的东西，即强调物理层面的组成，即系统的各子系统部署在不同计算机上。
3、解决问题不同
微服务架构：微服务解决的是系统复杂度问题： 一般来说是业务问题，即在一个系统中承担职责太多了，需要打散，便于理解和维护，进而提升系统的开发效率和运行效率，微服务一般来说是针对应用层面的。微服务如果用在其它系统，如存储系统感觉怪怪的，就像说Mysql集群是微服务的，总觉得哪里不舒服。
分布式架构：分布式解决的是系统性能问题： 即解决系统部署上单点的问题，尽量让组成系统的子系统分散在不同的机器上进而提高系统的吞吐能力。

4、部署方式不同
微服务架构：微服务的应用可以部署在是同一个服务器，不一定是分散在多个服务器上。微服务架构是一项在云中部署应用和服务的新技术。微服务架构是一种架构模式，它将一个复杂的大型应用程序划分成多个微服务，这些小型服务都在各自独立的进程中运行。
分布式架构：分布式是将一个大的系统划分为多个业务模块,这些业务模块会分别部署到不同的机器上，通过接口进行数据交互。
5、耦合度不同
微服务相比分布式服务来说，它的粒度更小，服务之间耦合度更低，由于每个微服务都由独立的小团队负责，因此它敏捷性更高，分布式服务最后都会向微服务架构演化，这是一种趋势，不过服务微服务化后带来的挑战也是显而易见的，例如服务粒度小，数量大，后期运维将会很难。

3， 简单说说微服务怎么划分？

1：横向拆分： 按照不同的业务域进行拆分，例如订单、营销、风控、积分资源等。形成独立的业务领域微服务集群。

2：纵向拆分：把一个业务功能里的不同模块或者组件进行拆分。例如 把公共组件拆分成独立的原子服务，下沉到底层，形成相对独立的原子服务层。原则就是服务内高内聚，服务间低耦合。

4，说说微服务设计原则？

1，单一职责原则 ： 就是每个微服务只需要独立完成自己的业务，订单模块，只需要处理订单逻辑。

2，服务自治原则：意思是每个微服务从开发、测试、运维都是独立的，包括数据库也是独立的，自已就有一套完整的流程，我们完全可以把他当成一个项目。

3，轻量级别通信原则

首先是通信的语言都是轻量，改通信方式需要跨语言、跨平台的，之所以跨平台、跨语言为了让每个微服务都有独立性。

4，接口明确原则； 由于微服务之间可能存在了调用关系，为了尽量避免以后由于某个微服务的接口变化而到致其他微服务改变。

5，简单说说微服务是如何通讯的？

 答案： 1.Http/rest api : 这是最常见的方式之一，微服务通过http协议提供接口，其他微服务通过发送http 请求来进行交互，通常使用json 等格式来传输数据，例如：springCloud  feign

Feign是一个声明式的Web Service客户端,以Java接口注解的方式调用Http请求。同时Feign整合了Ribbon和Hystrix，实现负载均衡与容断功能。

2， RPC （远程过程调用） 如果grpc ，他提供了更高效、强类型的通讯机制，适合对性能要求较高的场景。传输字节格式，所有传输快。

3消息队列：如 RabbitMQ、Kafka 等。服务可以将消息发送到消息队列中，其他服务订阅相应的队列来获取消息，实现异步通讯和解耦。

4 分布式事件总线：微服务可以发布和订阅事件，通过事件的传播来触发其他服务的相应动作。

考虑因素：

1. 性能需求：如果对通信延迟和吞吐量有较高要求，RPC 或高效的消息队列协议可能更合适；若性能要求不那么极致，HTTP/REST 通常也能满足。
2. 复杂性：HTTP/REST 相对简单，易于开发和调试；RPC 可能需要更多的配置和理解。
3. 数据格式：如对数据的紧凑性、可读性等有要求，不同协议支持的序列化格式（如 JSON、Protobuf 等）需考虑。
4. 异步需求：若需要大量异步交互，消息队列协议可能是更好的选择。
5. 跨语言支持：确保协议能在多种开发语言中方便地实现和集成。
6. 生态系统和工具支持：相关协议的周边工具、框架是否丰富和成熟。
7. 可扩展性：考虑随着系统发展，协议是否能灵活适应新的需求和变化。
8. 安全需求：某些协议可能在安全特性和实现上有优势。

简述微服务各个组件的作用？

服务注册中心：

• 集中管理微服务实例的信息，包括服务的名称、地址、端口等，使其他服务能够方便地发现和调用目标服务。

API 网关：

• 作为系统的统一入口，接收外部请求并进行路由分发到相应的微服务。
• 可以进行请求的鉴权、限流、熔断等操作，提供统一的对外接口。

配置中心：

• 集中管理微服务的配置信息，方便进行配置的动态更新和管理，确保各服务获取到一致的配置。

服务发现客户端：

• 微服务自身使用的组件，用于与服务注册中心交互，获取其他服务的信息，实现服务之间的动态调用。

消息队列：

• 实现服务之间的异步通信和解耦，缓冲消息，提高系统的可靠性和灵活性。

数据库：

• 用于存储微服务相关的数据，为服务提供数据持久化支持。

缓存：

• 加速数据的访问，提高系统性能。

监控组件：

• 监控微服务的运行状态、性能指标等，以便及时发现问题和进行优化。

日志组件：

• 收集和管理微服务产生的日志，方便进行问题排查和分析。

简述什么是服务注册与发现 ？ 

服务注册与发现是微服务架构中的重要机制。

服务注册指的是各个微服务在启动或运行过程中，将自身的相关信息（如服务名称、实例地址、端口等）主动向一个集中的服务注册中心进行登记。

服务发现则是其他微服务能够通过查询服务注册中心，获取到已注册服务的详细信息，从而知道如何与这些服务进行通信和交互。通过这种方式，微服务可以动态地感知到其他服务的存在和状态变化，实现服务之间的自动连接和协调工作。它使得微服务架构具有更好的灵活性、动态性和可扩展性，能够适应服务的动态部署、伸缩等情况，降低了服务之间的耦合度，提高了整个系统的可靠性和运维效率。

请列举常用的服务注册发现的组件 ？举例

以下是一些常用的服务注册与发现组件：

1. Eureka：由 Netflix 开源，是比较经典的服务注册发现组件。
2. ZooKeeper：虽然不是专门为服务注册发现设计，但常被用于该场景。
3. Nacos：阿里巴巴开源的动态服务发现、配置管理和服务管理平台。

请列举常用的服务调用组件 ？

1. RestTemplate：在Spring Cloud中，RestTemplate是用于进行HTTP请求的模板类，可以用来调用RESTful风格的Web服务。
2. Feign：Feign是一个声明式的Web Service客户端，它使得编写HTTP客户端变得更简单。Feign会自动根据接口定义来生成HTTP请求代码。
3. OpenFeign：OpenFeign是Feign的继任者，它提供了更强大的功能，例如负载均衡和服务发现等。
4. Dubbo：Dubbo是一个高性能、轻量级的开源Java RPC框架，它提供了远程过程调用（RPC）功能。Dubbo可以用来调用其他服务，并提供了负载均衡、容错和路由等功能。
5. gRPC：gRPC是一个高性能、开源的RPC框架，它提供了面向接口的通信、双向流式传输和头部压缩等功能。gRPC支持多种语言，包括Java、Go和C++等。

这些服务调用组件可以帮助开发人员实现分布式系统中的服务间通信和调用。不同的组件具有不同的特性和适用场景，开发人员可以根据具体需求选择合适的组件。

 

简述什么服务降级 ？

服务降级指的是在系统面临高并发、资源紧张、故障等异常情况时，为了保证核心功能的可用性和稳定性，主动采取一些策略来降低非核心功能的服务质量或暂时关闭部分功能。

比如，原本一个服务可能提供丰富详细的信息，但在降级状态下可能只返回简化的数据甚至直接返回预设的友好提示，而不是进行复杂的业务处理或耗时的操作。或者停止一些不太重要的服务接口，以确保关键业务流程不受影响。这样可以避免整个系统因局部问题而崩溃，将影响范围尽量缩小，等情况好转后再逐步恢复正常服务水平。服务降级是一种应对系统异常情况的有效手段，有助于提升系统的容错能力和可靠性。

解决办法：

熔断机制是一种应对服务雪崩效应的微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。当检测到该节点微服务调用响应正常后，恢复调用链路。

在微服务架构中，一个应用可能会有多个微服务组成，微服务之间的数据交互通过远程过程调用完成。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”

在微服务架构中，熔断机制是一种应对服务雪崩效应的保护机制。当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回错误的响应信息。

简述熔断有哪几种状态 

当检测到该节点微服务响应正常后恢复调用链路，在 Spring Cloud 框架机制通过 Hystrix 实现，Hystrix 会监控微服务间调用的状况，当失败的调用到一个阈值，缺省是 5 秒内 20 次调用失败就会启动熔断机制。

发生熔断后，熔断通常有三种状态：关闭、开启和半开。

关闭状态（Closed）：服务正常状态下是关闭的，这时需要一个计数器来记录调用失败的次数和总的请求次数，如果在某个时间窗口内，失败的失败率达到预设的阈值，则切换到断开状态，此时开启一个超时时间，当到达该时间则切换到半关闭状态，该超时时间是给了系统一次机会来修正导致调用失败的错误，以回到正常的工作状态。

开启状态（Open）：服务宕机状态下是开启的，在这种状态下，后续的请求将不会真正发起请求，而是在调用方直接返回错误。

半开状态（Half-Open）：熔断状态为开启状态，并且超过设置的时间；这时状态有开启转换为半开状态。在半开状态下，允许少量的请求会访问到发生异常的服务里，如果有响应结果，熔断状态转换为关闭状态，如果没有结果，则继续为开启状态。

熔断机制在《Spring Cloud 极简入门》中有详细的解释，熔断机制是对服务调用链路的保护机制，如果链路上的某个服务不可访问，调用超时，发生异常等，服务会进行发熔断，触发降级返回托底数据。简单理解就是当服务器不可访问，可以返回一些预先准备好的兜底数据给用户，比如友好的提示信息，不至于直接向客户抛出异常。

简单描述降级,熔断, 限流区别 ？

以下是降级、熔断和限流的简单区别描述：

降级：

• 主动行为，通常是根据系统的整体情况，有选择性地降低某些非关键服务的功能或质量，以保障核心服务的正常运行。

熔断：

• 主要针对调用链路上某个服务出现故障或异常情况时，自动切断对该服务的调用，防止故障蔓延，类似电路中的保险丝。

限流：

• 主要是限制进入系统的流量或请求数量，目的是避免系统因瞬间高流量而崩溃或性能严重下降，是一种预防措施。

总的来说，降级是对服务自身的调整，熔断是对故障服务的隔离处理，限流是对整体流量的把控。它们都是保障系统稳定性和可用性的不同手段。

简述什么是限流 ？

限流指的是限制系统在特定时间段内处理的请求数量或流量。

其主要目的是为了防止系统在短时间内承受过大的负载，避免因流量暴增而导致系统性能下降、崩溃或无法正常提供服务。通过对请求进行数量上的限制，可以确保系统资源能够合理地分配给各个请求，维持系统的稳定性和可靠性。

限流可以基于多种策略来实现，比如固定数量限流（设定每秒或每分钟允许的最大请求数）、滑动窗口限流、令牌桶算法限流、漏桶算法限流等。同时，限流通常会结合一些处理方式，如直接拒绝超出限制的请求，或者将其放入队列等待处理等。(

springcloud alibaba 限流 使用 Sentinel的限流规则) 在需要限流的方法使用注解

@SentinelResource(value = "test", blockHandler = "handleException")当触发限流调用方法

public String handleException(BlockException ex) {

return "Error: " + ex.getClass().getSimpleName();

}

当资源的响应时间变长时，线程将开始被占用。当线程数累积到一定数量时，新的传入请求将被拒绝。反之亦然，当资源恢复并变得稳定时，占用的线程也将被释放，新请求将被接受。

除了限制并发性外，Sentinel可以根据响应时间降级不稳定资源也是保证可靠性的有效方法。当资源的响应时间太大时，将在指定的时间窗口中拒绝所有对该资源的访问。-- 熔断机制

此外，Sentinel支持的熔断降级维度更多，可对多种指标进行流控、熔断，且提供了实时监控和控制面板，功能更为强大。

简述下服务网关？

服务网关是处于系统边界上的一个组件，主要具有以下作用：

它作为系统的统一入口，所有外部请求先到达服务网关。服务网关可以对这些请求进行路由分发，将请求准确地转发到对应的微服务实例上。它还能进行一系列的处理，比如请求的鉴权，验证请求者是否有合法权限访问相关服务；进行限流操作，控制进入系统的流量；进行熔断处理，当某些后端服务出现故障时进行相应策略处理；对请求和响应进行必要的转换和适配；提供统一的对外接口，隐藏内部微服务的细节和复杂性等。服务网关使得整个微服务架构在对外交互上更加有序、安全和可管理。