根据Gartner的说法,微服务是云开发的新应用平台。微服务是独立部署和管理的,一旦在容器内实现,它们与底层操做系统的交互不多。 所以,若是您计划在微服务中开始您的职业生涯,那么如今正是潜入技术处于新生状态的时候。所以,为了帮助您准备面试,我提出了微服务面试问题和答案博客。前端
在这个微服务面试问题博客中,我收集了面试官最常问的问题。这些问题是在咨询微服务和相关技术领域的顶级行业专家后收集的。面试
若是您最近参加过任何微服务面试,请将这些面试问题粘贴到评论部分,咱们会尽快回答。若是您有任何疑问,也能够在下面发表评论,这可能会在您的微服务面试中遇到。spring
您能够浏览微服务面试问题和答案的录音,咱们的讲师已经详细解释了这些主题,并提供了一些示例,可帮助您更好地理解这一律念。数据库
微服务,又称微服务 后端
通俗地说,你必须看到蜜蜂如何经过对齐六角形蜡细胞来构建它们的蜂窝状物。他们最初从使用各类材料的小部分开始,并继续从中构建一个大型蜂箱。这些细胞造成图案,产生坚固的结构,将蜂窝的特定部分固定在一块儿。这里,每一个细胞独立于另外一个细胞,但它也与其余细胞相关。这意味着对一个细胞的损害不会损害其余细胞,所以,蜜蜂能够在不影响完整蜂箱的状况下重建这些细胞。浏览器
图1:微服务的蜂窝表示 – 微服务访谈问题安全
请参考上图。这里,每一个六边形形状表明单独的服务组件。与蜜蜂的工做相似,每一个敏捷团队都使用可用的框架和所选的技术堆栈构建单独的服务组件。就像在蜂箱中同样,每一个服务组件造成一个强大的微服务架构,以提供更好的可扩展性。此外,敏捷团队能够单独处理每一个服务组件的问题,而对整个应用程序没有影响或影响最小。性能优化
图2:微服务的 优势 – 微服务访谈问题服务器
图3:微服务的 特色 – 微服务访谈问题restful
如下是设计微服务的最佳实践:
图4:设计微服务的最佳实践 – 微服务访谈问题
微服务架构具备如下组件:
图5:微服务 架构 – 微服务面试问题
微服务架构的优势 |
微服务架构的缺点 |
---|---|
自由使用不一样的技术 |
增长故障排除挑战 |
每一个微服务都侧重于单一功能 |
因为远程呼叫而增长延迟 |
支持单个可部署单元 |
增长了配置和其余操做的工做量 |
容许常常发布软件 |
难以保持交易安全 |
确保每项服务的安全性 |
艰难地跨越各类边界跟踪数据 |
多个服务是并行开发和部署的 |
难以在服务之间进行编码 |
图6: 单片SOA和微服务之间的比较 – 微服务访谈问题
开发一些较小的微服务听起来很容易,但开发它们时常常遇到的挑战以下。
SOA和微服务之间的主要区别以下:
SOA |
微服务 |
---|---|
遵循“ 尽量多的共享 ”架构方法 |
遵循“ 尽量少分享 ”的架构方法 |
重要性在于 业务功能 重用 |
重要性在于“ 有界背景 ” 的概念 |
他们有 共同的 治理 和标准 |
他们专一于 人们的 合做 和其余选择的自由 |
使用 企业服务总线(ESB) 进行通讯 |
简单的消息系统 |
它们支持 多种消息协议 |
他们使用 轻量级协议 ,如 HTTP / REST 等。 |
多线程, 有更多的开销来处理I / O. |
单线程 一般使用Event Loop功能进行非锁定I / O处理 |
最大化应用程序服务可重用性 |
专一于 解耦 |
传统的关系数据库 更经常使用 |
现代 关系数据库 更经常使用 |
系统的变化须要修改总体 |
系统的变化是创造一种新的服务 |
DevOps / Continuous Delivery正在变得流行,但还不是主流 |
专一于DevOps /持续交付 |
您能够列出微服务的特征,以下所示:
图7:微服务的特征 – 微服务访谈问题
图8: DDD原理 – 微服务面试问题
图9:咱们须要DDD的因素 – 微服务面试问题
若是您必须定义泛在语言(UL),那么它是特定域的开发人员和用户使用的通用语言,经过该语言能够轻松解释域。
无处不在的语言必须很是清晰,以便它将全部团队成员放在同一页面上,并以机器能够理解的方式进行翻译。
模块内部元素所属的程度被认为是凝聚力。
组件之间依赖关系强度的度量被认为是耦合。一个好的设计老是被认为具备高内聚力和低耦合性。
Representational State Transfer(REST)/ RESTful Web服务是一种帮助计算机系统经过Internet进行通讯的架构风格。这使得微服务更容易理解和实现。
微服务可使用或不使用RESTful API实现,但使用RESTful API构建松散耦合的微服务老是更容易。
事实上,随着新功能的增长,弹簧变得愈来愈复杂。若是必须启动新的spring项目,则必须添加构建路径或添加maven依赖项,配置应用程序服务器,添加spring配置。因此一切都必须从头开始。
Spring Boot是解决这个问题的方法。使用spring boot能够避免全部样板代码和配置。所以,基本上认为本身就好像你正在烘烤蛋糕同样,春天就像制做蛋糕所需的成分同样,弹簧靴就是你手中的完整蛋糕。
图10: Spring Boot的因素 – 微服务面试问题
Spring Boot执行程序提供了restful Web服务,以访问生产环境中运行应用程序的当前状态。在执行器的帮助下,您能够检查各类指标并监控您的应用程序。
根据Spring Cloud的官方网站,Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智能路由,领导选举,分布式会话,集群状态)。
在使用Spring Boot开发分布式微服务时,咱们面临的问题不多由Spring Cloud解决。
在测试目标只关注Spring MVC组件的状况下,WebMvcTest注释用于单元测试Spring MVC应用程序。在上面显示的快照中,咱们只想启动ToTestController。执行此单元测试时,不会启动全部其余控制器和映射。
虽然您能够经过多种方式实现微服务,但REST over HTTP是实现微服务的一种方式。REST还可用于其余应用程序,如Web应用程序,API设计和MVC应用程序,以提供业务数据。
微服务是一种体系结构,其中系统的全部组件都被放入单独的组件中,这些组件能够单独构建,部署和扩展。微服务的某些原则和最佳实践有助于构建弹性应用程序。
简而言之,您能够说REST是构建微服务的媒介。
在使用微服务时,因为有多个微服务协同工做,测试变得很是复杂。所以,测试分为不一样的级别。
分布式事务是指单个事件致使两个或多个不能以原子方式提交的单独数据源的突变的任何状况。在微服务的世界中,它变得更加复杂,由于每一个服务都是一个工做单元,而且大多数时候多个服务必须协同工做才能使业务成功。
幂等性是可以以这样的方式作两次事情的特性,即最终结果将保持不变,即好像它只作了一次。
用法:在远程服务或数据源中使用 Idempotence,这样当它屡次接收指令时,它只处理指令一次。
有界上下文是域驱动设计的核心模式。DDD战略设计部门的重点是处理大型模型和团队。DDD经过将大型模型划分为不一样的有界上下文并明确其相互关系来处理大型模型。
双因素身份验证为账户登陆过程启用第二级身份验证。
图11: 双因素认证的表示 – 微服务访谈问题
所以,假设用户必须只输入用户名和密码,那么这被认为是单因素身份验证。
这三种凭证是:
图12: 双因素认证的证书类型 – 微服务面试问题
客户端系统用于向远程服务器发出通过身份验证的请求的一种数字证书称为客户端证书。客户端证书在许多相互认证设计中起着很是重要的做用,为请求者的身份提供了强有力的保证。
PACT是一个开源工具,容许测试服务提供者和消费者之间的交互,与合同隔离,从而提升微服务集成的可靠性。
OAuth 表明开放受权协议。这容许经过在HTTP服务上启用客户端应用程序(例如第三方提供商Facebook,GitHub等)来访问资源全部者的资源。所以,您能够在不使用其凭据的状况下与另外一个站点共享存储在一个站点上的资源。
图13: Conway定律的表示 – 微服务访谈问题
该法律基本上试图传达这样一个事实:为了使软件模块起做用,整个团队应该进行良好的沟通。所以,系统的结构反映了产生它的组织的社会边界。
根据Martin Flower的说法,合同测试是在外部服务边界进行的测试,用于验证其是否符合消费服务预期的合同。
此外,合同测试不会深刻测试服务的行为。更确切地说,它测试该服务调用的输入&输出包含所需的属性和所述响应延迟,吞吐量是容许的限度内。
端到端测试验证了工做流中的每一个流程都正常运行。这可确保系统做为一个总体协同工做并知足全部要求。
通俗地说,你能够说端到端测试是一种测试,在特定时期后测试全部东西。
图14:测试层次 – 微服务面试问题
容器是管理基于微服务的应用程序以便单独开发和部署它们的好方法
图15: 容器的表示及其在微服务中的使用方式 – 微服务访谈问题
DRY表明不要重复本身。它基本上促进了重用代码的概念。这致使开发和共享库,这反过来致使紧密耦合。
这基本上是用于开发微服务的模式,以便它们能够被外部系统使用。当咱们处理微服务时,有一个特定的提供者构建它,而且有一个或多个使用微服务的消费者。
一般,提供程序在XML文档中指定接口。但在消费者驱动的合同中,每一个服务消费者都传达了提供商指望的接口。
微服务架构基于一个概念,其中全部服务应该可以彼此交互以构建业务功能。所以,要实现这一点,每一个微服务必须具备接口。这使得Web API成为微服务的一个很是重要的推进者。RESTful API基于Web的开放网络原则,为构建微服务架构的各个组件之间的接口提供了最合理的模型。
语义监控,也称为 综合监控, 将自动化测试与监控应用程序相结合,以检测业务失败因素。
跨功能测试是对非功能性需求的验证,即那些没法像普通功能那样实现的需求。
非肯定性测试(NDT)基本上是不可靠的测试。因此,有时可能会发生它们经过,显然有时它们也可能会失败。当它们失败时,它们会从新运行经过。
从测试中删除非肯定性的一些方法以下:
例如,对于空堆栈,您能够建立一个只为empty()方法返回true的存根。所以,这并不关心堆栈中是否存在元素。
例如,对于Customer对象,您能够经过设置名称和年龄来模拟它。您能够将age设置为12,而后测试isAdult()方法,该方法将在年龄大于18时返回true。所以,您的Mock Customer对象适用于指定的条件。
Mike Cohn 提供了一个名为Test Pyramid的模型。这描述了软件开发所需的自动化测试类型。
图16: Mike Cohn的测试金字塔 – 微服务面试问题
根据金字塔,第一层的测试数量应该最高。在服务层,测试次数应小于单元测试级别,但应大于端到端级别。
Docker提供了一个可用于托管任何应用程序的容器环境。在此,软件应用程序和支持它的依赖项紧密打包在一块儿。
所以,这个打包的产品被称为Container,由于它是由Docker完成的,因此它被称为Docker容器!
Canary Releasing是一种下降在生产中引入新软件版本的风险的技术。这是经过将变动缓慢地推广到一小部分用户,而后将其发布到整个基础架构,即将其提供给每一个人来完成的。
持续集成(CI)是每次团队成员提交版本控制更改时自动构建和测试代码的过程。这鼓励开发人员经过在每一个小任务完成后将更改合并到共享版本控制存储库来共享代码和单元测试。
持续监控深刻监控覆盖范围,从浏览器内前端性能指标,到应用程序性能,再到主机虚拟化基础架构指标。
微服务架构中的架构师扮演如下角色:
这里推荐一下个人Java后端技术群: 834962734,群里有(分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、等学习资源)进群免费送给每一位Java小伙伴,无论你是转行,仍是工做中想提高本身能力均可以!
咱们知道拥有本身的数据库的每一个微服务都是一个可独立部署的程序单元,这反过来又让咱们能够建立一个状态机。所以,咱们能够为特定的微服务指定不一样的状态和事件。
例如,咱们能够定义Order微服务。订单能够具备不一样的状态。Order状态的转换能够是Order微服务中的独立事件。
Reactive Extensions也称为Rx。这是一种设计方法,咱们经过调用多个服务来收集结果,而后编译组合响应。这些调用能够是同步或异步,阻塞或非阻塞。Rx是分布式系统中很是流行的工具,与传统流程相反。