六种常用的微服务架构设计模式 第四种模式

第四种模式：分层API架构上事件驱动的状态管理

事件驱动并不是一个新的设计模式。许多ESB最初的设计模式就是一个事件驱动系统。当在微服务体系上实施事件驱动架构时，它能够提供一些强大的抽象。事件驱动系统通常使用某种类型的队列（类似于面向消息的系统），但是围绕队列所传递内容的设计和行为，强制执行一个标准；具体来说，就是事件。

人们经常将事件驱动模式与其他模式相混淆，因此在事件驱动模式中涵盖了大量的设计。严格地说，事件是关于过去发生的，具有相关代表性状态和时间戳的东西。事件允许接收它的服务通过按顺序重放事件来重建状态的物化视图。然而，在许多实现中，往往将事件（已经发生了的事情）与命令（让某件事情发生）混淆在一起。如果事件和命令不进行区分的话，架构设计的可预测性是有缺陷的。也就是说，不可否认，事件驱动的设计模式优于面向消息的方法（因为事件驱动的设计更为具体）；但是由于事件驱动的设计模式缺乏一致性，在实现中往往会出现问题。但是，鼓励并执行一致标准的团队会发现，事件驱动的设计模式能够在微服务体系结构中工作得很好。

问题：

为了确保系统内数据的完整性，需要复制关键业务事件，以便在微服务或数据存储之间进行同步。

解决方案：

使用常见的事件抽象来表示系统中的发生变化的组件。

应用：

当业务发生改变时，将其封装成过去时的事件，并发送给相关方。业务中的更改就是发送和处理这些事件的产物。

影响：

1、增加复杂性，因为这种模式让状态以一种新的方式更改和移动。

2、不提供任何标准模式，实现可能是不一致的，除非建立并实践统一的标准。

3、对于在发生故障时如何处理数据冲突或重建状态，不提供任何具体的解决方案。

目标：

1、内聚性：由于其标准化的特性，事件驱动架构非常容易使用和理解。

2、可伸缩性：事件驱动的设计模式需要更深层次的技术决策（如何发送/处理/存储事件？以及重传？），但是在这种模式下可伸缩性是可实现的。

3、更改的速度：会受到更具内聚性的架构影响，如果没有依赖性分析，管理手段有点过于依赖团队的知识和运气。

主要特点：

1、异步通信机制将带来高效的IPC（Inter-Process Communication，进程间通信）。

2、丧失了设计的灵活性，取而代之的是可预测的行为。

3、通过特定的一致性模型，提高了数据一致性和状态管理能力；任何给定的状态都是事件的重构4、由于与面向消息设计模式的相似性，在事件与命令混合的地方可能会出现混淆。

5、该模式具备合理的可操作性以及有效的可扩展性。

6、该模式在具备一致性能力时有很强的内聚力，但内聚力往往随时间推移而变弱。

分层API架构上事件驱动的状态管理模式如何与现有系统、SOA或API共存？

事件驱动系统可以与现有系统共存，但这两个系统之间往往需要一个“转换层”，这个“转换层”跨越体系结构中事件驱动部分与非事件驱动部分的边界。本质上，事件驱动系统在其架构内部使用一致的语言，其架构外部的任何内容都需要转换（输入或输出）才能参与进来。分层API架构上事件驱动的状态管理模式提供了一种清晰的方法，将体系结构中的事件驱动部分与传统集成和企业系统分离开来，但这确实意味着，您倾向于使用事件驱动的微服务创建“新”功能，这些微服务可以在其他地方更新，或与边界外的系统和API同步。