转载

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

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

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

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

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

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

问题:

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

解决方案:

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

应用:

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

影响:

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

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

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

目标:

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

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

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

主要特点:

1、异步通信机制将带来高效的IPC(Inter-Process Communication,进程间通信)。

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

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

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

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

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

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

原文  https://segmentfault.com/a/1190000020061023
正文到此结束
Loading...