译:Kafka事件驱动和流处理

http://www.confluent.io/blog/event-sourcing-cqrs-stream-processing-apache-kafka-whats-connection/

Event sourcing as an application architecture pattern is rising in popularity. Event sourcing involves modeling the state changes made by applications as an immutable sequence or “log” of events. Instead of modifying the state of the application in-place, event sourcing involves storing the event that triggers the state change in an immutable log and modeling the state changes as responses to the events in the log. We previously wrote about event sourcing, Apache Kafka and how they are related. In this post, I explore these ideas further and show how stream processing and, in particular, Kafka Streams helps to put Event sourcing and CQRS into practice.

事件驱动(Event sourcing)作为应用程序架构的一种模式现在越来越流行了。事件驱动包括了将应用程序产生的状态改变数据建模成不可变的序列、或者说是事件的日志。它不是直接就地修改应用程序的状态,事件驱动会将触发状态改变的事件存储到一个不可变的日志,在日志中将状态改变建模成针对发生事件的响应。在之前的文章中,我们阐述了事件驱动和Kafka的关系。本篇文章,我们会更进一步探索这些思想,并且会展示流处理,更准确的说是Kafka Streams,怎么帮助我们将事件驱动和CQRS运用在实际中。

Let’s take an example. Consider a Facebook-like social networking app (albeit a completely hypothetical one) that updates the profiles database when a user updates their Facebook profile. There are several applications that need to be notified when a user updates their profile — the search application so the user’s profile can be reindexed to be searchable on the changed attribute; the newsfeed application so the user’s connections can find out about the profile update; the data warehouse ETL application to load the latest profile data into the central data warehouse that powers various analytical queries and so on.

举例类似于Facebook这样的社交网络应用,当用户在Facebook的设置页面更新自己的信息时会更新profiles数据库。有很多应用因为和个人信息相关,在用户更新他们的设置时,这些应用都需要被通知到。比如通知搜索应用,用户的设置可以被重新索引,被改变的属性就可以被搜索出来;通知新闻订阅应用,这样用户的连接就可以找出被更新过的设置;数据仓库应用,加载最新的设置数据到中央仓库,用于不同维护的数据查询和分析等等。


基于事件驱动的架构

Event sourcing involves changing the profile web app to model the profile update as an event — something important that happened — and write it to a central log, like a Kafka topic. In this state of the world, all the applications that need to respond to the profile update event, merely subscribe to the Kafka topic and create the respective materialized views – be it a write to cache, index the event in Elasticsearch or simply compute an in-memory aggregate. The profile web app itself also subscribes to the same Kafka topic and writes the update to the profiles database.

事件驱动会将profile应用程序的profile更新作为一个事件,写入到中央日志系统中,比如一个Kafka的主题。在这个充满状态的世界中,所有需要对profile更新事件作出响应的,所做的工作仅仅是订阅到Kafka的主题,并创建各自的物化视图(消费者读取数据,产生各自的数据),比如将其作为缓存的以写入、Elasticsearch的一个索引事件、或者只是内存中的简单聚合计算。当然profile应用程序本身也要订阅相同的Kafka主题(实际上不是订阅,而是生产,这里的意思是生产者和消费者使用相同的主题,否则生产者生产的消息没有被任何消费者订阅,就没有什么意义了。生产者这里是web应用程序产生的更新事件,消费者是下方各种数据源),并且会将更新写入到profiles数据库。

事件驱动:一些利弊

There are several advantages to modeling applications to use event sourcing — It provides a complete log of every state change ever made to an object; so troubleshooting is easier. By expressing the user intent as an ordered log of immutable events, event sourcing gives the business an audit and compliance(合规性审计) log which also has the added benefit of providing data provenance(起源). It enables resilient(弹性) applications; rolling back applications amounts to rewinding(绕回) the event log and reprocessing data. It has better performance characteristics; writes and reads can be scaled independently. It enables a loosely coupled(松耦合) application architecture; one that makes it easier to move towards a microservices-based architecture. But most importantly:

Event sourcing enables building a forward-compatible(向前兼容) application architecture — the ability to add more applications in the future that need to process the same event but create a different materialized view.

将应用程序建模成事件驱动有很多优点:它提供了针对一个对象的每个状态改变的完整日志,所以排查问题非常简单。

For the upsides mentioned above, there are some downsides as well. Event sourcing has a higher learning curve(曲线); it is a new and unfamiliar programming model. The event log might involve more work to query it as it requires converting the events into the required materialized state suitable to query.

That was a quick introduction to event sourcing and some tradeoffs. This article is not meant to go into details of event sourcing or advocate for it’s usage. You can read more about event sourcing and various tradeoffs here.

除了上面提到的一些优点,当然它也有缺点。事件驱动有更高的学习曲线,它是一种崭新的、不熟悉的编程模型。

Kafka作为事件驱动的支柱

事件驱动和CQRS

CQRS和Kafka Streams

方案1:应用程序状态存储到外部存储

方案2:应用程序状态存储到Kafka Streams的本地状态

Kafka Streams的交互式查询

交互式查询的用例

使用Kafka作为事件驱动、CQRS

零售店示例


文章目录
  1. 1. 事件驱动:一些利弊
  2. 2. Kafka作为事件驱动的支柱
  3. 3. 事件驱动和CQRS
  4. 4. CQRS和Kafka Streams
    1. 4.1. 方案1:应用程序状态存储到外部存储
    2. 4.2. 方案2:应用程序状态存储到Kafka Streams的本地状态
  5. 5. Kafka Streams的交互式查询
  6. 6. 交互式查询的用例
  7. 7. 使用Kafka作为事件驱动、CQRS
    1. 7.1. 零售店示例