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

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

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

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

问题：

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

解决方案：

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

应用：

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

影响：

一、增长复杂性，由于这种模式让状态以一种新的方式更改和移动。

二、不提供任何标准模式，实现多是不一致的，除非创建并实践统一的标准。

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

目标：

一、内聚性：因为其标准化的特性，事件驱动架构很是容易使用和理解。

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

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

主要特色：

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

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

三、经过特定的一致性模型，提升了数据一致性和状态管理能力；任何给定的状态都是事件的重构四、因为与面向消息设计模式的类似性，在事件与命令混合的地方可能会出现混淆。

五、该模式具有合理的可操做性以及有效的可扩展性。

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

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

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