50个必需要会的微服务面试题

时间 2019-11-10

原文原文链接

做者：Sahiti Kappagantula
翻译：疯狂的技术宅前端

原文：https://www.edureka.co/blog/i...程序员

未经容许严禁转载面试

根据 Gartner 的说法，微服务是云开发的新应用平台。微服务是独立部署和管理的，一旦应用实如今容器内，它们与底层操做系统的交互不多。所以，若是你但愿把微服务添加到本身的技术栈中，并想要了解与之相关的技能，那么如今正是潜心研究的时候。为了帮你准备面试，我写出了这篇关于微服务面试题的文章。spring

在本文中，我收集了面试官最常问到的问题。数据库

微服务面试题与答案

Q1. 说说微服务架构的优点。

优点	说明
*独立开发*	全部微服务均可以根据各自的功能轻松开发
*独立部署*	根据他们所提供的服务，能够在任何应用中单独部署
*故障隔离*	即便应用中的一个服务不起做用，系统仍然继续运行
*混合技术栈*	能够用不一样的语言和技术来构建同一应用程序的不一样服务
*粒度缩放*	各个组件可根据须要进行扩展，无需将全部组件融合到一块儿

Q2. 你对微服务是怎么理解的？

微服务，又名微服务架构，是一种架构风格，它将应用构建为一个小型自治服务的集合，以业务领域为模型。
通俗地说，就像蜜蜂经过对蜡制的等边六角形单元来构建它们的蜂巢。
他们最初从使用各类材料的小单元开始，一点点的搭建出一个大型蜂巢。
这些小单元组成坚固的结构，将蜂窝的特定部分固定在一块儿。
这里，每一个小单元都独立于另外一个，但它也与其余小单元相关。
这意味着对一个小单元的损害不会损害其余的单元，所以，蜜蜂能够在不影响完整蜂巢的状况下重建这些单元。

请参考上图。这里，每一个六边形都表明单独的服务组件。与蜜蜂的工做相似，每一个敏捷团队都使用可用的框架和所选的技术栈构建单独的服务组件。就像在蜂巢中同样，这些服务组件造成一个强大的微服务架构，以提供更好的可扩展性。此外敏捷团队能够单独处理每一个服务组件的问题，而不会对整个应用程序产生影响或使影响最小。segmentfault

Q3. 微服务有哪些特色？

解耦（Decoupling） - 系统内的服务很大程度上是分离的。所以整个应用能够被轻松构建、修改和扩展
组件化（Componentization） - 微服务被视为能够被轻松替换和升级的独立组件
业务能力（Business Capabilities） - 微服务很是简单，专一于单一功能
自治（Autonomy） - 开发人员和团队能够相互独立工做，从而提升效率
持续交付（ContinousDelivery） - 容许频繁发版，经过系统自动化完成对软件的建立、测试和审核，
责任（Responsibility） - 微服务不把程序做为项目去关注。相反，他们将程序视为本身负责的产品
分散治理（Decentralized Governance） - 重点是用正确的工具去作正确的事。这意味着没有任何标准化模式或着技术模式。开发人员能够自由选择最合适的工具来解决本身的问题
敏捷性（Agility） - 微服务支持敏捷开发。任何新功能均可以快速开发并被再次丢弃

Q4. 设计微服务的最佳实践是什么？

如下是设计微服务的最佳实践：
浏览器

为每一个微服务分开数据存储
将代码保持在相似的成熟度等级上
为每一个微服务进行单独的构建
部署到容器中
将服务器视为无状态的

Q5. 微服务架构是如何运做的？

微服务架构具备如下组件：安全

Clients – 来自不一样设备的不一样用户发送请求。
Identity Providers – 对用户或客户端身份进行身份验证，并颁发安全令牌。
API Gateway – 处理客户端请求。
Static Content – 容纳系统的全部内容。
Management – 平衡节点上的服务压力并识别故障。
Service Discovery – 用于找到微服务之间通讯路径的向导。
Content Delivery Networks – 代理服务器及其数据中心的分布式网络。
Remote Service – 启用驻留在 IT 设备网络上的远程访问信息。

Q6. 微服务架构的优势和缺点是什么？

微服务架构的优势	微服务架构的缺点
能够自由使用不一样的技术	增长故障排除的难度
每一个微服务都专一于单一功能	因为远程调用而致使延迟增长
支持单个可部署单元	增长配置和其余操做的工做量
容许软件的持续发布	难以维持处理的安全性
可确保每项服务的安全性	很难跟踪各类边界的数据
并行开发和部署多个服务	服务之间难以编码

Q7. 单体应用、SOA 和微服务架构有什么区别？

单体应用相似于一个大容器，其中程序的全部组件都被组装在一块儿并紧密包装。
SOA是一组相互通讯的服务。通讯能够涉及简单的数据传送，也能够涉及两个或多个协调某些活动的服务。
微服务架构是一种架构风格，它将应用程序构建为以业务域为模型的小型自治服务集合。

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

开发较小的微服务听起来很容易，但在开发时会常常遇到一些挑战。服务器

自动化组件：难以自动化，由于有许多较小的组件。对于每一个组件，都必须采起构建、发布和监控的步骤。
可感知性：将大量组件维持在一块儿会带来难以部署、维护、监控和识别的问题。它须要在全部组件周围具备很好的感知能力。
配置管理：有时在各类环境中维护组件的配置会很困难。
调试：很难找到与产生的错误相关的每一项服务。维护一个集中式的日志和控制面板对调试问题相当重要。

Q9. SOA 和微服务架构之间的主要区别是什么？

SOA 和微服务之间的主要区别以下：微信

SOA	微服务
遵循“尽量多的共享”架构方法	遵循“尽量少的共享”的架构方法
侧重点是业务功能重用	侧重点在于“bounded context”的概念
遵循共同治理并有相关的标准	专一于人的合做和其余选择的自由
使用企业服务总线（ESB）进行通讯	简单的消息系统
支持多消息协议	使用轻量级协议，例如 HTTP/REST 等
多线程，有更多的开销来处理I / O	单线程，一般使用事件循环进行非锁定 I/O 处理
最大化服务的可重用性	专一于解耦
使用传统关系数据库较多	使用现代关系型数据库较多
系统发生变化时须要修改总体	系统发生变化是建立一项新服务
DevOps和持续交付正在变得流行，但还没有成为主流	专一于DevOps和持续交付

Q10. 微服务有什么特色？

你能够列出微服务的特征，以下所示：

围绕业务功能组织团队
作产品而不是作项目
基本的消息传递框架
去中心化治理
去中心化管理数据
基础设施自动化
容错设计

Q11. 什么是领域驱动设计（DDD）？

专一于核心领域逻辑
在模型上找到综合的设计
不断与领域专家合做，改进应用程序模型并解决与领域相关的问题

Q12. 为何须要域驱动设计（DDD）？

映射领域
下降复杂性
可测试性
可维护性
知识丰富的设计
将业务和服务结合在一块儿
上下文集中
通用语言

Q13. 什么是通用语言（UL）？

若是你必须定义通用语言（UL），那么它是特定域的开发人员和用户使用的通用语言，经过该语言能够轻松解释领域。

通用语言必须很是清晰，以便将全部团队成员处于同一水平线上，并以机器能够理解的方式进行翻译。

Q14. 什么是内聚？

内聚是一个模块内部各元素之间相关联程度的度量

Q15. 什么是耦合？

组件之间依赖关系强度的度量被称为耦合。好的设计老是高内聚和低耦合的。

Q16. 什么是REST/RESTful ？它的用途是什么？

Representational State Transfer（REST）/ RESTful （表述性状态转移）是一种帮助计算机系统经过 Internet 进行通讯的架构风格。这使得微服务更容易理解和实现。

微服务能够用 RESTful API 来实现，固然也能够不用，可是用 RESTful API 去构建松散耦合的微服务老是更容易些。

Q17. 你怎么理解 Spring Boot？

随着新功能的增长，spring 变得愈来愈复杂。若是必须启动新的 spring 项目，必须添加构建路径或添加 maven 依赖项，配置服务器，添加 spring 配置。因此一切都必须从头开始。

Spring Boot 是解决这个问题的方法。使用 spring boot 能够避免全部样板代码和配置。所以，基本上认为本身就好像在烤蛋糕同样，spring 就像作蛋糕所需的原料同样， spring boot 就是完整的蛋糕。

Q18. Spring boot 的执行器是什么？

Spring Boot 执行器提供 restful 服务，以访问在生产环境中运行程序的当前状态。在执行器的帮助下，你能够检查各类指标并监控本身的程序。

Q19. 什么是 Spring Cloud？

根据 Spring Cloud 的官方网站，Spring Cloud 为开发人员提供了一些快速构建分布式系统常见模式的工具（例如配置管理、服务发现、断路器、智能路由、领导选举、分布式会话、集群状态）。

Q20. Spring Cloud 解决了哪些问题？

在使用 Spring Boot 开发分布式微服务时，咱们面临的一些问题能够由 Spring Cloud 解决。

与分布式系统相关的复杂性 - 这包括网络问题、延迟开销、带宽问题、安全问题。
处理服务发现的能力 - 服务发现容许群集中的进程和服务找到彼此并进行通讯。
解决了冗余问题 - 冗余问题常常发生在分布式系统中。
负载平衡 - 改进跨多种计算资源（如计算机集群、网络连接、中央处理单元）的工做负载分配。
减小性能问题 - 减小因各类操做开销致使的性能问题。

Q21. 在 Spring MVC 中使用 WebMvcTest 注释有什么用？

WebMvcTest 注释用于 Spring MVC 程序的单元测试，其目标是专一于Spring MVC组件。在上面显示的快照中，咱们只想启动 ToTestController。执行此单元测试时，将不会启动全部其余控制器和映射。

Q22. 你可否给出关于 Rest 和微服务的要点？

REST

虽然你能够经过多种方式实现微服务，但 REST over HTTP 是实现微服务的一种方式。 REST 还用于其余应用程序，如 Web 应用、API 设计和 MV C应用以提供业务数据。

微服务

微服务是一种体系结构，其中系统的全部组件都被放入单独的组件中，这些组件能够单独构建、部署和扩展。微服务的某些原则和最佳实践有助于构建弹性应用程序。

简而言之，你能够认为 REST 是构建微服务的媒介。

Q23. 什么是不一样类型的微服务测试？

在使用微服务时，因为有多个微服务协同工做，测试变得很是复杂。所以，测试分为不一样的级别。

在底层，咱们有面向技术的测试 —— 单元测试和性能测试。这些是彻底自动化的。
在中间层，咱们有探测性测试，如压力测试和可用性测试。
在顶级，咱们有不多的验收测试。这些验收测试有助于利益相关者理解和验证软件功能。

Q24. 你对分布式事务的理解？

分布式事务是单个事件致使两个或多个不能以原子方式提交的单独数据源的突变的状况。在微服务的世界中，它变得更加复杂，由于每一个服务都是一个工做单元，而且在大多数状况下，多个服务必须协同工做才能使业务成功。

Q25. 什么是幂等性（Idempotence）及用在那里？

幂等性是可以以一样的方式作两次，而最终结果将保持不变，就好像它只作了一次的特性。

用法：在远程服务或数据源中使用幂等性，以便当它屡次接收指令时，只处理一次。

Q26. 什么是有界上下文？

有界上下文是领域驱动设计的核心模式。 DDD 战略设计部门的重点是处理大型模型和团队。 DDD 经过将大型模型划分为不一样的有界上下文并明确其相互关系来处理大型模型。

Q27. 什么是双因素身份验证？

双因素身份验证是在账户登陆过程当中启用第二级身份验证。

所以，若是用户只须要输入用户名和密码，那么就被认为是单因素身份验证。

Q28. 双因素身份验证的凭据类型有哪些？

这三种凭证是：

你知道的东西——如：PIN、密码或模式
你有的东西——如：ATM 卡、电话或 OTP
你是谁——如：生物特征指纹或声纹

Q29. 什么是客户端证书？

客户端系统向远程服务器发出通过身份验证的请求所用的数字证书被称为客户端证书。客户端证书在许多相互认证设计中起着很是重要的做用，为请求者的身份提供了强有力的保证。

Q30. PACT 在微服务架构中的用途是什么？

PACT 是一个开源工具，容许测试服务提供者和消费者之间的交互，与契约隔离，从而提升微服务集成的可靠性。

在微服务中的用法：

用于在微服务中实现消费者驱动的契约。
测试微服务的消费者和生产者之间的消费者驱动的契约。

Q31. 什么是OAuth？

OAuth 表明开放受权协议。这容许经过在 HTTP 服务上启用客户端应用（例如第三方提供商 Facebook，GitHub等）来访问资源全部者的资源。所以，你能够在不使用其凭据的状况下与另外一个站点共享存储在一个站点上的资源。

Q32. 什么是康威定律？

“任何设计系统的组织（普遍定义）都将产生一种设计，其结构是组织通讯结构的副本。” —— Mel Conway

该定律基本上试图传达这样一个事实：即为了使软件模块起做用，整个团队应该进行良好的沟通。所以系统的结构反映了产生它的组织的社会边界。

Q33. 契约测试（contract test）是什么？

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

此外，契约测试不会深刻测试服务的行为。相反，它测试服务调用的输入和输出包含所需的属性和响应延迟，吞吐量在容许的限制范围内。

Q34. 什么是端到端微服务测试？

端到端测试验证了工做流中的每一个流程都正常运行。这可确保系统做为一个总体协同工做并知足全部要求。

通俗地说，你能够说端到端测试是一种测试，在特定时期后测试全部东西。

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

容器是管理基于微服务的程序以便单独开发和部署它们的好方法。你能够将微服务封装在容器镜像及其依赖项中，而后能够用它来滚动开发按需实例的微服务而无需任何额外的工做。

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

DRY 表明不要重复本身。它基本上促进了重用代码的概念。这致使开发并共享库，可是反过来致使紧耦合。

Q37. 消费者驱动的契约（CDC）是什么？

这基本上是用于开发微服务的模式，以便它们能够被外部系统使用。当咱们处理微服务时，有一个特定的生产者者构建它，而且有一个或多个使用微服务的消费者。

一般，生产者程序在 XML 文档中指定接口。但在消费者驱动的契约中，每一个服务的消费者都传达了生产者指望的接口。

Q38. Web、RESTful API 在微服务中的做用是什么？

微服务架构基于一个概念，为了构建业务功能其中全部服务应该可以彼此交互。所以要实现这一点，每一个微服务必须具备接口。这使得 Web API 成为微服务的一个很是重要的推进者。 RESTful API 基于 Web 的开放网络原则，为构建微服务架构的各个组件之间的接口提供了最合理的模型。

Q39. 你对微服务架构中的语义监控有何了解？

语义监控，也称为综合监控，将自动化测试与监控程序相结合，以检测业务失败的因素。

Q40. 咱们如何进行跨功能测试？

跨功能测试是对非功能性需求的验证，即那些不能像普通功能那样实现的要求。

Q41. 如何在测试中消除不肯定性？

不肯定性测试（NDT）基本上是不可靠的测试。所以，它们有时可能会经过，显然有时也可能会失败。当它们失败时，会从新运行以经过。

从测试中排除不肯定性的一些方法以下：

隔离
异步
远程服务
分离
时间
资源泄漏

Q42. Mock 与 Stub 有什么区别？

Stub

一个有助于运行测试的虚拟对象。
在某些能够硬编码的条件下提供固定的行为。
从未测试stub的全部其余行为。

例如，对于空栈，你能够建立一个对于 empty() 方法只返回 true 的 stub。所以这并不关心栈中是否存在元素。

模拟

一个虚拟对象，其中最初设置了某些属性。
此对象的行为取决于设置的属性。
也能够测试对象的行为。

例如，对于 Customer 对象，你能够经过设置姓名和年龄来模拟它。你能够将年龄设置为 12，而后测试isAdult()方法，该方法将在大于 18 岁时返回 true。所以你的 Mock Customer 对象适用于指定的条件。

Q43. 你对Mike Cohn的测试金字塔了解多少？

Mike Cohn 提供了一个名为 测试金字塔 的模型。这描述了软件开发所需的自动化测试类型。

图16： Mike Cohn 的测试金字塔 - 微服务面试问题

根据金字塔，第一层的测试量应该最高。在服务层，测试次数应小于单元测试级别，但应大于端到端级别。

Q44. Docker 的用途是什么？

Docker 提供了一个可用于托管任何应用程序的容器环境。将软件应用程序和支持它的依赖项紧密打包在一块儿。

这个打包的产品被称为容器，由于它是由 Docker 完成的，因此被称为 Docker 容器。

Q45. 什么是金丝雀发布（Canary Releasing）？

金丝雀发布是一种下降在生产中引入新版本软件风险的技术。经过在将更改传递给整个基础架构以前将更改缓慢地推广到一小部分用户来完成的。

Q46. 什么是持续集成（CI）？

持续集成（CI）是每次团队成员提交版本控制更改时自动构建和测试代码的过程。这鼓励开发人员经过在每一个小任务完成后将更改合并到共享版本控制存储库来共享代码和单元测试。

Q47. 什么是持续监控？

持续监控深刻监控覆盖范围，从浏览器中的前端性能指标，到应用程序性能，再到主机虚拟化基础架构指标。

Q48. 架构师在微服务架构中的角色是什么？

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

决定整个软件系统的布局。
有助于肯定组件的分区。所以，他们确保组件相互粘合，但不紧密耦合。
与开发人员一块儿编写代码，了解平常面临的挑战。
为开发微服务的团队提供某些工具和技术的建议。
提供技术治理，以便技术开发团队遵循微服务原则。

Q49. 能够用微服务建立状态机吗？

咱们知道拥有本身数据库的每一个微服务都是一个可独立部署的程序单元，这反过来又让咱们能够建立一个状态机。所以，咱们能够为特定的微服务指定不一样的状态和事件。

例如，咱们能够定义 Order 微服务。订单能够具备不一样的状态。Order 状态的转换能够是 Order 微服务中的独立事件。

Q50. 微服务中的反应性扩展是什么？

Reactive Extensions 也称为Rx。这是一种设计方法，咱们经过调用多个服务来收集结果，而后编译组合响应。这些调用能够是同步或异步，阻塞或非阻塞。 Rx 是分布式系统中很是流行的工具，与传统流程相反。

本文首发微信公众号：前端先锋

欢迎扫描二维码关注公众号，天天都给你推送新鲜的前端技术文章

欢迎继续阅读本专栏其它高赞文章：

更多文章...