将来，数据将像现在的基础设施一样自动化和自助服务。您将打开一个控制台，列出贵公司可用的数据;定义您需要的部分，您想要的格式以及您希望它们如何结合在一起;启动一个新的端点：一个数据库，缓存，微服务或无服务器功能，你就可以了。

这些是现代时代的事件驱动架构 - 但消息传递不仅仅是将系统连接在一起的简单管道。部件消息传递系统，部分分布式数据库，流式系统允许您在公司内部存储，Join，聚合和改造数据，然后在需要的地方推送数据，无论是笨重的数据仓库还是微小的无服务器功能。

与公共云和私有云结合使用时，可以动态配置基础架构，从而使数据完全自助服务。许多公司已经实施了这个未来的某些版本。

他们采取的不同方法可分为四大类，我们看到的公司和项目通常一次采用一种：

• 1.全球事件流媒体平台
• 2.中央活动商店
• 3.事件优先和事件流应用程序
• 4.自动数据配置

我们所知道的任何一家公司都没有掌握它们，但所有这些类别都以某种形式存在于生产中。

1.全局事件流平台

这是最容易理解的，因为它类似于旧的企业消息传递模式。组织采用事件驱动的方法，使用流经ApacheKafka®等事件流平台的核心数据集（应用程序之间共享的数据集，如订单，客户，支付，账户，交易等）。

这些通过单一基础架构取代了传统的点对点通信，使应用程序可以在不同地理位置或云提供商中大规模，实时地运行。

因此，一家公司可能在旧金山运行旧式大型机，在开普敦和伦敦设有区域办事处，并且在AWS和GCP上运行高度可用的微服务，所有这些都与相同的事件主干相连。更极端的用例包括通过卫星或汽车通过移动连接船只。

公司几乎在每个行业都实施这种模式。例如Netflix，Audi，Salesforce，HomeAway，ING和RBC，仅举几例。

 

2.中央事件存储

流平台可以在一段定义的时间段内缓存事件或无限期地存储它们，从而创建一个类型或组织分类帐或事件存储。

一些公司使用这种模式来推动回顾性分析，例如，训练在一级方程式赛后分析中用于欺诈检测或倒带时间的机器学习模型。其他人将模式应用于许多团队。

这样就可以构建新的应用程序，而无需源系统重新发布先前的事件，这一特性对于难以从其原始源重放的数据集非常有用，例如大型机，外部或遗留系统。

一些组织将所有数据保存在Kafka中。该模式被称为前向事件缓存，事件流作为事实的来源，kappa架构或简单事件溯源。

最后，有状态流处理需要事件存储，这通常用于从许多不同的数据源创建丰富的，自给自足的事件。例如，这可能是通过客户或帐户信息丰富订单。

丰富的事件更容易从微服务或FaaS实现中消费，因为它们提供了服务所需的所有数据。它们还可用于为数据库提供非规范化输入。执行这些丰富的流处理器需要事件存储来保存支持表格操作的数据（Join客户，帐户等）。

 

3.事件优先和事件流应用

大多数传统应用程序通过将来自不同位置的数据集导入其数据库（例如，ETL）来工作，在数据库中可以对其进行清理，连接，过滤和聚合。

对于创建报告，仪表板，在线服务等的应用程序，这仍然是最佳选择，但对于业务处理，通过将实时事件直接推送到微服务或无服务器功能来跳过数据库步骤通常更有效。

在这种方法中，像Kafka Streams或KSQL这样的流处理器通过在将事件流推入微服务或FaaS之前清理，Join，过滤和聚合事件流来执行数据库在传统方法中所执行的数据操作。

例如，考虑使用像KSQL这样的流处理器将订单和付款连接在一起的限制检查服务，提取相关的记录/字段并将它们传递到微服务或作为检查限制的服务的功能 - 没有数据库的工作流程完全使用。

由于它们的事件驱动性质，这样的系统响应更快。它们通常也更简单，构建速度更快，因为维护的基础架构和数据更少，工具集自然可以处理异步连接的环境。

更丰富的示例直接包含流分析，例如检测信用卡支付中的异常行为或优化智能电网中的能量输送。这样的系统通常作为链存在，其中阶段分离有状态和无状态操作，可以独立地扩展并利用事务保证来保证正确性。

我们看到这种类型的应用程序出现在许多行业中：金融，游戏，零售，物联网等，跨越离线和在线用例。

 

4.自动数据分配

最终模式是其他模式的结晶，与PaaS /无服务器实现相结合，使数据配置完全自助服务。

用户定义他们需要的数据（实时或历史），应采取的形式以及应该在何处落地，无论是在数据库，分布式缓存，微服务，FaaS还是在任何地方。 （通常，这与可发现的模式的中央存储库结合使用。）

系统配置基础架构，在必要时预先填充它并管理事件流。流处理器过滤，操作和缓冲各种共享数据流，并根据用户的规范进行模拟。

因此，进行风险分析的财务用户可能会启动一个新的Elasticsearch实例，该实例预先填充了三个月的交易，风险结果和账簿。或者，零售公司可能会关联实时订单，付款和客户数据，并将其推送到微服务或FaaS，向客户发送付款确认。

随着组织转向公共云和私有云，基于云的基础架构的动态特性使这种模式越来越实用，从而带来系统性好处。可以快速启动新项目，环境或实验。

由于数据集被缓存或存储在消息传递系统中，因此鼓励用户仅在某个时间点获取他们需要的数据（与传统消息传递不同，传统消息传递倾向于消耗和保留整个数据集以防以后再次需要）。这可以最大限度地减少团队之间的摩擦，并使应用程序接近单一，共享的真实来源。

我们所知道的组织很少能够完全达到这种自动化水平，但这种模式的核心要素被用于金融，零售和互联网领域的几个客户的生产中，无论是在内部还是在云中。

 

事件驱动2.0：一个进化和一个新的开始

多年来，事件驱动的架构自然发展。最初，他们只进行了消息传递：通过传统消息系统应用的通知和状态转移。

后来，企业服务总线通过更丰富的开箱即用连接和更好的集中控制来点缀它们。集中控制变成了喜忧参半，因为它提供的标准化经常使团队进步更加困难。

最近，像事件溯源(Event Sourcing)和CQRS这样的存储模式已经变得很流行，正如Martin Fowler在他的文章中所讨论的“事件驱动”是什么意思？

我所描述的四种模式都建立在这个基础上，但今天的现代事件流系统使我们能够通过将事件，存储和处理统一到一个平台中来进一步发展。这种统一很重要，因为这些系统不是将数据锁定在一个地方的数据库;它们不是消息传递系统，数据是短暂的和短暂的。他们坐在两者之间。

通过在这两个传统类别之间取得平衡，公司已经能够跨地区和跨云实现全球连接，数据 - 他们最宝贵的商品 - 作为服务提供，无论是否意味着将其推入数据库，缓存，机器学习模型，微服务或无服务器功能。

所以，总结一下：

• 广播事件
• 缓存日志中的共享数据集并使其可被发现。
• 让用户直接操纵事件流（例如，使用像KSQL这样的流媒体引擎）
• 驱动简单的微服务或FaaS，或在您选择的数据库中创建特定于用例的视图