微服务面试题及详细答案

本文参考 嗨客网 Java 随笔

前言

本章节记录了一些常见的微服务面试题及详细答案，目录如下：

 

微服务特点

微服务特点

简单地说，微服务架构是一种以一些微服务来替代开发单个的大而全的应用的方法，每一个小服务都运行在自己的进程里，并以轻量级的机制（通常是 HTTP RESTful API）来通信。微服务强调 “小快灵”，任何一个相对独立的功能服务不再是一个模块，而是一个独立的服务。

举个例子，就是将以前的大兵团全功能的部队拆分成一个个专业化的小分队，各司其职，各自为战，彼此之间用清晰的接口通信。

类似于真实世界，以前推崇金字塔结构：从上到下，分层管理，都在一个大的系统（进程）里以内部事件或函数调用的方法进行分工协作。而当前更倾向于扁平化管理，分成若干个独立运作的事业部或小组，各自为战，却又以 API/RPC 的方式紧密合作，为一个或一些用户提供所需的产品和服务。

有一利就有一弊，以往一个程序有几十个组件，现在可能就变成了几十个微服务。那么这么多微服务该如何管理呢？

类似于真实世界，若干个小分队联合作战得由总参谋部协调，彼此之间职责明确、分工协作。在软件世界中就可以前端应用及 API gateway 来调用和协调所依赖的微服务，再加上服务注册（service registry）、服务发现（service discovery）等服务治理功能，依靠强大的度量和监控将多个微服务整合在一起。

就如 《人月神话》 的作者布鲁克斯所提到的 “没有银弹”，从来就没有包治百病的灵丹妙药，如果有人声称有，那他一定是个骗子。微服务的问题也不少，小分队多了，沟通成本就增加了，性能也可能会有所下降。

详细说明：链接

 

微服务设计原则

微服务架构演进过程：

近年来我们大家都体会到了互联网、移动互联带来的好处，作为 IT 从业者，在生活中时刻感受互联网好处的同时，在工作中可能感受的却是来自自互联网的一些压力，那就是我们传统企业的 IT 建设也是迫切需要转型，需要面向外部客户，我们也需要应对外部环境的快速变化、需要快速创新，那么我们的 IT 架构也需要向互联网企业学习作出相应的改进，来支撑企业的数字化转型。

我们再看一下应用架构的演进过程，回忆一下微服务架构是如何一步一步进化产生的，最早是应用是单块架构，后来为了具备一定的扩展和可靠性，就有了垂直架构，也就是加了个负载均衡，接下来是前几年比较火的 SOA，主要讲了应用系统之间如何集成和互通，而到现在的微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好的开发、管理更加灵活高效。

微服务架构的基本思想就是 “围绕业务领域组件来创建应用，让应用可以独立的开发、管理和加速”。

详细说明：链接

 

微服务优缺点

什么是微服务

微服务是用一组小服务构建的一个应用，服务运行在不同的进程中，服务之间通过轻量的通讯机制进行交互，并且服务可以通过自动化部署方式独立部署。正因为微服务架构中，服务之间是相互独立的，所以不同的服务可以使用不同的语言来开发，或者根据业务的需求使用不同类型的数据库。

详细说明：链接

 

SOA架构与微服务架构区别

什么是SOA

SOA（Service Oriented Architecture）面向服务架构，它可以通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是 SOA 的接口，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。SOA 是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA 可以看作是 B/S 模型、XML（标准通用标记语言的子集）/Web Service 技术之后的自然延伸。

SOA 将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以 SOA 架构的系统能够更加从容地面对业务的急剧变化。

详细说明：链接

 

微服务最佳实践

微服务极大的改变了服务端引擎的架构方式。微服务不是一个单一的巨型的用来托管应用程序所有业务逻辑的代码库，而是反映了分布式系统模型，在该模型中，一组应用程序组件协同工作来满足业务需求。通过遵循十项基本的微服务最佳实践，你可以实现一个高效的微服务生态系统，从而避免不必要的架构复杂性。

详细说明：链接

 

微服务间通信

许多架构师已经将微服务之间的通信划分为同步和异步两种模式。让我们一个一个来介绍。

同步模式

当我们说到同步时，意思是客户端向服务端发出请求并等待其响应。线程将被阻塞，直到它接收到返回。实现同步通信最主要的协议是 HTTP。HTTP 可以通过 REST 或 SOAP 实现。现在 REST 在微服务方面发展迅速并超越了 SOAP。对我而言两者都很好用。

异步模式

当我们谈到异步通信时，它意味着客户端调用服务器，接收到请求的确认，然后忘记它。服务器将处理请求并完成。

现在让我们讨论一下什么时候需要异步。如果你的应用读操作很多，那么同步可能非常适合，尤其是在需要实时数据时。但是，当你处理大量写操作而又不能丢失数据记录时，你可能希望选择异步操作，因为如果下游系统宕机，你继续向其发送同步的调用，你将丢失请求和业务交易。经验法则是永远不要对实时数据读取使用异步，也永远不要对关键的业务交易写操作使用同步，除非你在写后立即需要数据。你需要在数据可用性和数据的强一致性之间进行选择。

详细说明：链接

 

使用微服务面临的挑战

使用微服务面临的挑战主要包括：固有的复杂性、分区的数据库架构和波及多个服务。

三大挑战

1. 固有的复杂性：微服务架构有很多优点，当然也有其不足。比如微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。
2. 分区的数据库架构：另外一个关于微服务的挑战来自于分区的数据库架构。在商业交易系统中同时给多个业务分主体更新消息很普遍。这种交易对于单个应用来说很容易，因为只有一个数据库。而在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为 CAP 理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。
3. 波及多个服务：一个问题在于，微服务架构模式应用的改变将会波及多个服务。比如，假设你在完成一个项目案例，需要修改服务 A、B、C，而 A 依赖 B，B 依赖 C。在单个应用中，你只需要改变相关模块，整合变化，部署就好了。相比之下，微服务架构模式就需要考虑相关改变对不同服务的影响。比如，你需要更新服务 C，然后是 B，才是 A，幸运的是，许多改变一般只影响一个服务，而需要协调多服务的改变很少。

使用微服务构建适合云的新型应用是很有意义的，因为它让你既利用了横向扩展架构，也利用了纵向扩展架构，还额外得到 API 的组合，且在整个业务中可重复利用。

可能在每一分钟都在交付新服务，这样你就会拥有一个敏捷的且即时响应的应用程序平台，当然这一平台一直在不断改进中，微服务架构也在前进着。

详细说明：链接

 

分布式与微服务区别

概念

集群是个物理形态，分布式是个工作方式。

1. 分布式：一个业务分拆多个子业务，部署在不同的服务器上。
2. 集群：同一个业务，部署在多个服务器上。

详细说明：链接

 

接口幂等性

什么是幂等性

幂等（Idempotent）是一个数学与计算机学的概念，常见于抽象代数中。

f(n) = 1^n // 无论n等于多少，f(n)永远值等于1

在编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数或幂等方法是指可以使用相同参数重复执行，并能获得相同结果的函数 / 方法。这些函数 / 方法不会影响系统状态，因此不用担心重复执行会对系统造成改变。例如：

1. 前端重复提交选中的数据，后台也只会产生对应这个数据的一个反应结果。
2. 用户发起一笔付款请求，就应该只扣用户一次钱，即使遇到网络重发或系统 bug 重发请求，也应该之扣一次钱。
3. 发送验证短息也应该只发一次，同样的验证短信不应该发送多次。
4. 创建业务订单，一个业务请求只能创建一个业务订单，创建多个就会出大问题。

这些等等很多的业务逻辑都需要幂等的特性来支持。

简单来理解就是，幂等就是一个操作，这个操作不管执行多少次，产生的效果和返回的结果都是一样的。比如说有一个 getOne () 函数，无论执行这个函数多少次，它返回的都是 1，这时就可以说它是一个幂等函数。

详细说明：链接

分布式事务

数据库事务

在说分布式事务之前，我们先从数据库事务说起。 数据库事务可能大家都很熟悉，在开发过程中也会经常使用到。但是即使如此，可能对于一些细节问题，很多人仍然不清楚。比如很多人都知道数据库事务的几个特性：原子性(Atomicity )、一致性( Consistency )、隔离性或独立性( Isolation)和持久性(Durabilily)，简称就是 ACID。但是再往下比如问到隔离性指的是什么的时候可能就不知道了，或者是知道隔离性是什么但是再问到数据库实现隔离的都有哪些级别，或者是每个级别他们有什么区别的时候可能就不知道了。

详细说明：链接

 

分布式CAP和BASE理论

问题的提出

在计算机科学领域，分布式一致性是一个相当重要且被广泛探索与论证问题，首先来看三种业务场景。

火车站售票

假如说我们的终端用户是一位经常坐火车的旅行家，通常他是去车站的售票处购买车票，然后拿着车票去检票口，再坐上火车，开始一段美好的旅行----一切似乎都是那么和谐。想象一下，如果他选择的目的地是杭州，而某一趟开往杭州的火车只剩下最后一张车票，可能在同一时刻，不同售票窗口的另一位乘客也购买了同一张车票。假如说售票系统没有进行一致性的保障，两人都购票成功了。而在检票口检票的时候，其中一位乘客会被告知他的车票无效----当然，现代的中国铁路售票系统已经很少出现这样的问题了。但在这个例子中我们可以看出，终端用户对于系统的需求非常简单：

“请售票给我，如果没有余票了，请在售票的时候就告诉我票是无效的”

这就对购票系统提出了严格的一致性要求----系统的数据（本例中指的就是那趟开往杭州的火车的余票数）无论在哪个售票窗口，每时每刻都必须是准确无误的！

详细说明：链接

 

双因素身份认证

如您所知，现代世界已经进入数字时代，与此同时，我们看到了网络犯罪和在线欺诈的增加。我怀疑您不认识至少一个没有被其 Facebook 个人资料遭到黑名单攻击的人，或者是因为黑名单而失去了 Twitter 帐户。如今，大多数人对保护强大的在线安全的价值极为熟悉，仅是为了保护自己的银行帐户。我们都听说过登录名，用户名和密码，但是实际上有多少人知道什么是双重身份验证？有些人可能听说过它，但是如果您要求他们向您解释它，即使大多数人每天都使用它，您也会得到一些答案和猜测。

您可能已经听说过 “双重身份验证”，但这究竟是什么？好吧，简单地说，它是第二层保护。有些人也称其为 “多因素身份验证”，只是使您更加困惑。

由于基本的在线安全协议通常可以简化为简单的用户名和密码，因此网络犯罪分子逐渐可以轻松获取您的个人信息 。此类数据的范围从与家人，朋友和亲人的私人交谈到财务记录以及您想避免由第三方掌握的所有其他敏感数据。

详细说明：链接

 

微服务pact契约测试

迁移到微服务对测试我们的系统产生了新的挑战。理论上每个微服务都应该是隔离的并可以独立操作。但在实践中一个服务如果没有其他部分通常没什么用。另一方面，为一个服务拉起整个系统的拓扑进行测试抵消了微服务期望带来的模块化和封装。

挑战在于如何检验与其他服务集成后没有问题。我们希望越早越好。而且我们不想将复杂的生产环境重现一遍。一般来说这种检验是集成功能测试或叫端到端测试。但实际是当我们的系统越来越复杂，端到端带来的收益越少。 大量的相互依赖导致误报和很长的执行周期。 使得测试变得很难管理与调试。

这甚至有一个测试金字塔理论（最初由 Mike Cohn 在他的著作 ‘Succeeding with Agile’ 中提到）讲述了为了优化你的投入，你需要更少的高层次的端到端测试，写更多的低层次的单元测试。

详细说明：链接

 

康威定律

康威定律是马尔文·康威 1967 提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。” 通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。

跨部门沟通是非常难的，系统各个模块的接口也反映了它们之间的信息流动和合作方式。

详细说明：链接

 

什么是CICD

如果你经历体验过传统的应用发布，你可能就会觉得 CICD 有足够吸引你的地方，反之亦然。一般一个研发体系中都会存在多个角色：开发、测试、运维。当时我们的应用发布模式可以能是这样的：

• 「开发团队」 在开发环境中完成软件开发，单元测试，测试通过，提交到代码版本管理库;
• 「开发同学」 通知运维同学项目可以发布了，然后运维同学下载代码进行打包和构建，生成应用制品;
• 「运维同学」 使用部署脚本将生成的制品部署到测试环境，并提示测试同学可以进行产品的测试;
• 「测试同学」 开始进行手动、自动化测试，测试完成后提醒运维同学可以进行预生产环境部署;
• 「运维同学」 开始进行预生产环境部署，然后测试同学进行测试，测试完成后，开始部署生产环境。

当然我描述的可能只是其中的一部分，手动操作很多、出现的问题很多。上面看似很流畅的过程，其实每次构建或发布都可能会出现问题。未对每次提交验证、构建环境不一致：开发人员本地测试成功后提交代码，运维同学下载代码进行编译却出现了错误。

详细说明：链接

 

JWT（JSON Web Token）

JSON Web Token（缩写 JWT）是目前最流行的跨域认证解决方案，本文介绍它的原理和用法。

跨域认证的问题

互联网服务离不开用户认证。一般流程是下面这样。

1. 用户向服务器发送用户名和密码。
2. 服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。
3. 服务器向用户返回一个 session_id，写入用户的 Cookie。
4. 用户随后的每一次请求，都会通过 Cookie，将 session_id 传回服务器。
5. 服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

这种模式的问题在于，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求 session 数据共享，每台服务器都能够读取 session。

详细说明：链接

 

什么是DevOps

DevOps（Development 和 Operations 组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。一些国际组织对其定义如下：

DevOps 强调对应用进行快速、小规模、可迭代的开发和部署，以更好地应对和满足客户的需求。它要求进行文化的转变，即将开发和运维只能作为一个合作的整体来看待，注重提高业务价值，旨在精简整个 IT 价值链。

从定义来看，其实 devops 就是为了让开发、运维和 QA 可以高效协作的流程。（可以把 DevOps 看作开发、技术运营和质量保障（QA）三者的交集）。

详细说明：链接

 

Ribbon负载均衡

服务器端负载均衡

负载均衡是我们处理高并发、缓解网络压力和进行服务器扩容的重要手段之一，但是一般情况下我们所说的负载均衡通常都是指服务器端负载均衡，服务器端负载均衡又分为两种，一种是硬件负载均衡，还有一种是软件负载均衡。

硬件负载均衡主要通过在服务器节点之前安装专门用于负载均衡的设备，常见的如：F5。软件负载均衡则主要是在服务器上安装一些具有负载均衡功能的软件来完成请求分发进而实现负载均衡，常见的如：LVS 、 Nginx 、Haproxy。

详细说明：链接

 

服务熔断降级限流

服务熔断降级限流

针对下面的情形，如图所示

当 Service A 调用 Service B，失败多次达到一定阀值，Service A 不会再去调 Service B，而会去执行本地的降级方法！对于这么一套机制:在 Spring cloud 中结合 Hystrix，将其称为熔断降级!

详细说明：链接

 

微服务限流

在高并发访问下，系统所依赖的服务的稳定性对系统的影响非常大，依赖有很多不可控的因素，比如网络连接变慢，资源突然繁忙，暂时不可用，服务脱机等。我们要构建稳定、可靠的分布式系统，就必须要有这样一套容错机制。常用的的容错技术如：隔离，降级，熔断，限流等策略，本文将详细的介绍微服务中的容错机制。

详细说明：链接

 

Service Mesh

Service Mesh 又译作 “服务网格”，作为服务间通信的基础设施层。

服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。

详细说明：链接

 

Istio

什么是Istio？

官方对 Istio 的介绍浓缩成了一句话：

An open platform to connect, secure, control and observe services.

翻译过来，就是 ”连接、安全加固、控制和观察服务的开放平台“。开放平台就是指它本身是开源的，服务对应的是微服务，也可以粗略地理解为单个应用。

详细说明：链接

更多

原文大纲： 链接

更多文章，可以关注下方公众号：