作者:Sahiti Kappagantula
翻译:疯狂的技术宅
来源:edureka
根据 Gartner 的说法,微服务是云开发的新应用平台。微服务是独立部署和管理的,一旦应用实现在容器内,它们与底层操作系统的交互很少。因此,如果你希望把微服务添加到自己的技术栈中,并想要了解与之相关的技能,那么现在正是潜心研究的时候。为了帮你准备面试,我写出了这篇关于微服务面试题的文章。
在本文中,我收集了面试官最常问到的问题。
优势 | 说明 |
---|---|
独立开发 | 所有微服务都可以根据各自的功能轻松开发 |
独立部署 | 根据他们所提供的服务,可以在任何应用中单独部署 |
故障隔离 | 即使应用中的一个服务不起作用,系统仍然继续运行 |
混合技术栈 | 可以用不同的语言和技术来构建同一应用程序的不同服务 |
粒度缩放 | 各个组件可根据需要进行扩展,无需将所有组件融合到一起 |
用蜂巢表示微服务
请参考上图。这里,每个六边形都代表单独的服务组件。与蜜蜂的工作类似,每个敏捷团队都使用可用的框架和所选的技术栈构建单独的服务组件。就像在蜂巢中一样,这些服务组件形成一个强大的微服务架构,以提供更好的可扩展性。此外敏捷团队可以单独处理每个服务组件的问题,而不会对整个应用程序产生影响或使影响最小。
微服务的特点
以下是设计微服务的最佳实践:
设计微服务的最佳实践
微服务架构具有以下组件:
微服务架构
微服务架构的优点 | 微服务架构的缺点 |
---|---|
可以自由使用不同的技术 | 增加故障排除的难度 |
每个微服务都专注于单一功能 | 由于远程调用而导致延迟增加 |
支持单个可部署单元 | 增加配置和其他操作的工作量 |
允许软件的持续发布 | 难以维持处理的安全性 |
可确保每项服务的安全性 | 很难跟踪各种边界的数据 |
并行开发和部署多个服务 | 服务之间难以编码 |
单体应用、SOA与微服务之间的比较
开发较小的微服务听起来很容易,但在开发时会经常遇到一些挑战。
SOA 和微服务之间的主要区别如下:
SOA | 微服务 |
---|---|
遵循“尽可能多的共享”架构方法 | 遵循“尽可能少的共享”的架构方法 |
侧重点是业务功能重用 | 侧重点在于“bounded context”的概念 |
遵循共同治理并有相关的标准 | 专注于人的合作和其他选择的自由 |
使用企业服务总线(ESB)进行通信 | 简单的消息系统 |
支持多消息协议 | 使用轻量级协议,例如 HTTP/REST 等 |
多线程,有更多的开销来处理I / O | 单线程,通常使用事件循环进行非锁定 I/O 处理 |
最大化服务的可重用性 | 专注于解耦 |
使用传统关系数据库较多 | 使用现代关系型数据库较多 |
系统发生变化时需要修改整体 | 系统发生变化是创建一项新服务 |
DevOps和持续交付正在变得流行,但尚未成为主流 | 专注于DevOps和持续交付 |
你可以列出微服务的特征,如下所示:
微服务的特征
领域驱动设计
为什么需要DDD
如果你必须定义通用语言(UL),那么它是特定域的开发人员和用户使用的通用语言,通过该语言可以轻松解释领域。
通用语言必须非常清晰,以便将所有团队成员处于同一水平线上,并以机器可以理解的方式进行翻译。
内聚是一个模块内部各元素之间相关联程度的度量
组件之间依赖关系强度的度量被称为耦合。好的设计总是高内聚和低耦合的。
Representational State Transfer(REST)/ RESTful (表述性状态转移)是一种帮助计算机系统通过 Internet 进行通信的架构风格。这使得微服务更容易理解和实现。
微服务可以用 RESTful API 来实现,当然也可以不用,但是用 RESTful API 去构建松散耦合的微服务总是更容易些。
虽然你可以通过多种方式实现微服务,但 REST over HTTP 是实现微服务的一种方式。REST 还用于其他应用程序,如 Web 应用、API 设计和 MV C应用以提供业务数据。
微服务是一种体系结构,其中系统的所有组件都被放入单独的组件中,这些组件可以单独构建、部署和扩展。微服务的某些原则和最佳实践有助于构建弹性应用程序。
简而言之,你可以认为 REST 是构建微服务的媒介。
在使用微服务时,由于有多个微服务协同工作,测试变得非常复杂。因此,测试分为不同的级别。
分布式事务是单个事件导致两个或多个不能以原子方式提交的单独数据源的突变的情况。在微服务的世界中,它变得更加复杂,因为每个服务都是一个工作单元,并且在大多数情况下,多个服务必须协同工作才能使业务成功。
幂等性是能够以同样的方式做两次,而最终结果将保持不变,就好像它只做了一次的特性。
用法:在远程服务或数据源中使用幂等性,以便当它多次接收指令时,只处理一次。
有界上下文是领域驱动设计的核心模式。DDD 战略设计部门的重点是处理大型模型和团队。DDD 通过将大型模型划分为不同的有界上下文并明确其相互关系来处理大型模型。
双因素身份验证是在帐户登录过程中启用第二级身份验证。
双因素认证因此,如果用户只需要输入用户名和密码,那么就被认为是单因素身份验证。
这三种凭证是:
双因素身份验证的凭据类型
客户端系统向远程服务器发出经过身份验证的请求所用的数字证书被称为客户端证书。客户端证书在许多相互认证设计中起着非常重要的作用,为请求者的身份提供了强有力的保证。
PACT 是一个开源工具,允许测试服务提供者和消费者之间的交互,与契约隔离,从而提高微服务集成的可靠性。
OAuth 代表开放授权协议。这允许通过在 HTTP 服务上启用客户端应用(例如第三方提供商 Facebook,GitHub等)来访问资源所有者的资源。因此,你可以在不使用其凭据的情况下与另一个站点共享存储在一个站点上的资源。
“任何设计系统的组织(广泛定义)都将产生一种设计,其结构是组织通信结构的副本。” —— Mel Conway
康威定律
该定律基本上试图传达这样一个事实:即为了使软件模块起作用,整个团队应该进行良好的沟通。因此系统的结构反映了产生它的组织的社会边界。
根据 Martin Flower 的说法,契约测试是在外部服务边界进行的测试,用于验证其是否符合消费者服务预期的契约。
此外,契约测试不会深入测试服务的行为。相反,它测试服务调用的输入和输出包含所需的属性和响应延迟,吞吐量在允许的限制范围内。
端到端测试验证了工作流中的每个流程都正常运行。这可确保系统作为一个整体协同工作并满足所有要求。
通俗地说,你可以说端到端测试是一种测试,在特定时期后测试所有东西。
测试层次
容器是管理基于微服务的程序以便单独开发和部署它们的好方法。你可以将微服务封装在容器镜像及其依赖项中,然后可以用它来滚动开发按需实例的微服务而无需任何额外的工作。
容器的表示及其在微服务中的使用方式
DRY 代表不要重复自己。它基本上促进了重用代码的概念。这导致开发并共享库,但是反过来导致紧耦合。
这基本上是用于开发微服务的模式,以便它们可以被外部系统使用。当我们处理微服务时,有一个特定的生产者者构建它,并且有一个或多个使用微服务的消费者。
通常,生产者程序在 XML 文档中指定接口。但在消费者驱动的契约中,每个服务的消费者都传达了生产者期望的接口。
微服务架构基于一个概念,为了构建业务功能其中所有服务应该能够彼此交互。因此要实现这一点,每个微服务必须具有接口。这使得 Web API 成为微服务的一个非常重要的推动者。RESTful API 基于 Web 的开放网络原则,为构建微服务架构的各个组件之间的接口提供了最合理的模型。
语义监控,也称为综合监控,将自动化测试与监控程序相结合,以检测业务失败的因素。
跨功能测试是对非功能性需求的验证,即那些不能像普通功能那样实现的要求。
不确定性测试(NDT)基本上是不可靠的测试。因此,它们有时可能会通过,显然有时也可能会失败。当它们失败时,会重新运行以通过。
从测试中排除不确定性的一些方法如下:
例如,对于空栈,你可以创建一个对于 empty() 方法只返回 true 的 stub。因此这并不关心栈中是否存在元素。
例如,对于 Customer 对象,你可以通过设置姓名和年龄来模拟它。你可以将年龄设置为 12,然后测试isAdult()方法,该方法将在大于 18 岁时返回 true。因此你的 Mock Customer 对象适用于指定的条件。
Mike Cohn 提供了一个名为 测试金字塔 的模型。这描述了软件开发所需的自动化测试类型。
Mike Cohn 的测试金字塔
图16: Mike Cohn 的测试金字塔 - 微服务面试问题
根据金字塔,第一层的测试量应该最高。在服务层,测试次数应小于单元测试级别,但应大于端到端级别。
Docker 提供了一个可用于托管任何应用程序的容器环境。将软件应用程序和支持它的依赖项紧密打包在一起。
这个打包的产品被称为**容器 **,因为它是由 Docker 完成的,所以被称为 Docker 容器。
金丝雀发布是一种降低在生产中引入新版本软件风险的技术。通过在将更改传递给整个基础架构之前将更改缓慢地推广到一小部分用户来完成的。
持续集成(CI)是每次团队成员提交版本控制更改时自动构建和测试代码的过程。这鼓励开发人员通过在每个小任务完成后将更改合并到共享版本控制存储库来共享代码和单元测试。
持续监控深入监控覆盖范围,从浏览器中的前端性能指标,到应用程序性能,再到主机虚拟化基础架构指标。
微服务架构中的架构师扮演以下角色:
我们知道拥有自己数据库的每个微服务都是一个可独立部署的程序单元,这反过来又让我们可以创建一个状态机。因此,我们可以为特定的微服务指定不同的状态和事件。
例如,我们可以定义 Order 微服务。订单可以具有不同的状态。Order 状态的转换可以是 Order 微服务中的独立事件。
Reactive Extensions 也称为Rx。这是一种设计方法,我们通过调用多个服务来收集结果,然后编译组合响应。这些调用可以是同步或异步,阻塞或非阻塞。Rx 是分布式系统中非常流行的工具,与传统流程相反。
随着新功能的增加,spring 变得越来越复杂。如果必须启动新的 spring 项目,必须添加构建路径或添加 maven 依赖项,配置服务器,添加 spring 配置。所以一切都必须从头开始。
**Spring Boot **是解决这个问题的方法。使用 spring boot 可以避免所有样板代码和配置。因此,基本上认为自己就好像在烤蛋糕一样,spring 就像做蛋糕所需的原料一样, spring boot 就是完整的蛋糕。
Spring Boot
Spring Boot 执行器提供 restful 服务,以访问在生产环境中运行程序的当前状态。在执行器的帮助下,你可以检查各种指标并监控自己的程序。
根据 Spring Cloud 的官方网站,Spring Cloud 为开发人员提供了一些快速构建分布式系统常见模式的工具(例如配置管理、服务发现、断路器、智能路由、领导选举、分布式会话、集群状态)。
在使用 Spring Boot 开发分布式微服务时,我们面临的一些问题可以由 Spring Cloud 解决。
WebMvcTest 注释用于 Spring MVC 程序的单元测试,其目标是专注于Spring MVC组件。在上面显示的快照中,我们只想启动 ToTestController。执行此单元测试时,将不会启动所有其他控制器和映射。
原文:https://www.edureka.co/blog/interview-questions/microservices-interview-questions/