事件流应用程序不执行应用程序，它们只是充当现实世界与应用程序之间的缓冲

代理为每个应用程序和主题保留一个索引，因此如果应用程序重新启动，它可以从每个队列中的下一个事件（如果它是有状态的）恢复处理,如果不是则必须再次从每个队列的开头开始,但是长时间（真实）时间重播事件是浪费的，并使应用程序进一步落后于真实世界永不停止！

每个提供有用见解的应用程序都需要一个系统来生成事件的模型

该流可用于将数据传递到机器学习管道，或修改关系数据库或图形数据库，但终有关每个事件的含义和状态变化的推理将其传达给实体和相关实体，以实现以下目的：系统总体上需要有状态的模型，该模型通常保存在数据库中,不幸的结果是，现在应用程序需要处理两个延迟源–代理程序上的主题队列和应用程序层上的数据库,两者的延迟特性都不可预测，因此无法限制响应时间。

如果将应用程序状态组织在数据库中，则事件流非常适合微服务体系结构

应用程序可以通过添加无状态微服务实例来扩展事件来进行扩展,每个实例独立地向代理询问下一个事件–避免了使用负载均衡器，并且如果一个实例失败，它可以简单地重新启动并继续。

但是应用程序始终是有状态的，将分配，一致性，可用性

负载平衡和弹性等棘手问题推到数据库层会影响性能，并终无法提供持续的智能：数据库毕竟只是反映应用程序当前模型的存储库,系统–它不会基于此进行计算。上下文也有问题：处理单个事件可能会导致数十次数据库访问，因为其连锁反应会改变许多其他实体的状态。每次访问都会增加每个事件的端到端处理延迟。

缓冲数据数据库尝试表示磁盘上系统的当前状态

但是对数据驱动的见解或响应计算的需求意味着将数据库作为状态的组织存储库的想法已不再足够,随着数据流入应用程序，应用程序逻辑（分析，学习和预测）需要实时，连续地进行,时间至关重要：如果应用程序速度太慢，它将失去跟踪并提供无用的见解，而“存储后分析”架构就会陷入这种陷阱。

不幸的是，由代理程序管理的主题队列引入了一个严重的问题：

应用程序只能按到达顺序处理主题中的事件,但是它们无法控制在时间窗口内针对给定主题进入队列的事件数，因此，如果它们处理事件的速度过慢，它们将落在后面或必须丢弃事件，从而失去保真度,但是代理程序无法将队列的到达率或深度传达给应用程序，以使其能够适当地扩展资源。

您的应用程序需要多少个主题？

如果弄错了，以后很难修复,对于导致每个主题有多个数据源的任何选择，该应用程序终可能不得不从队列中读取许多不重要或过时的事件，以找到重要的信息,因此无法限制应用程序的响应时间,对于一个有效的“每个主题一个来源”的答案，挑战在于经纪人对主题队列的限制,对于大型应用程序，即使是一百万个主题也太少了。

应用程序可能需要消耗并丢弃许多不重要的事件，然后才能找到关键事件

由于无法知道队列中可能有什么，因此无法推断应用程序的响应时间。是否总是能及时找到关键事件？

经纪人对事件的含义不屑一顾-不了解紧急性，重要性或无关紧要（它们只是队列中的事件）,因此一个应用程序可能会发现自己无法处理无用的或过时的事件，而只是为了获得关键的见解-浪费时间，无法传递实时响应。 

代理程序不会在事件之间进行推理，因此，例如一系列事件（如果相关）可能触发应用程序层响应，因此不会被解释

依赖于数据源及其状态之间的逻辑或数学关系的应用程序层见解不是代理的领域,它只是缓冲数据,如上所述应用程序需要围绕有状态模型构建，这不可避免地需要某种数据库,这使得应用程序响应时间取决于数据库往返时间（RTT），并带来了另一个更为严峻的挑战：如果应用程序的数据驱动部分仅负责更新数据库，那么它将触发并运行对结果状态的分析变化？缺乏用于分析，学习和预测的端到端架构是交付连续情报的真正障碍。

 客服热线：400-050-6600

商业联合会数据分析专业委员会