微服务应该遵循的6种设计模式

曾经被认为是最热门的新兴技术之一，微服务现在已被广泛采用，作为解决大型复杂基础设施的一种方式。

传统应用程序充当单体，这意味着它们是单个自包含的项目，而基于微服务的应用程序由多个构建块组成，这些构建块可以组合在一起以更快地启动和运行新的应用程序和服务。

什么是微服务模式？

可以将大型应用程序结构分解为更小的独立服务的六大微服务模式。

1. 细粒度的 SOA

刚开始时，细粒度的 SOA 是最常见的微服务方法。这种模式应用了与面向服务的架构相同的原则，但通过将基础架构分解成更小、更细化的部分来减少通常会出现的问题。

在大多数情况下，此模式是 SOA 集成的扩展，其中每个服务都提供与外部系统的连接。这对那些外部存储形成了紧密的依赖关系，从而降低了更改的速度，并使系统的凝聚力反映了这些应用程序的内部状态。

2. 细粒度 SOA 上的分层 API

细粒度 SOA 模式的下一个演变是在其上分层 API。在大多数情况下，这两种模式会共存。细粒度 SOA 方法之上的分层 API 与API 主导的连接密切相关。在这两者中，系统 API 公开应用程序，流程 API 编排它们，体验 API 提供最终用户体验。

当缺乏结构时，微服务架构可能难以合理化，从而难以对每个微服务的目的进行分类和可视化。这种模式通过将微服务组织成按目的（系统、流程或领域模型和经验）分组的层来创建一些结构，并使架构更易于管理。

3. 基于分层 API 的面向消息的状态管理

前两种模式缺乏状态管理能力，这意味着使用它们实现的微服务缺乏数据完整性。基于分层 API 模式的面向消息的状态管理通过在微服务或数据存储之间复制关键业务数据的状态来确保数据完整性。

这使系统能够聚合事件并使用消息队列提供一致的外部视图，从而允许将状态异步发送到不同的位置或通过其他微服务进行查询。通过解耦组件，每个微服务的实现和行为变得模糊。

4. 分层 API 上的事件驱动状态管理

组织利用事件驱动模式进行REST API和同步通信不提供的实时数据更新；这对于欺诈检测、工作流通知、新闻提要和股票报价等用例至关重要。事件驱动系统使用队列（如面向消息的系统），但对通过队列传递的内容（特别是事件）的设计和行为强制执行标准。

事件是与代表状态和时间戳相关联的动作。此事件允许任何接收它的服务通过按顺序重放事件来重建状态的物化视图。

5. 分层 API 中的隔离状态

事件驱动微服务的另一种方法是在每个单独的微服务中添加持久性。这种模式在查询时而不是在交换时实现一致性，并通过隔离每个微服务的状态来实现这一点，这样每个微服务都包含自己的状态。

在这种模式下，每个微服务都成为其自身的单一事实来源，并包含一个不断与外部存储协调的内部数据存储——无论它们是事件日志还是企业资产。单一事实来源模式倾向于看到复杂的问题（类似于主数据管理中看到的问题），但是当使用外部存储时，这可以简化。

6. 在分层 API 中复制状态（事件溯源）

复制状态本质上与隔离状态相反，因为需要一致性。在隔离状态下，微服务变得相互依赖，单个微服务中的故障可能导致其他微服务失败。复制状态提供了一个存储所有状态突变的地方，每个隔离的微服务都可以在其中重建其内部状态。

复制状态需要对每个微服务的管理流程和行为有更深入的了解才能进行预测。从本质上讲，这种设计最终是一致的。虽然这在传统的事务设计中似乎是一个问题，但通过深入了解设计的性质，它得到了缓解。这可以实现更大的自由度和变更速度，并最终更快地实现价值。