事件驱动架构

点击上方“黑光技术”关注之

完美之道,不在无可增加,而在无可删减！

本文是一篇翻译，最近在看微服务架构方面的资料，看到这篇文章感觉有点意思，其实看过之后发现理论和思路应该目前大部分的架构都有了，在业界实际使用中也几乎都是这样的方案，算是一篇科普文章。而且文章也不算太长，所以试着翻译了，学习英语，也学习技术。

原文在这里：

https://dzone.com/articles/need-for-event-driven-architecture

为什么需要事件驱动架构和事件消息传递

开发微服务，我们必须处理分布式数据管理的问题。每一个微服务有它自己的私有数据，有时候是一个SQL并且有时候是NoSQL数据库。如果数据实体被多个服务拥有，那么开发这类服务将会比较有挑战，同样开发数据在多个服务上访问获取的这类服务也是有挑战的。

当你迁移到一个微服务架构的时候数据访问将会变的非常复杂。这是因为数据被每个微服务私有化存储，并且数据的访问只能通过它的API。如果多个服务访问相同的数据，则数据的更新需要消耗时间来协调所有服务。

另外一个微服务的主要问题是网络失败问题。如果任何一个服务因为网络或者其它任何问题问题而挂掉，那么一个服务就不能和其它服务通信，并且整个事务也就失败了。例如，如果服务A在尝试访问服务B，而服务B已经挂掉了，那么这个事务就失败了。

事件驱动架构

对于大多数应用，让微服务工作并且管理好分布式数据的方式就是采用事件驱动架构。已经有多种可用模式，我们本次聚焦于非常常用的模式：事件消息传递。

事件消息传递

事件驱动架构被叫做消息传递系统。一个消息简单来说就是一个事件，反之亦然一个事件也可以是一个消息。一个事件驱动系统时说：所有的模块都应该被事件通知，从而驱动系统模块工作。所以早起的实时事件驱动系统被定义为发布/订阅模式。

发布/订阅模式是另一种描述基于事件消息传递的方式。在发布/订阅方式中有发布者和订阅者。一个发布者不需要知道订阅它发布消息的任何信息。同样，订阅者也不需要知道任何发布者的信息，除非是被认证合法的发布者。

一个发布订阅系统应该为发布者提供这样的机制：找出新的订阅者并且订阅者应该可以在信息发布者可用的时候立刻找到它。

作为一个订阅者，要知道系统要保证它可以按照消息发生时间的顺序收取所有发布者发布的消息（系统的可靠性和安全性）。所有的订阅者应该在同时被通知到。

消息代理在发布者和订阅者之间扮演了一个协调者。一个代理的目的是从应用方收取消息并且让订阅者可以拿到的这些消息。消息在代理中一直会被保留，直到被相关的订阅者取走。这些都是最流行的消息代理：例如Apache Kafka，Apache ActiveMQ，RabbitMQ（Mozilla发布协议），Redis。

总结

这篇文章，讨论了在微服务中分布式数据管理的挑战和事件驱动架构使用消息传递模式如何帮助解决这些问题。

看完本文有收获？请分享给更多人

关注「黑光技术」加星标，关注大数据+微服务