微服务常见面试题

1.简述什么是微服务

微服务是一种软件架构风格，它将一个大型的应用程序拆分成一组小型的、独立的服务，每个服务都运行在自己的进程中，并通过轻量级的通信机制进行交互。

一、核心特点

1.独立部署

每个微服务都是一个独立的应用程序，可以独立地进行开发、测试和部署。这意味着开发团队可以根据每个服务的需求选择不同的技术栈，并且可以独立地对某个服务进行升级或扩展，而不会影响其他服务。
例如，一个电商平台可以将用户服务、商品服务、订单服务等拆分成不同的微服务。如果需要对用户服务进行升级，只需要部署用户服务的新版本，而商品服务和订单服务可以继续运行旧版本，不会受到影响。

2.松耦合

微服务之间通过定义良好的接口进行通信，服务之间的耦合度很低。这种松耦合使得各个服务可以独立地进行开发和维护，一个服务的修改不会影响其他服务。
例如，商品服务和订单服务之间通过接口进行交互，如果商品服务的数据库结构发生了变化，只要接口不变，订单服务就不需要进行修改。

3.高内聚

每个微服务都专注于完成一个特定的业务功能，具有高内聚性。这使得服务的代码更加易于理解和维护，同时也提高了开发效率。
比如，用户服务专门负责用户的注册、登录、信息管理等功能，商品服务专门负责商品的展示、库存管理等功能。

2.简述分布式和微服务的区别

分布式和微服务的区别主要有以下几点：

一、定义

• 分布式是由一组通过网络通信协作的计算机节点组成的系统，强调任务分解到多个节点处理。
• 微服务是将应用拆分成小型独立服务，每个服务运行在自己进程中并通过轻量级通信机制交互。

二、架构特点

• 分布式系统架构复杂，需考虑数据一致性等问题，如数据一致性、分布式事务、故障恢复等，可能采用多种技术模式。
• 微服务强调服务独立性和自治性，采用轻量级通信机制及服务注册发现等技术。

三、技术实现

• 分布式可能需专门框架，配置管理复杂。
• 微服务可使用多种工具，强调自动化部署管理，常借助容器化和编排工具。

四、开发维护

• 分布式开发维护难度大，需专业团队。
• 微服务相对容易，可独立开发测试部署，适合敏捷开发。

3.简述微服务的服务划分原则

微服务的服务划分原则如下：

一、业务功能单一原则

每个微服务专注特定业务功能，高内聚，便于理解维护和独立部署。

二、数据独立性原则

各微服务有独立数据存储，不直接共享数据库，降低耦合度且利于扩展。

三、可扩展性原则

划分时考虑服务可轻松应对业务增长变化，能水平或垂直扩展以提高性能。

四、技术独立性原则

各微服务可根据业务需求选合适技术栈，充分利用技术优势并提高开发效率。

五、可维护性原则

划分要考虑服务易理解、测试、调试，降低维护成本，提高系统稳定性。

4.简述微服务设计原则

微服务设计原则如下：

一、单一职责原则

每个微服务应该只负责一项单一的业务功能，具有高度的内聚性。这样可以使微服务的代码更易于理解、维护和扩展。例如，一个电商系统可以将用户管理、商品管理、订单管理等功能分别拆分成不同的微服务，每个微服务专注于自己的特定任务。

二、服务自治原则

每个微服务应该是独立自治的，能够独立部署、升级和扩展，而不影响其他微服务。这意味着微服务应该有自己独立的代码库、数据库和运行环境。例如，一个微服务的升级不应该导致其他微服务的停机或需要重新部署。

三、轻量级通信原则

微服务之间应该使用轻量级的通信机制，如 HTTP、gRPC 等，避免使用复杂的分布式通信协议。轻量级通信机制可以提高系统的性能和可扩展性，同时也降低了系统的复杂性。例如，使用 RESTful API 进行微服务之间的通信，可以方便地实现跨语言和平台的交互。

四、独立性原则

微服务应该尽可能地独立于其他微服务，减少服务之间的依赖关系。这可以通过将业务功能拆分成独立的微服务来实现，每个微服务只依赖于自己的内部状态和外部接口。例如，一个商品微服务不应该直接依赖于用户微服务的数据库，而应该通过用户微服务提供的 API 来获取用户信息。

五、可扩展性原则

微服务应该易于扩展，能够根据业务需求的变化进行快速的扩展和收缩。这可以通过使用容器化技术和自动化部署工具来实现，使得微服务可以轻松地在不同的环境中进行部署和扩展。例如，使用 Kubernetes 等容器编排工具可以方便地管理和扩展微服务集群。

六、高可用性原则

微服务应该具有高可用性，能够在出现故障时快速恢复服务。这可以通过使用冗余部署、自动故障转移和负载均衡等技术来实现，确保系统的稳定性和可靠性。例如，使用多个副本的微服务实例可以提高系统的可用性，当一个实例出现故障时，其他实例可以继续提供服务。

七、数据管理原则

每个微服务应该管理自己的数据，避免共享数据库。这可以通过使用独立的数据库或数据存储来实现，每个微服务只负责自己的数据存储和管理。例如，一个用户微服务可以使用自己独立的数据库来存储用户信息，而商品微服务可以使用自己独立的数据库来存储商品信息。

八、持续集成和持续部署原则

微服务架构应该采用持续集成和持续部署的开发模式，确保代码的质量和稳定性。这可以通过使用自动化构建、测试和部署工具来实现，使得开发人员可以快速地将代码集成到主干分支，并部署到生产环境中。例如，使用 Jenkins 等持续集成工具可以自动化地进行代码构建、测试和部署。

5.简述微服务之间如何通信的

微服务之间通信方式主要有：

一、同步通信

1、HTTP/RESTful API：简单易用，跨平台和语言无关，如微服务 A 向微服务 B 发送 HTTP 请求获取信息。
2、gRPC：高效的 RPC 框架，支持多种语言，如微服务 C 调用微服务 D 的远程方法。

二、异步通信

1、消息队列：解耦依赖关系，提高可扩展性和容错性，如微服务 E 处理任务后发消息到队列，微服务 F 订阅处理。
2、事件驱动架构：增强解耦性和灵活性，实现实时事件响应，如微服务 G 发布事件，微服务 H 订阅并响应。

6.简述微服务中各组件的作用

微服务主要组件及作用如下：

一、服务注册与发现组件

• 服务注册：微服务启动时将信息注册到中心。
• 服务发现：微服务查询中心以找到目标服务，地址变化时能及时通知。

二、API 网关

• 统一入口：为客户端提供统一入口，隐藏内部细节。
• 路由转发：根据请求转发到相应微服务。
• 负载均衡：分发请求到多个服务实例。
• 安全认证：对请求进行认证和授权。
• 限流熔断：防止系统过载和故障扩散。

三、配置中心

• 集中管理配置：统一存储微服务配置信息。
• 动态更新配置：变化时实时通知微服务更新。
• 版本管理：方便回滚到历史版本配置。

四、服务监控与日志组件

• 监控服务状态：监测指标，及时发现问题。
• 日志收集与分析：收集分析日志，排查故障和优化性能。
• 报警通知：异常时通知管理员处理。

7.什么是服务注册与发现

服务注册与发现是微服务架构中的重要机制。服务注册是微服务启动时将自身信息上报给服务注册中心；服务发现是其他微服务或调用者向注册中心查询目标服务地址信息。目的是动态获取服务位置，提高系统灵活性、可扩展性、可靠性和可维护性。

8.常用服务注册发现的组件

常用服务注册与发现组件有：

• Consul：支持多数据中心，有服务发现、健康检查等功能，适用于大规模分布式系统。
• Eureka：Netflix 开源，适用于 Java 微服务架构，有自我保护机制。
• Zookeeper：分布式协调服务，可用于服务注册与发现，保证数据一致性，常用于高一致性要求系统。
• Nacos：支持动态服务发现、配置管理等，适用于云原生微服务架构。

9.什么是服务降级

服务降级是在系统面临高负载、故障或资源紧张时，为保证核心功能可用性，对非核心功能进行限制或关闭的机制。
触发场景包括系统高负载、故障发生、资源紧张。实现方式有开关降级、返回默认值、简化功能。作用是保证核心功能可用性、提高系统性能、增强容错能力。

10.什么是熔断机制

熔断机制是分布式系统中应对服务故障的保护机制。原理是监控服务调用，当错误率高或响应时间长时触发，中断对服务的调用。有关闭、打开、半打开三种状态。作用是防止故障扩散、提升系统稳定性、自动恢复服务调用。

11.熔断有几种状态

状态转换

1、关闭状态

初始状态，服务正常运行，对服务的调用正常进行。

2、打开状态

当触发熔断条件后，进入打开状态，此时不再调用目标服务，而是直接返回预设的错误响应或者执行降级逻辑。

3、半打开状态

经过一段时间后，系统会尝试部分请求去探测目标服务是否恢复正常。如果这些请求成功，熔断机制回到关闭状态，恢复对服务的正常调用；如果请求仍然失败，则再次进入打开状态。

12.服务熔断原理（断路器的原理）

服务熔断的原理就如同电路中的断路器一样，主要是为了在系统出现故障时及时切断对故障服务的调用，防止故障进一步扩散，从而提升整个系统的稳定性和可靠性。

服务熔断原理类似断路器。系统持续监控服务调用的指标，如请求数量、响应时间、错误率等，并设定阈值。当错误率过高或响应时间超阈值时触发熔断。熔断有关闭、打开、半打开三种状态。关闭时正常调用服务；打开时中断请求，返回预设错误响应；半打开时部分请求探测服务是否恢复。有自动恢复和人工干预两种恢复机制。

13.降级、熔断、限流的区别

降级、熔断、限流都是保障系统稳定性的手段，区别如下：

一、定义与目的

降级：系统面临问题时对非核心功能限制或关闭，保核心业务，如电商大促关非核心服务保订单处理。
熔断：服务高错误率或响应长时中断调用防故障扩散，如支付服务故障时停止调用。
限流：限制系统资源访问速率防被压垮，如限制每秒处理请求数。

二、触发条件

降级：系统高负载、故障、资源紧张等，如服务器内存超 80%。
熔断：服务调用错误率超阈值或响应超时，如连续 50% 请求失败。
限流：请求速率超设定上限，根据系统处理能力和资源定。

三、实现方式

1、降级
开关降级：通过配置开关来控制服务的启用和禁用。
返回默认值：对于一些非关键请求，直接返回默认值而不进行复杂的处理。
简化功能：对服务进行功能简化，只提供最基本的功能。
2、熔断
断路器模式：类似于电路中的断路器，当故障发生时，立即断开连接，经过一段时间后尝试恢复连接。
快速失败：一旦检测到故障，立即返回错误信息，不再进行后续的调用。
3、限流
令牌桶算法：以固定的速率向桶中放入令牌，请求需要获取令牌才能被处理，当桶中没有令牌时，请求被拒绝。
漏桶算法：请求像水一样流入漏桶，漏桶以固定的速率流出请求，当流入速度大于流出速度时，多余的请求被拒绝。

四、作用范围

降级：非核心功能或服务，可单个或多个组合。
熔断：特定服务调用，防故障扩散。
限流：整个系统或特定资源。

14.什么是限流

限制对系统资源的访问速率，防止系统被过多的请求压垮。
确保系统在可承受的负载范围内运行，避免因突发的高流量导致系统性能下降或崩溃。例如，限制每秒只能处理 1000 个用户请求。
限流的实现
令牌桶算法：以固定的速率向桶中放入令牌，请求需要获取令牌才能被处理，当桶中没有令牌时，请求被拒绝。
漏桶算法：请求像水一样流入漏桶，漏桶以固定的速率流出请求，当流入速度大于流出速度时，多余的请求被拒绝。

15.如何保障微服务通信安全

保障微服务通信安全可从以下方面入手：

一、传输层安全

用 TLS/SSL 加密协议，如 HTTPS。
管理数字证书确保身份真实。

二、身份认证与授权

对调用者进行身份认证，如用户名 / 密码、OAuth2、JWT 等。
基于认证进行授权，确定访问资源和操作权限。

三、安全通信协议

选择安全协议如 gRPC 或 HTTP/2。
对敏感消息加密。

四、网络隔离与访问控制

网络隔离，如用 VPN、防火墙。
控制网络访问，用 ACL 或防火墙规则。

五、安全监控与审计

实时监控通信，检测异常和安全事件。
记录通信和操作日志，便于审计和故障排查。定期安全评估和漏洞扫描。

16.什么是服务网关

服务网关在微服务架构中作用关键：
统一入口：为外部提供统一入口，隐藏内部微服务细节，降低系统复杂性。
路由转发：根据请求信息准确转发到对应微服务。
负载均衡：将请求均衡分发到多个微服务实例，提高性能和可用性。
安全认证与授权：对外部请求进行安全认证和授权，提高安全性。
限流与熔断：限流防止系统被压垮，熔断在服务故障时防止故障扩散，保障系统稳定性和可靠性。

17.什么是API网关

API 网关是微服务架构或分布式系统的边界组件。作用包括：
统一入口：为外部提供唯一访问点，隐藏内部细节，降低耦合度。
路由转发：根据请求信息准确转发到对应微服务。
负载均衡：将请求均衡分发到多个微服务实例。
安全防护：进行安全认证、授权和加密等操作。
限流熔断：保障系统稳定性，避免崩溃。
协议转换：提高兼容性和灵活性。总之，API 网关可提高系统可维护性、安全性、性能和可用性。

18.服务网关的基本功能

统一入口：为外部提供唯一访问点，隐藏内部细节，降低耦合度。
路由转发：根据请求信息准确转发到对应微服务。
负载均衡：将请求均衡分发到多个微服务实例。
安全防护：进行安全认证、授权和加密等操作。
限流熔断：保障系统稳定性，避免崩溃。
协议转换：提高兼容性和灵活性。总之，API 网关可提高系统可维护性、安全性、性能和可用性。

19.市面常用的微服务框架

市面上常用微服务框架有：
Spring Cloud：基于 Spring Boot，提供整套方案，社区活跃，适用于 Java 企业级应用。
Dubbo：阿里开源，主要做服务治理，性能高，适合大规模分布式系统。
Istio：开源服务网格框架，功能强大，与 Kubernetes 集成好，适用于云原生环境。
Kubernetes Service Mesh：基于 Kubernetes，与平台结合紧密，用于 Kubernetes 环境微服务部署。
Apache ServiceComb：华为开源，支持多语言，高可用，适用于多语言混合开发项目。

20.目前的主流服务网关有哪些

目前主流服务网关有：
Spring Cloud Gateway：基于 Spring 生态，性能高，支持路由、过滤、限流等，适用于 Spring 技术栈微服务架构。
Kong：功能强大可扩展，支持插件，性能出色，适用于大型企业级应用。
Zuul：Spring Cloud 生态组件，易配置，支持过滤器，适合中小规模微服务架构。
Traefik：自动发现服务，配置简单，支持多种后端，适用于容器化和云原生环境微服务部署。

21.简述SpringCloud Alibaba的整体架构

Spring Cloud Alibaba 是一套基于 Spring Cloud 的微服务解决方案，其整体架构如下：

一、服务发现与注册中心

Nacos
承担服务注册与发现的功能，微服务在启动时将自己的信息注册到 Nacos 中，其他服务可以通过 Nacos 发现并调用这些服务。
同时也可以作为配置中心，集中管理微服务的配置信息。

二、服务调用与负载均衡

OpenFeign
基于声明式的 HTTP 客户端，方便微服务之间进行调用。
结合 Ribbon 实现负载均衡，将请求分发到不同的服务实例上。

三、服务容错与降级

Sentinel
实现流量控制、熔断降级、系统负载保护等功能。
可以对服务的调用进行实时监控，当出现异常情况时，自动进行熔断或降级操作，保证系统的稳定性。

四、分布式事务

Seata
解决分布式系统中的事务问题，确保在多个服务之间的数据一致性。

五、消息驱动

RocketMQ
提供可靠的消息队列服务，实现异步通信和解耦。
微服务可以通过发送和接收消息来进行交互，提高系统的灵活性和可扩展性。
总的来说，Spring Cloud Alibaba 提供了一系列组件，帮助开发者构建高可用、高性能的微服务架构，简化了分布式系统的开发和管理。

22.使用微服务架构时，你面临的挑战是什么

使用微服务架构面临以下挑战：

一、服务拆分与设计

确定边界难，需深刻理解业务，确保高内聚低耦合。
服务数量增多，管理复杂。

二、通信与集成

网络延迟与可靠性问题影响性能，需考虑重试、超时等策略。
保证多个服务操作同一数据时的一致性较难。

三、部署与运维

部署复杂，需自动化工具和流程，确保顺序和依赖正确。
监控困难，故障排查复杂。

四、技术选型与团队协作

技术多样性增加选型难度，需确保兼容性。
团队协作要求高，不同服务团队需密切配合。

23.阐述SOA和微服务架构之间的主要区别

SOA 和微服务架构主要区别如下：

一、设计理念

SOA：较重架构，有中央集成点 ESB，负责复杂集成任务。
微服务：轻量级、去中心化，无中央集成点，服务直接通信。

二、服务粒度

SOA：服务粒度较大，一个服务包含多个业务功能。
微服务：服务粒度小，专注单一业务功能。

三、技术选型

SOA：对技术栈有一定限制，需与 ESB 集成。
微服务：各服务可独立选技术栈，更灵活。

四、部署方式

SOA：整体部署，更新服务可能需全系统部署，依赖 ESB 较复杂。
微服务：每个服务可独立部署，速度快，影响小。

五、可扩展性

SOA：通过扩展 ESB 和增加服务实例实现，ESB 可能成瓶颈。
微服务：可根据每个服务负载独立扩展。

六、故障隔离性

SOA：一个服务故障可能影响整个系统，隔离难。
微服务：一个微服务故障影响小，隔离性好。

24.什么是幂等性

幂等性指操作无论执行多少次效果都与只执行一次相同。在编程和分布式系统中很重要，比如网络不稳定或重试机制下，避免重复请求导致问题。在微服务架构和分布式事务中，若操作不幂等可能影响业务流程和数据一致性。实现幂等性可采用唯一标识符或状态机设计等方法。

25.容器在微服务中的用途是什么

容器在微服务中的用途如下：

一、封装与隔离

封装微服务及其依赖项，便于在不同环境部署运行，避免依赖冲突和环境差异。
提供隔离运行环境，不同微服务互不干扰，提高系统稳定性和可靠性。

二、快速部署与扩展

可快速部署，减少时间和成本。通过容器编排工具，能在几分钟内将微服务部署到多个节点。
能根据负载快速扩展，增加容器实例提高服务处理能力，容器编排工具可自动管理。

三、资源优化

高效利用资源，一台服务器可运行多个容器，提高资源利用率，降低硬件成本。
可对容器进行资源限制，防止某个微服务占用过多资源影响其他服务。

四、一致性与可移植性

确保微服务在不同环境一致性，减少因环境差异导致的问题。
具有可移植性，可在不同云平台、服务器或数据中心间轻松迁移。

26.微服务架构中的DRY是什么

在微服务架构中，DRY（Don’t Repeat Yourself，即不要重复自己）原则是一种重要的设计理念，主要体现在以下几个方面：

一、代码层面

避免重复代码，将通用功能封装成模块或服务供调用，提高开发效率和维护性。
实现代码复用，如对数据库访问、日志记录等通用功能创建独立库或工具类。

二、数据存储层面

避免重复存储数据，如多个服务需用户信息时，存储在独立服务中供调用。
采用数据共享与集成方式，如事件驱动架构，避免重复存储。

三、配置管理层面

集中配置管理，避免各服务重复配置，提高一致性和可维护性。
配置复用，如通用配置参数供多个服务复用。
总之，遵循 DRY 原则可提高微服务架构的可维护性、可扩展性和可靠性，降低成本。

27.什么是微服务中服务配置统一管理

在微服务架构中，服务配置统一管理是指将各个微服务的配置信息集中存储和管理，以便于配置的修改、更新和分发。主要包括以下几个方面：

一、集中存储

建立配置中心（如 Spring Cloud Config、Consul 等）或用数据库存储配置，微服务从其获取配置。

二、动态更新

支持实时更新，配置变化时可主动通知微服务或微服务定期拉取。还能进行版本管理，便于跟踪变化和回滚。

三、安全与权限管理

提供访问控制，确保授权用户才能访问和修改配置。对敏感信息加密处理。

四、优势

提高可维护性，方便配置修改和更新，便于版本控制和回滚。
增强灵活性，可根据不同环境获取不同配置，动态调整参数。
提高系统稳定性，及时获取最新配置，避免因配置不一致导致故障。

28.简述服务链路追踪以及实现机制

服务链路追踪是用于跟踪和监控分布式系统中请求在各个微服务之间的流转路径和性能指标的技术。

一、重要性

故障排查：在复杂的微服务架构中，当出现问题时，很难快速确定问题发生的位置。服务链路追踪可以帮助开发人员和运维人员快速定位故障点，了解请求在哪个服务出现了延迟、错误或异常。
性能优化：分析性能瓶颈。
了解系统行为：帮助理解架构和流程。

二、实现机制

生成唯一标识（Trace ID），在请求链路中传递关联服务调用。
记录调用信息，与 Trace ID 关联。
收集存储调用信息到专门数据存储。
可视化展示，直观呈现请求流转和性能指标。

29.如何保证微服务之间的通信可靠性

为了保证微服务之间的通信可靠性，可以采取以下措施：

一、选择合适的通信协议

1、HTTP/RESTful
2、gRPC

二、使用服务注册与发现机制

微服务在启动时，将自己的服务信息（如服务名称、IP 地址、端口号等）注册到服务注册中心。其他微服务通过查询服务注册中心，获取所需服务的地址信息，然后进行通信。
当服务的地址发生变化（例如服务实例的扩缩容、故障转移等），服务注册中心会及时通知依赖该服务的其他微服务，以保证通信的准确性。

三、实现重试机制

1、客户端重试

当微服务之间的通信出现错误时，客户端可以自动进行重试。例如，如果一个 HTTP 请求失败，可以设置重试次数和重试间隔时间，自动重新发送请求。
注意事项：需要考虑重试可能带来的副作用，如重复提交问题。可以通过使用唯一请求标识符或幂等性设计来避免重复提交。

2、服务端重试

在服务端，如果处理请求时出现暂时的错误（如数据库连接失败、网络超时等），可以返回适当的错误码，让客户端进行重试。同时，服务端也可以在内部进行重试，例如在数据库操作失败时，自动重新尝试执行数据库操作。

四、设置超时时间

设置合理的超时时间可以避免一个微服务的故障导致其他依赖它的微服务长时间等待，从而提高系统的整体可靠性和响应速度。

1、客户端超时设置

在发起请求时，客户端可以设置一个超时时间。如果在超时时间内没有收到响应，客户端可以中断请求并采取相应的处理措施，如重试或返回错误信息给用户。

2、服务端超时处理

服务端也应该设置处理请求的超时时间。如果一个请求在服务端处理时间过长，应该及时中断处理并返回错误信息，避免占用过多的资源。

五、进行负载均衡

负载均衡可以将请求分发到多个服务实例上，避免单个服务实例过载，提高系统的可用性和性能。

1、常见负载均衡策略

轮询：依次将请求分发到每个服务实例上。
随机：随机选择一个服务实例处理请求。
最少连接数：将请求分发到当前连接数最少的服务实例上。
加权轮询 / 加权随机：根据服务实例的权重进行请求分发，权重可以根据服务实例的性能、负载等因素进行设置。

2、实现方式

可以使用硬件负载均衡器（如 F5 Big-IP），也可以使用软件负载均衡器（如 Nginx、HAProxy），或者在客户端实现负载均衡逻辑。

六、监控和日志记录

1、监控
建立完善的监控系统，实时监测微服务之间的通信状态。可以监控指标如请求成功率、响应时间、错误率等。当出现通信问题时，能够及时发出警报，以便开发人员进行故障排查和处理。
例如，使用 Prometheus 和 Grafana 组合来监控微服务的通信指标，设置阈值，当指标超过阈值时触发警报。
2、日志记录
记录微服务之间的通信日志，包括请求和响应的详细信息、错误信息等。通过分析日志，可以了解通信过程中的问题，帮助进行故障诊断和性能优化。
可以使用日志聚合工具（如 ELK Stack）来集中收集和分析微服务的日志。