发布于 2025-03-08 52 阅读
0

系统设计面试中的 19 种微服务模式

系统设计面试中的 19 种微服务模式

图片来源 - ByteByteGo

大家好,如果您正在准备系统设计面试,那么准备微服务设计模式也是有意义的,不仅是为了在面试中表现出色或使您的架构更加健壮,而且还能了解现有项目。

Cicuit Breaker、API Gateway、Saga、Event Sourcing 等微服务模式是经过尝试和测试的常见微服务问题解决方案。

这些模式解决了微服务架构中的常见挑战,例如可扩展性、容错性和数据一致性。

过去,我讨论过常见的系统设计问题,例如API 网关与负载均衡器水平扩展与垂直扩展正向代理与反向代理以及常见的系统设计问题,在本文中,我将分享 24 个关键的微服务设计模式,这些是技术面试必备的知识。

它们也是面试中必不可少的系统设计主题之一,你必须做好准备。

许多公司都在使用微服务,因此了解这些模式表明您了解当前趋势。了解何时以及如何应用这些模式也表明您有能力解决复杂的分布式系统问题。

这些模式通常涉及权衡,让您展示您的分析思维,并且面试官经常会提出这些模式是相关解决方案的场景。

顺便说一句,如果你正在准备系统设计面试,并且想要深入学习系统设计,那么你也可以查看ByteByteGoDesign GuruExponentEducativeCodeemia.ioUdemy等网站,这些网站有很多很棒的系统设计课程和像这样的系统设计面试模板,你可以使用它来回答任何系统设计问题。

如何回答系统设计问题

如果你需要更多选择,你还可以查看最佳系统设计课程书籍网站的列表

PS:请继续阅读到最后。我有一个免费赠品给你。

那么,我们还等什么,赶紧开始吧

19 种适用于系统设计面试的微服务设计模式

微服务架构是一种设计方法,将应用程序构建为松散耦合的服务集合。

为了构建可扩展、可维护且具有弹性的基于微服务的系统,出现了各种模式。

以下是您可以在项目中使用并记住的系统设计面试的基本微服务模式。

1. 服务注册中心

由于微服务架构中有许多微服务,它们需要相互发现并通信。

服务注册表(例如 Netflix Eureka 或 Consul)充当集中式目录,服务可以在其中注册自己并发现其他服务。

它看起来是这样的:

服务注册模式


2. API 网关

API网关作为客户端应用程序的单一入口点,将多个微服务聚合为统一的 API。

它处理请求,将其路由到适当的服务,并可能执行身份验证、授权和负载平衡等任务。

API 网关的样子如下:

API 网关


3. 断路器

受电气断路器的启发,此模式可防止微服务故障影响其他服务。断路器模式会监控故障,如果超过阈值,则会断开电路,阻止进一步的请求。

这有助于实现优雅降级和容错,并且在微服务架构中绝对必须这样做,以防止服务完全关闭。

以下是 Netflix Hysrix 作为断路器的示例:

断路器


4. 隔板

在微服务系统中,隔离故障至关重要。隔墙模式涉及分离组件或服务以控制故障。

例如,可以使用线程池或不同服务的单独数据库来防止系统某一部分的故障影响其他部分。

下面是微服务架构中隔墙模式的示意图:

隔墙模式


5. Saga 模式

此模式用于管理分布式事务。Saga 模式将长期运行的业务事务分解为一系列较小的独立事务。

传奇中涉及的每个微服务都处理自己的事务并发布事件以触发后续操作。

Saga 模式的实际运作方式如下:

Saga 模式


6.事件源

这是另一种流行的模式,在高频率、低延迟的应用程序中被广泛使用。

在这种模式中,事件源不仅仅存储当前状态,还涉及存储导致当前状态的一系列事件。

该模式提供了可靠的审计跟踪,并允许在任何时间点重建系统状态。

事件溯源的实际运作方式如下:

事件溯源


7. 命令查询责任分离(CQRS)

CQRS 模式将应用程序的读写端分开。它使用不同的模型来更新信息(命令)和读取信息(查询)。

这种模式可以提高可扩展性,因为读写操作有不同的优化要求。

下面是一个展示 CQRS 模式的图表:

命令查询责任分离(CQRS)


8.数据分片

数据库共享模式用于分配数据库负载并避免瓶颈,数据分片涉及跨多个数据库或数据库实例对数据进行分区。

在这种模式中,每个微服务可以处理一部分数据或特定类型的请求。

数据库分片的样子如下,来源:设计大师

数据库分片的类型


9. 多语言持久性

不同的微服务可能有不同的数据存储需求。Polyglot Persistence 允许根据每个微服务的需求使用多种数据库技术,优化数据存储、检索和查询功能。

下面是一个漂亮的图表,展示了 Azure 中的多语言持久性:

多语言持久性


10. 重试

在微服务架构中,当发生瞬时故障时,重试模式涉及重试操作而不是立即失败。

它可以应用于各个层面,例如服务到服务通信或数据库交互。

这是ByteByteGo提供的一张漂亮的图表,它是系统设计学习的好地方,它展示了微服务中的重试模式:

微服务中的重试模式


12. Sidecar

Sidecar 模式涉及将辅助服务(sidecar)附加到主微服务,以提供附加功能,例如日志记录、安全性或与外部服务的通信。

这使得主服务能够专注于其核心功能。

Sidecar 模式如下所示:

微服务中的 Sidecar 模式


13. 前端的后端(BFF)

这种模式也称为 BFF,在处理多种客户端类型(例如 Web、移动)时很有用,BFF 模式涉及为每种类型的客户端创建量身定制的单独后端服务。

这允许为每个客户端提供优化和专门的 API。

前端后端 (BFF) 模式如下所示:

前端的后端 (BFF)


14. 影子部署

影子部署模式涉及将生产流量的副本(影子)路由到新的微服务版本,而不会影响实际用户体验。

这是流行的部署策略之一,它有助于验证新版本的性能和正确性。

影子部署如下

影子部署


15.消费者驱动的合同

在微服务生态系统中,多个服务经常相互交互。消费者驱动契约模式要求消费者指定他们对生产者的期望,从而实现更稳健、更协调的变更。

这是一个很好的图表,解释了消费者驱动合同

消费者驱动的合同


16. 智能端点,哑管道

此模式主张将业务逻辑置于微服务(智能端点)中,而不是依赖复杂的中间件。通信基础设施(管道)应该简单,并且只处理消息路由。


17. 每个服务都有数据库

这是另一种流行的微服务模式,其中每个微服务都有自己的数据库,并且服务通过明确定义的 API 进行通信。

每个服务数据库模式提供隔离,但也需要仔细考虑数据的一致性和完整性。

这个模式看起来是这样的:

每个服务对应一个数据库模式


18. 异步消息

异步消息传递模式不使用微服务之间的同步通信,而是使用消息队列来促进异步通信。这可以提高系统响应能力和可扩展性。

这是一个很好的图表,显示了同步和异步消息传递之间的区别

异步消息传递模式


19. 无状态服务

将微服务设计为无状态可简化可扩展性和弹性。每个服务独立处理请求,而不依赖于存储的状态,从而更容易进行水平扩展。

下面是一张很好的图表,展示了无状态服务和有状态服务的区别

无状态服务


系统设计访谈资源

此外,以下是我精心挑选的最佳系统设计书籍、在线课程和练习网站列表,您可以查看这些内容以更好地准备系统设计面试。这些课程中的大多数也回答了我在这里分享的问题。

  1. DesignGuru 的 Grokking 系统设计课程:一个交互式学习平台,通过实践练习和真实场景来加强您的系统设计技能。

  2. Codeemia.io:这是在线练习面试系统设计问题的最佳场所之一。它有超过 120 个系统设计问题,其中许多都是免费的,并且有适当的结构来解决它们。

  3. Exponent:一个专门为亚马逊和谷歌等 FAANG 公司提供面试准备的网站,他们还有很棒的系统设计课程和许多其他材料可以帮助你破解 FAANG 面试。

  4. Martin Kleppmann 撰写的《设计数据密集型应用程序》:一本全面的指南,涵盖了设计可扩展且可靠系统的原则和实践。

  5. LeetCode 系统设计标签:LeetCode 是一个流行的技术面试准备平台。LeetCode 上的系统设计标签包含各种练习问题。

  6. GitHub 上的“系统设计入门”:精选的资源列表,包括文章、书籍和视频,可帮助您准备系统设计面试。

  7. Educative 的系统设计课程:一个交互式学习平台,包含实践练习和真实场景,以加强您的系统设计技能。

  8. 高可扩展性博客:该博客提供有关高流量网站和可扩展系统架构的文章和案例研究。

  9. YouTube 频道:查看“Gaurav Sen”和“Tech Dummies”等频道,获取有关系统设计概念和面试准备的精彩视频。

  10. ByteByteGo:Alex Xu 撰写的一本用于系统设计面试准备的现场书籍和课程。它包含系统设计面试书籍第 1 卷和第 2 卷的所有内容,并将在即将推出的第 3 卷中更新。

  11. Alex Xu 撰写的《系统设计面试》:本书深入探讨了系统设计的概念、策略和面试准备技巧。

如何准备系统设计

图片来源 - ByteByteGo


这就是开发人员应该知道的常见微服务模式和概念。这些微服务模式有助于解决与构建和维护分布式系统相关的各种挑战,为通信、容错、数据管理和可伸缩性提供解决方案。

在设计微服务架构时,明智地结合这些模式可以打造出一个强大而有弹性的系统。

这些额外的微服务模式,如果经过深思熟虑地应用,有助于构建有弹性、可扩展和可维护的分布式系统。

模式的选择取决于微服务架构设计和实施过程中面临的具体要求和挑战。