认识达内从这里开始

事件驱动架构与微服务架构都是目前软件开发项目中经常会用到的一些软件开发架构方式，而今天我们就通过案例分析来了解一下，事件驱动架构与微服务架构的区别。

一、微服务架构

过去，我们用统一的领域模型来表示销售上下文和支持上下文中的客户或产品。例如，支持联系人和销售客户被建模为单个Customer模型。随着解决方案空间变得越来越大，拥有越来越多的域，我们添加了更多的参数、属性和验证规则，有些规则只适用于一个域，而不适用于另一个域，从而导致统一代码的不必要的复杂性开销。

有界上下文(BoundedContext)——识别特定上下文范围，在该范围内，领域模型的特定术语是有效且有意义的。

在新模型中，不必在支持域的“Customer”中定义“Contact”，而是在支持域中使用正确的术语“Contact”。当与Sales域对话时，可以使用定义良好的接口将“Contact”转换为“Customer”对象。这样可以提高内聚性，减少跨不同领域的耦合。

微服务定义(Microservicesdefined)——将单个系统划分为子系统，子系统作为服务承担单一职责，通过明确定义的接口相互通信。每个服务可以自主部署，有自己独立的数据库和支持服务。每个微服务都是独立的，可以选择适合自己的技术栈、工具和实践。每个服务可以独立缩放。负责每个服务的团队规模相对较小，一个团队可能负责一个或多个微服务。每个团队只需要了解他们负责的微服务的领域知识，而不需要知道整个系统的所有内容。

缺点

初始成本较高。

必须有DevOps自动化和自动化部署。

这种分布式计算架构在处理延迟、负载均衡、日志记录、监控、处理终一致性等方面需要付出额外的时间和成本。

二、事件驱动架构(Event-DrivenArchitecture—EDA)

微服务可以通过REST调用的请求/响应机制(如JSON)相互通信，或者使用带有消息代理的事件驱动架构。现代体系架构更喜欢EDA，这样服务的响应更快、延迟更少，可以提供更健壮、可容错、有保障的服务，并允许更好的可伸缩性。

在EDA中有三个参与者，即创建触发事件的生产者、以健壮的方式携带消息的消息代理和可以订阅特定/所有事件的消费者，这些构成了“反应式编程(ReactivePrograming)”。这种模式对来自数据流的事件(触发器)做出反应，从而获得更快的响应时间和更低的延迟。

对于需要支持跨微服务事务终一致性，具有ACID属性的微服务，可以使用SAGA模式，其支持显式回滚机制来处理错误回滚。不过这种设计会变得更复杂，应该谨慎使用。

EDA还定义了事件源(EventSourcing)，作为将数据存储在DB中的新机制。在这里，DB对象永远不会被更新。相反，要获取对象的当前状态，需要按照事件到达的顺序进行处理。在事件源中，通过以固定的时间间隔创建当前状态的快照来实现性能优化。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。