原文链接

十种常见的反模式以及如何避免它们

引言

一个精心打造的基于微服务架构的应用程序能够经受住时间的考验，因为它具有可扩展性、灵活性和弹性，能够应对可能出现的大多数问题。

由于揭耦的组件可以独立运行，因此不会受到应用程序中其他微服务的影响，这些架构实现了高水平的弹性。

尽管如此，微服务架构仍有可能失败并失去效力。

在本文中，我们将探讨一些最常见的反模式或设计模式，它们会给基于微服务的架构带来问题。

下面是反模式概要清单：

1. 微服务中的单体
2. 聊天式微服务
3. 分布式单体
4. 过度微服务
5. 违反单一责任
6. 意大利面架构
7. 分布式数据不一致
8. 紧密耦合
9. 缺乏可观察性
10. 忽视人力成本

1. 微服务中的单体

如果要在保留单体架构的同时构建微服务器，就会遇到可扩展性、容错等问题。这通常是由以下原因造成的：

1. 共享数据库： 在构建微服务时，为每个服务配备一个数据库通常是个好主意。这可以让你根据每个服务的规则控制数据库类型、模式规则和 IOPS 容量，从而让你对扩展有更精细的控制。但是，如果所有服务都使用一个数据库，就会增加应用程序的增长难度。
2. 复杂的部署： 尽管微服务被分解成更小的服务，但部署过程仍然复杂耗时，需要不同团队之间的协调和人工参与。这限制了微服务的敏捷性和灵活性。
3. 服务界限不清： 服务界限不清会导致功能重叠和所有权不明确。这会导致工作重复，难以控制和改进架构。

因此，为了避免在微服务中出现单体，我建议每个微服务使用单个数据库，并通过领域驱动设计明确微服务的所有权。

2. 聊天式微服务

由于其解耦性质，微服务经常会相互通信，以处理应用程序的工作负载。虽然通信是关键，但微服务之间的过度通信或低效聊天会降低它们的效率。

让我们来看看一些会大大降低效率，同时又会导致聊天式微服务的应用场景：

1. 频繁的服务间通信： 系统中的微服务向其他微服务发送大量请求以完成次要任务或获取少量数据的情况。这会产生大量网络流量并增加响应延迟。
2. 细粒度应用程序接口： 微服务提供的细粒度 API 需要多次调用才能完成单个用户请求或业务事务。每次调用都可能需要序列化、网络开销，甚至阻塞 I/O 操作，从而增加了性能问题。
3. 级联调用： 单个用户请求或事务会在多个微服务之间发起一系列调用，每个服务都依赖其他服务完成处理。这可能会造成多米诺骨牌效应，即一个服务的故障或延迟会波及其他服务，导致整个系统恶化。

因此，为了避免这个问题，您需要以这样一种方式来设计您的架构，即您的服务是解耦的，并且更具可扩展性。您可以利用 Amazon SQS、Amazon SNS 和 Amazon EventBridge 等服务，引入消息队列、事件总线或事件主题。

如您所见，订单确认微服务与发货、库存和通知微服务进行通信。不过，它并不直接与这些服务通信。相反，它使用 SQS 和 SNS 等附属服务来解耦通信行为。

这样做可以避免服务间通信，使服务之间的通信分离。

3. 分布式单体

这种反模式指的是，应用程序是作为分布式系统设计和实施的，但由多个相互连接的组件或服务组成，这些组件或服务耦合得很紧，因此微服务缺乏真正的独立性。

这种反模式的一些主要特征包括：

1. 缺乏服务自主性： 分布式系统中的每个组件都严重依赖其他组件运行，因此缺乏完全的自主性。这种缺乏独立性的情况使得独立扩展、部署和演进各种元素变得十分困难。
2. 复杂的相互依赖： 分布式系统的各个组件之间存在着错综复杂的相互依赖关系，其中一个组件需要依赖其他众多组件才能正常运行。这就形成了一个难以管理和理解的关系网，增加了复杂性和风险。
3. 共享状态： 分布式系统的组件通过共享数据库、缓存或直接通信直接共享状态或数据。这种共享状态会导致数据一致性挑战、竞赛条件和扩展困难。

举例来说，请看这个架构：

您正在调用三个服务：OrderService、PaymenrService 和 InvoiceService。这三个服务是独立运行的，但通过这样的链式调用，您将服务与这一个操作耦合在一起。这样做会引入线性扩展等问题，并产生不必要的相互依赖关系。

同样，您可以通过将微服务与 SNS、SQS 等服务解耦来解决这个问题。

4. 过度微服务

在设计基于微服务的架构时，最常见的误区之一就是将每个功能拆分成一个微服务，甚至是最简单的功能！

这就在不需要的地方引入了微服务，超出了必要或有益的范围，从而降低了应用程序的整体性能。在遵循领域驱动设计原则的同时，将微服务分解为必要的部分至关重要。

"过度微服务"反模式的主要特征包括：

1. 过度分散： 系统被划分为大量的微服务，这可能导致数十个甚至数百个服务。每个微服务可能只封装了一小部分功能，导致分解过细。
2. 内聚力低： 单个微服务缺乏连贯性，这意味着它们可能不包含逻辑连接或连贯的功能集。这会导致业务逻辑分散零碎，难以从整体上理解和管理系统。
3. 高耦合： 尽管服务被划分为多个微服务，但由于服务之间存在大量的交互和相互依存关系，因此服务可能会紧密耦合。一个微服务的变化可能需要许多其他微服务的变化，从而增加了复杂性和风险。

解决这一问题的方法之一是在微服务中采用领域驱动设计，并为应用程序的特定领域创建微服务。有关领域驱动设计的详细指南，请查看： 开发面向领域驱动设计的微服务

5. 违反单一责任

这从根本上违反了面向对象设计中函数的责任。当单个函数或微服务承担了本应分开的多个职责或关注点时，就会出现这种情况。例如，当支付处理微服务同时处理用户注册时。

让我们来看看助长这种反模式的一些情况：

1. 缺乏设计原则意识： 开发人员可能没有完全意识到或理解单一责任原则（SRP）等设计概念，或者没有在代码库中确定应用程序的优先级。
2. 规划不足： 在软件设计的早期阶段，规划或分析不足可能会导致组件职责划分不清，从而导致同一组件中的多个关注点混杂在一起。
3. 对需求的误解： 对需求的误解或误解会导致在组件中引入不需要或不相关的功能，从而违反单一责任原则（SRP）。

6. 意大利面架构

有些反模式是不言自明的，就像意大利面架构（Spaghetti Architecture），它指的是缺乏清晰结构和组织的软件架构，导致相互连接的组件、模块或层级杂乱无章。

"意大利面架构"反模式的主要特征包括：

1. 缺乏关注点分离： 架构未能区分不同的关注点或职责，导致业务逻辑、表现逻辑、数据访问逻辑和其他功能混杂在同一组件或模块中。
2. 复杂的控制流： 架构的控制流复杂而迂回，组件之间的依赖关系和交互难以跟踪或理解。这可能会导致不可预测的行为和意想不到的后果。
3. 高耦合： 与我们前面看到的情况类似，架构中的组件或模块紧密相连，这意味着它们之间的依赖性极强。一个组件的改变有时需要改变其他几个组件，从而在整个系统中产生连锁反应。

7. 分布式数据不一致

这是指数据在多个节点或服务之间复制，由于在这些副本之间同步更新时出现延迟或故障而导致不一致，从而导致系统的不同部分访问到不正确或过时的信息，造成不正确的行为、数据损坏或完整性违规。

"分布式数据不一致"反模式的主要特征包括：

1. 异步更新： 数据更新在分布式系统的副本或节点中以异步方式传播。这可能会导致在执行更改和将更改反映到所有数据副本之间出现延迟。
2. 网络分区： 由于不可预见的原因，可能会出现网络分区或故障，导致更新无法传播到所有副本，或因更新不完整而造成副本间的差异。
3. 冲突操作： 许多节点对相同数据的并发操作可能会导致冲突，而这些冲突没有得到适当处理，从而导致数据不一致或损坏。

要解决这些问题，必须利用微服务模式（如 Saga 模式）来创建和管理微服务中的分布式事务。如何在微服务中使用 Saga 模式

8. 紧密耦合

紧密耦合本身可能并不被视为一种反模式，但却是我们之前研究过的许多反模式的一个关键特征。但是，如果微服务之间或其输出之间存在严重的依赖关系，则可能会在系统扩展时产生问题。

这会导致许多反模式，例如但不限于以下方面：

1. 单体架构
2. 意大利面架构
3. 上帝对象
4. 分布式数据不一致
5. 供应商锁定

9. 缺乏可观察性

在这种情况下，应用程序无法提供对内部状态、操作和性能的充分了解。这使得开发人员或管理员很难观察应用程序的性能，甚至无法有效地排除故障。

"缺乏可观察性"反模式的主要特征包括：

1. 日志记录有限： 系统缺乏全面的日志记录机制，无法捕捉系统中发生的重大事件、错误和操作。这增加了追踪执行流程和发现问题的难度。
2. 指标不足： 系统没有提供有关其性能、资源使用情况和其他重要指标的有用度量或遥测数据。如果没有这些信息，就很难评估系统的健康状况，并找出可能的瓶颈或需要改进的地方。
3. 稀少的跟踪： 系统缺乏分布式跟踪功能，无法跟踪跨多个服务或组件的请求流和事务流。这使得检测分布式系统的性能峰值、延迟问题和故障变得更加困难。

考虑使用 AWS X-Ray 等云本地工具或 New Relic 等第三方平台。

通过这样做，您可以深入了解系统错误，并主动识别性能和可扩展性问题。

10. 忽视人力成本

这是指主要目标集中在实现技术目标和最后期限上，而没有充分考虑到对参与项目的团队或个人的福利、士气和工作与生活平衡的影响。

"忽视人力成本"反模式的主要特征包括：

1. 过度工作： 团队成员经常被迫延长工作时间，包括晚上、周末和节假日，以完成项目的最后期限或解决意料之外的挑战。这会导致倦怠、疲惫和工作效率下降。
2. 不切实际的期望： 在确定项目时间表和交付成果时，不考虑团队的现有资源、技能或能力。这就造成了不合理的期望，给团队成员在紧迫的期限内执行项目带来了不必要的压力。
3. 微观管理： 管理者或团队领导对团队成员的工作过度控制或微观管理，从而削弱了他们的自主性、创造力和动力。
4. 缺乏支持： 在工作中遇到问题或困难时，团队成员会感到得不到管理层或同事的支持。这会增加孤独感、紧张感和脱离感。

总结

我们已经研究了一些企业中最常见的反模式，这些企业有的刚刚开始微服务之旅，有的正在从更传统的架构演进实践。

这些反模式不仅会造成应用程序的瓶颈，还会由于遵循不当做法而引入的各种限制导致应用程序性能低下和崩溃。

因此，我们必须避免这些问题，以确保我们的微服务架构通过实现可扩展性、灵活性和复原力来达到预期效果。

希望对您有所帮助。

感谢您的阅读！