35 个你最有可能答不出来的微服务面试问题

Nginx 的一项调查显示，36% 的企业目前正在使用微服务，另有 26% 的企业正在研究如何实施微服务。阅读本文，复习一下你之前可能不知道如何回答的一些重要的微服务面试问题。

🔴 最初发表于FullStack.Cafe - Kill Your Tech & Coding Interview

Q1：持续集成是什么意思？

主题：DevOps
难度：⭐

持续集成 (CI)是一种开发实践，要求开发人员每天多次将代码集成到共享存储库中。每次签入都会通过自动构建进行验证，从而使团队能够及早发现问题。

🔗资料来源： edureka.co

问题2：什么是Docker？

主题：Docker
难度：⭐

• Docker 是一个容器化平台，它将您的应用程序及其所有依赖项以容器的形式打包在一起，以确保您的应用程序在任何环境中（无论是开发、测试还是生产）都能无缝运行。
• Docker 容器将软件包装在一个完整的文件系统中，其中包含运行所需的一切：代码、运行时、系统工具、系统库等可以在服务器上安装的任何东西。
• 这保证了软件无论在何种环境下都能始终以相同的方式运行。

🔗资料来源： edureka.co

Q3：容器化是什么意思？

主题：DevOps
难度：⭐⭐

容器化是一种虚拟化策略，它是传统基于虚拟机管理程序的虚拟化的替代方案。

在容器化中，操作系统由不同的容器共享，而不是为每个虚拟机克隆。例如，Docker 提供了一个容器虚拟化平台，可以作为基于虚拟机管理程序的良好替代方案。

🔗来源： linoxide.com

Q4：定义微服务架构

主题：微服务
难度：⭐⭐

微服务，又称 微服务架构，是一种架构风格，它将应用程序构建为围绕业务领域建模的小型自主服务集合 。

🔗资料来源： lambdatest.com

Q5：解释蓝绿部署技术

主题：DevOps
难度：⭐⭐⭐

蓝绿部署是一种通过运行两个完全相同的生产环境（分别称为“蓝”和“绿”）来减少停机时间和风险的技术。在任何时候，只有一个环境处于活动状态，并且活动环境负责处理所有生产流量。在本例中，蓝环境当前处于活动状态，而绿环境处于空闲状态。

在准备新版本的软件时，部署和最终测试阶段会在非上线环境（在本例中为绿环境）中进行。在绿环境中部署并全面测试软件后，您可以切换路由器，使所有传入请求都转到绿环境而不是蓝环境。此时绿环境已上线，蓝环境处于空闲状态。

这种技术可以消除应用程序部署造成的停机时间。此外，蓝绿部署还可以降低风险：如果绿部署中的新版本出现意外，您可以立即切换回蓝部署，回滚到上一个版本。

🔗来源： cloudfoundry.org

问题 6：蓝绿部署和滚动部署有什么区别？

主题：DevOps
难度：⭐⭐⭐

• 在蓝绿部署中，您拥有两个完整的环境。
  一个是正在运行的蓝环境，另一个是您想要升级到的绿环境。一旦您将环境从蓝环境切换为绿环境，流量就会被引导到新的绿环境。您可以删除或保存旧的蓝环境以进行备份，直到绿环境稳定为止。

• 在滚动部署中，您只有一个完整的环境。代码会部署在同一环境的实例子集中，完成后再迁移到另一个子集中。

🔗来源： stackoverflow.com

Q7：持续集成、持续交付、持续部署有什么区别？

主题：DevOps
难度：⭐⭐⭐

• 实践持续集成的开发人员会尽可能频繁地将更改合并回主分支。这样做可以避免人们等到发布日才将更改合并到发布分支时经常发生的集成困境。
• 持续交付是持续集成的扩展，旨在确保您能够以可持续的方式快速向客户发布新的变更。这意味着，除了自动化测试之外，您还可以自动化发布流程，并且只需单击按钮即可随时部署应用程序。
• 持续部署比持续交付更进一步。通过这种实践，所有通过生产流程各个阶段的变更都会发布给客户。无需人工干预，只有测试失败才会阻止新的变更部署到生产环境中。

🔗资料来源： atlassian.com

Q8：你对无服务器模型了解多少？

主题：DevOps
难度：⭐⭐⭐

无服务器是指服务器的存在对开发人员隐藏的模型。这意味着您不再需要处理容量、部署、扩展、容错和操作系统等问题。这将从根本上减少维护工作量，使开发人员能够快速专注于代码开发。

例如：

• 亚马逊 AWS Lambda
• Azure 函数

🔗来源： linoxide.com

Q9：微服务的特点是什么？

主题：微服务
难度：⭐⭐⭐

• 解耦 ——系统内的服务在很大程度上是解耦的。因此，整个应用程序可以轻松构建、修改和扩展。
• 组件化 ——微服务被视为独立组件，可以轻松替换和升级
• 业务能力 ——微服务非常简单，专注于单一功能
• 自主性 ——开发人员和团队可以彼此独立工作，从而提高速度
• 持续 交付 ——通过软件创建、测试和批准的系统自动化，允许频繁发布软件
• 责任 ——微服务并不将应用程序视为项目。相反，它们将应用程序视为产品，并对其负责。
• 去中心化治理 ——重点在于使用合适的工具完成合适的工作。这意味着没有标准化的模式或任何技术模式。开发人员可以自由选择最实用的工具来解决他们的问题。
• 敏捷性 ——微服务支持敏捷开发。任何新功能都可以快速开发并再次弃用

🔗资料来源： lambdatest.com

Q10：微服务架构如何工作？

主题：微服务
难度：⭐⭐⭐

• 客户端 – 来自不同设备的不同用户发送请求。
• 身份提供者 ——验证用户或客户端身份并颁发安全令牌。
• API 网关 ——处理客户端请求。
• 静态内容 ——包含系统的所有内容。
• 管理 ——平衡节点上的服务并识别故障。
• 服务发现 ——查找微服务之间通信路线的指南。
• 内容分发网络 ——代理服务器及其数据中心的分布式网络。
• 远程服务 – 支持远程访问 IT 设备网络上的信息。

🔗资料来源： edureka.co

Q11：单体架构、SOA 架构和微服务架构之间有什么区别？

主题：微服务
难度：⭐⭐⭐

• 单片架构类似于一个大容器，其中应用程序的所有软件组件都组装在一起并紧密打包。
• 面向服务架构 ( SOA )是一系列相互通信的服务的集合。通信可以是简单的数据传递，也可以是两个或多个服务协调某项活动。
• 微服务架构是一种架构风格，它将应用程序构建为围绕业务领域建模的小型自主服务的集合。

🔗资料来源： edureka.co

Q12：微服务和单片架构的主要区别是什么？

主题：微服务
难度：⭐⭐⭐

微服务

• 服务启动很快
• 微服务是松散耦合的架构。
• 在单个数据模型中所做的更改不会影响其他微服务。
• 微服务专注于产品，而不是项目

单体架构

• 服务启动需要时间
• 单片架构大多是紧密耦合的。
• 数据模型的任何变化都会影响整个数据库
• 整体强调整个项目

🔗资料来源： edureka.co

Q13：编排微服务的标准模式有哪些？

主题：微服务
难度：⭐⭐⭐

当我们开始对越来越复杂的逻辑进行建模时，我们必须处理跨越各个服务边界的业务流程的管理问题。

• 通过编排，我们依靠一个中央大脑来引导和驱动流程，就像管弦乐队中的指挥一样。编排风格更符合 SOA 的编排/任务服务理念。例如，我们可以将业务流程包装在其自己的服务中。代理会编排微服务之间的交互，如下图所示。

• 通过编排，我们告知系统的每个部分其职责，并让它们自行处理细节，就像芭蕾舞中的舞者找到自己的方向并与周围的其他人互动一样。编排风格与 Martin Fowler 提到的“哑管道”和“智能端点”相对应。这种方法也称为领域方法，它使用领域事件，每个服务都会发布与已发生的事情相关的事件，其他服务可以订阅这些事件。

🔗来源： stackoverflow.com

Q14：什么是智能端点和哑管道？

主题：微服务
难度：⭐⭐⭐

• 智能端点只是意味着实际的业务规则和任何其他验证都发生在这些端点后面，而这些端点的消费者对这些端点的任何人都不可见，可以将其视为实际发生魔法的地方。

• 哑管道是指任何不进行进一步操作（例如验证）的通信方式，它只是在特定通道上传输数据，并且如果需要，它也可以替换。所选的基础设施通常是哑的（哑是指仅充当消息路由器）。这只是意味着路由是管道应该执行的唯一功能。

🔗来源： stackoverflow.com

Q15：您是否认为 GraphQL 适合设计微服务架构？

主题：微服务
难度：⭐⭐⭐

GraphQL 和微服务是完美的搭配，因为 GraphQL 向客户端隐藏了微服务架构的事实。从后端的角度来看，您希望将所有内容拆分成微服务，但从前端的角度来看，您希望所有数据都来自一个 API。使用 GraphQL 是我所知道的可以同时实现这两者的最佳方法。它允许您将后端拆分成微服务，同时仍然为所有应用程序提供单一 API，并允许跨不同服务的数据进行连接。

🔗来源： stackoverflow.com

Q16：容器与虚拟机有何不同？

主题：DevOps
难度：⭐⭐⭐⭐

• 与虚拟机不同，容器无需启动操作系统内核，因此可以在不到一秒的时间内创建容器。这一特性使得基于容器的虚拟化相较于其他虚拟化方法而言独一无二，且更具吸引力。
• 由于基于容器的虚拟化几乎不会给主机增加任何开销，因此基于容器的虚拟化具有接近原生的性能
• 对于基于容器的虚拟化，与其他虚拟化不同，不需要额外的软件。
• 主机上的所有容器共享主机的调度程序，从而节省了额外资源的需求。
• 容器状态（Docker 或 LXC 镜像）与虚拟机镜像相比体积较小，因此容器镜像易于分发。
• 容器中的资源管理是通过 cgroups 实现的。cgroups 不允许容器消耗超过分配给它们的资源。

🔗来源： stackoverflow.com

Q17：虚拟化在低层如何工作？

主题：Docker
难度：⭐⭐⭐⭐

VM 管理器接管了 CPU 的 Ring 0（在较新的 CPU 中称为“根模式”），并拦截了所有来自客户操作系统的特权调用，从而营造出客户操作系统拥有独立硬件的假象。有趣的是：1998 年之前，人们认为在 x86 架构中实现这一点是不可能的，因为根本就没有办法进行这种拦截。VMWare 的团队率先想到了通过重写内存中用于客户操作系统特权调用的可执行字节来实现这一点。

虚拟化的最终效果是，它允许你在同一硬件上运行两个完全不同的操作系统。每个客户操作系统都要经历引导、加载内核等所有过程。这样可以实现非常严格的安全性，例如，客户操作系统无法完全访问主机操作系统或其他客户操作系统，从而造成混乱。

🔗来源： stackoverflow.com

Q18：什么是半虚拟化？

主题：Docker
难度：⭐⭐⭐⭐

半虚拟化（也称为 1 型虚拟机管理程序）直接在硬件或“裸机”上运行，并直接向其上运行的虚拟机提供虚拟化服务。它帮助操作系统、虚拟化硬件和真实硬件协作以实现最佳性能。这些虚拟机管理程序通常占用空间较小，并且本身不需要大量资源。

此类别的示例包括 Xen、KVM 等。

🔗来源： stackoverflow.com

Q19：什么是幂等性？

主题：微服务
难度：⭐⭐⭐⭐

幂等性是指重复执行某项任务，但最终结果保持不变或相似的场景。

🔗资料来源： lambdatest.com

Q20：微服务架构的优缺点是什么？

主题：微服务
难度：⭐⭐⭐⭐

优点：

• 自由使用不同的技术
• 每个微服务专注于单一功能
• 支持单个可部署单位
• 允许频繁发布软件
• 确保每项服务的安全
• 多个服务并行开发和部署

缺点：

• 增加了故障排除的挑战
• 远程调用导致延迟增加
• 加大配置和其他操作的力度
• 交易安全难以维护
• 难以跨越不同边界追踪数据
• 服务之间难以编码

🔗资料来源： edureka.co

Q21：你对合同测试是如何理解的？

主题：微服务
难度：⭐⭐⭐⭐

根据 Martin Flower 的说法，契约测试是在外部服务边界进行的测试，用于验证其是否满足消费服务所期望的契约。

此外，契约测试不会深入测试服务的行为。相反，它测试服务调用的输入和输出是否包含必需的属性，以及响应延迟和吞吐量是否在允许的范围内。

🔗资料来源： edureka.co

Q22：架构师在微服务架构中扮演什么角色？

主题：微服务
难度：⭐⭐⭐⭐

微服务架构中的架构师扮演以下角色：

• 决定整个软件系统布局的大致轮廓。
• 帮助确定组件的区域划分。这样，它们就能确保组件之间相互衔接，但又不会紧密耦合。
• 与开发人员一起编写代码并了解日常生活中面临的挑战。
• 向开发微服务的团队推荐某些工具和技术。
• 提供技术治理，以便团队在技术开发中遵循微服务原则。

🔗资料来源： edureka.co

Q23：解释什么是 API 网关模式

主题：微服务
难度：⭐⭐⭐⭐

API网关是系统的唯一入口服务器。它类似于面向对象设计中的外观模式 (Facade)。API 网关封装了系统内部架构，并为每个客户端提供定制的 API。它可能还承担其他职责，例如身份验证、监控、负载均衡、缓存、请求调整和管理以及静态响应处理。

使用 API 网关的一大优势在于它封装了应用程序的内部结构。客户端无需调用特定的服务，只需与网关通信即可。

🔗来源： nginx.com

Q24：列举 API 网关的一些优点和缺点

主题：微服务
难度：⭐⭐⭐⭐

有一些：

• 使用 API 网关的一大优势在于它封装了应用程序的内部结构。客户端无需调用特定的服务，只需与网关通信即可。
• API 网关是另一个必须开发、部署和管理的高可用性组件。此外，API 网关还存在成为开发瓶颈的风险。
• 开发人员必须更新 API 网关才能公开每个微服务的端点。

🔗来源： nginx.com

Q25：什么是物化视图模式，何时使用它？

主题：微服务
难度：⭐⭐⭐⭐

物化视图模式是一种用于聚合来自多个微服务的数据的解决方案，用于实现从多个微服务检索数据的查询。在这种方法中，我们预先生成（在实际查询发生之前准备非规范化的数据）一个只读表，其中包含由多个微服务拥有的数据。该表的格式适合客户端应用或 API 网关的需求。

关键点是，物化视图及其包含的数据是完全可丢弃的，因为它可以从源数据存储中完全重建。

这种方法不仅解决了如何跨微服务查询和连接的问题，而且与复杂的连接相比，它还大大提高了性能，因为您已经在查询表中拥有应用程序所需的数据。

🔗资料来源： microsoft.com

Q26：什么是金丝雀发布？

主题：DevOps
难度：⭐⭐⭐⭐⭐

金丝雀发布是一种降低在生产环境中引入新软件版本风险的技术。它通过将变更缓慢地推广到一小部分用户，然后再将其发布到整个基础设施，即让所有人都可以使用。

🔗资料来源： edureka.co

Q27：梅尔文·康威所阐述的定律意味着什么？

主题：微服务
难度：⭐⭐⭐⭐⭐

康威定律适用于模块化软件系统，它指出：

“任何设计系统（这里的定义比信息系统更广泛）的组织都将不可避免地产生一种设计，其结构是该组织的通信结构的副本”。

🔗资料来源： lambdatest.com

Q28：说出 SOA 和微服务之间的主要区别？

主题：微服务
难度：⭐⭐⭐⭐⭐

• SOA 使用企业服务总线进行通信，而微服务使用更简单的消息传递系统。
• 每个微服务独立存储数据，而在 SOA 中组件共享相同的存储。
• 对于微服务，通常使用云，而对于 SOA，应用服务器更为常见。
• SOA 仍然是一个整体，为了进行更改，您需要更改整个架构。
• SOA 仅使用重量级技术和协议（如 SOAP 等），而微服务是一种更精简、更高效、更敏捷的方法（REST/GraphQL）。

🔗资料来源： quora.com

Q29：内聚和耦合有什么区别？

主题：微服务
难度：⭐⭐⭐⭐⭐

内聚性指的是类（或模块）能做什么。低内聚性意味着类会执行各种各样的操作——功能广泛，没有重点突出它应该做什么。高内聚性意味着类专注于它应该做的事情，即只包含与类的意图相关的方法。

至于耦合度，它指的是两个类/模块之间的关联性或依赖性。对于低耦合度的类，修改一个类中的某些重要内容不会影响另一个类。高耦合度会使代码的修改和维护变得困难；由于类之间联系紧密，因此修改代码可能需要整个系统重构。

好的软件设计具有高内聚性和低耦合性。

🔗资料来源： edureka.co

Q30：什么是消费者驱动合同（CDC）？

主题：微服务
难度：⭐⭐⭐⭐⭐

这基本上是一种开发微服务的模式，以便它们可以被外部系统使用。当我们开发微服务时，会有一个特定的提供者来构建它，并且会有一个或多个消费者使用微服务。

通常，服务提供者在 XML 文档中指定接口。但在消费者驱动契约中，每个服务消费者都会向服务提供者传达期望的接口。

🔗资料来源： edureka.co

Q31：微服务中的反应式扩展是什么？

主题：微服务
难度：⭐⭐⭐⭐⭐

响应式扩展（Reactive Extensions）也称为 Rx。这是一种设计方法，我们通过调用多个服务来收集结果，然后编译成一个组合响应。这些调用可以是同步的或异步的，阻塞的或非阻塞的。Rx 是分布式系统中非常流行的工具，其工作方式与传统流程相反。

🔗资料来源： edureka.co

Q32：目前最被接受的微服务事务策略是什么

主题：微服务
难度：⭐⭐⭐⭐⭐

微服务因其值得称赞的对去中心化数据管理的坚持而引入了最终一致性问题。在单体应用中，你可以在一个事务中同时更新多个数据。而微服务需要多个资源才能更新，分布式事务并不受欢迎（这是有原因的）。因此，现在开发人员需要意识到一致性问题，并弄清楚如何在执行任何代码会后悔的操作之前检测出数据不同步的情况。

想想交易是如何发生的，以及哪种交易对您的服务有意义，然后您可以实现一个回滚机制来取消原始操作，或者一个两阶段提交系统来保留原始操作，直到被告知真正提交。

金融服务业经常会做这种事——如果我想把钱从我的银行转到你的银行，不像数据库那样需要单笔交易。你不知道两家银行分别运行着什么系统，所以必须有效地将每个系统都视为微服务。在这种情况下，我的银行会将我的钱从我的账户转移到一个暂存账户，然后告诉你的银行他们有一些钱，如果转账失败，我的银行会将他们试图转账的钱退还给我的账户。

🔗来源： softwareengineering.stackexchange.com

Q33：为什么要使用 saga 而不是 2PC，反之亦然？

主题：微服务
难度：⭐⭐⭐⭐⭐

以下是我所知道的两种实现分布式事务的方法：

• 两阶段提交（2PC）
• 传奇

2PC 是一个协议，允许应用程序在平台的支持下透明地使用全局 ACID 事务。由于它嵌入在平台中，据我所知，它对业务逻辑和应用程序代码都是透明的。

另一方面，Sagas 是一系列本地事务，每个本地事务都会修改并持久化实体，同时使用一些指示全局事务阶段的标志来提交更改。换句话说，事务状态是领域模型的一部分。回滚是提交一系列“反转”事务的过程。无论哪种情况，服务发出的事件都会触发这些本地事务。

• 通常，2PC 用于即时交易。
• 通常，Sagas 适用于长期运行的交易。

我个人认为 Saga 能够做到 2PC 能做到的事情，但它们需要实现重做机制，这会增加开销。“相反”的说法并不准确。我认为 Saga 是通用的，而 2PC 则涉及平台/供应商锁定，缺乏平台独立性。

🔗来源： stackoverflow.com

Q34：请提供“智能管道”和“哑端点”的例子

主题：微服务
难度：⭐⭐⭐⭐⭐

系统中的组件使用“管道”（HTTP/S、队列等）相互通信。通常，这些管道会流经企业服务总线 (ESB)，ESB 会对组件之间传递的消息进行一系列处理。

它可能会这样做：

• 安全检查
• 路由
• 业务流程/验证
• 转型

完成这些任务后，消息将被转发到“端点”组件。这是一个“智能管道”的例子，因为许多逻辑和处理都驻留在 ESB 内部（“管道”系统的一部分）。由于 ESB 已经完成了所有工作，因此端点可以保持“哑”状态。

“智能端点和哑管道”主张相反的方案。通信通道应该剥离业务处理和逻辑，只在组件之间分发消息。然后由组件本身对这些消息进行处理/逻辑/验证等。

🔗来源： stackoverflow.com

Q35：如何为微服务架构实现 SSO？

主题：微服务
难度：⭐⭐⭐⭐⭐

添加身份服务并使用令牌授权通过该服务访问。任何拥有受保护资源的服务都会与身份服务通信，以确保其凭证（令牌）有效。如果无效，则会重定向用户进行身份验证。令牌验证完成后，即可保存在会话中，这样用户会话中的后续调用就无需进行额外的调用。如果需要在该会话中刷新令牌，您还可以创建计划作业。

解决这个问题的一个好方法是使用 OAuth 2 协议。在这种情况下，您可以使用 OAuth 2.0 端点进行身份验证，令牌将被添加到 HTTP 标头中，以便调用您的域名。所有服务都应从该域名路由，因此您可以从 HTTP 标头中获取令牌。

🔗来源： stackoverflow.com

感谢🙌的阅读，祝你面试顺利！
如果喜欢，请分享给你的开发者同事！
更多 FullStack 面试问答，请访问👉 www.fullstack.cafe