事件流处理的问题解决

使用事件流解决问题的方法。

2022年11月9日:

解决事件流问题

请看我们的数据社区中出色的创新者们所面临的挑战以及事件流的帮助解决这些问题之处(还有朋友们给予的一些小小帮助)。

介绍了James Jobs AG

我是尼克,正在James Job工作。James Job是一家能够革新寻找符合你技能的职位信息的初创公司。

在招聘广告中寻找适合自己的工作确实是一件麻烦的事情。在James Job上,只要你确定自己的技能背景,系统会为你筛选出符合你技能要求的职位广告。

为了只显示相关的职位广告,我们采用了一种在后台进行大量计算的架构。这些变化(例如职位广告的更改和新技能的学习)会引发我们系统中的许多计算。Apache Kafka®为我们提供了完美的支持。

对于我们这样的新兴企业来说,能够迅速灵活地构建新的创意和使用案例非常重要。具备活跃的数据和(必要时)无限保存的数据,正是我们手中的利器。

此外,仅凭这个还不够的话,我们也是Aiven的Crabby的狂热粉丝。

对于沟通的挑战

微服务和纳米服务的兴起实际上意味着需要连接更多的组件。使用API、RPC等可以实现这一点,但这意味着组件之间紧密耦合。对一个服务进行更改可能会导致后续变更的连锁反应。我希望通过使用事件能够使所有事情变得更加自由和灵活。

无论是什么服务,都可以开始发送和监听事件。数据在系统中流动,是一个开放的世界,有许多可能性。下面的章节中,将简要概述一些优点和问题。

我们已经拥有很多数据,但在大多数情况下,这些数据都是静止在数据库、索引、文件等中的。为了获取所需的数据,我们必须克服一些障碍。

需要了解: (zhī bì

    • どこでそれを見つけるか(多くのデータシステムと構造)

 

    • どのようにアクセスするか(統合)

 

    データ構造がどのように機能するか(一般的にドキュメントはない)

活动的使用

    • データへのアクセスが合理化される

 

    • データ構造が文書化されている(Avro、Protobufなど)

 

    優れた命名ポリシーにより、データを見つけやすい。

没有系统崩溃

让我们从一个简单的例子开始:用户注册。

注册过程可能包含各种不同的输入字段,延续数页的流程。

最令人沮丧的是,在点击最后的注册按钮后,出现错误提示要稍后再试!这不仅令人感到烦躁,而且缺乏明确的具体信息,难以提供帮助。

如果使用事件的话,您可以最大限度地减少当注册服务发生故障时对用户的影响。

只需将事件发送到Apache Kafka®。

一旦注册服务恢复正常,用户立即收到有关注册事件的处理通知,确认账户已成功创建的电子邮件。

虽然账号不能立即创建仍然让人担心,但用户无需再次进行注册流程。这对每个人都是胜利。

历史重演

历史总是重复的。

在Apache Kafka®中,您可以选择对事件进行无限期保留。这样做有什么好处呢?

假设一年后,我们想要给最初的100个顾客送出一个意外的礼物,但是我们忘记保存用户的创建日期了。

如果没有活动,这是不可能的难题。然而,如果有活动,可以重新播放注册活动并找到幸运的获奖者。

这不一定是一个常见的情节,但它展示了利用过去的数据重建事件来构建新的用例的方法。

如果不再需要从现有系统中提取和转换数据,那么从零开始构建新服务将变得更加容易。所需的是

    • 必要なデータ・ストリームを特定する

 

    • 過去のイベントを再生する

 

    必要に応じて、これらのイベントを永続化/変換/リアクトする

这个东西多年来在许多使用场景中都节省了时间。它促使我们更深入思考数据,并让许多事情变得简单。

与其努力创建适应各种需求的数据结构,不如在组件需要时轻松构建自定义数据投影。结果是,所有组件都变得更加独立。

迟到

在某个时间点发送事件意味着发生了某种情况。

根据情况不同,可能会依赖系统内发生的其他事件。

由于所有组件都是解耦的,所以没有直接与组件通信的方法。

假设一个用户在那里注册了电子邮件地址和住址。另外,假设他们选择了两个活动:

    • ユーザーアカウントイベント

 

    ユーザ・アドレス・イベント

用户注册后,将被重定向到其个人资料页面。由于这些事件将由不同的系统进行处理,因此可能会发生以下情况:

    • ユーザーアカウントはまだ作成中です。

 

    • アドレスサービスがダウンしている。

 

    アドレス・サービスは稼動しているが、ユーザー・サービスより速い。

这类问题常常存在,即使在数据静止的时候。然而,对于事件,我们倾向于更频繁地考虑它。

不确定性给系统带来了挑战。那么,在事件驱动架构中,如何解决这个问题呢?

要建立一个更好的系统,以下是一些有用的事情(还有其他很多):

    • 欠損データに対する耐性

 

    • 柔軟なデータロード(例:スケルトンのロード)

 

    他のコンポーネントで起きていることに関するライブイベント(プッシュ通知)

假设地址服务变慢,我们已经能够查看到帐户信息,地址会有加载状态,并且在数据可用后立即刷新(推送对拉取)。

由于Apache Kafka®具有非常高的吞吐量,因此在许多情况下,延迟并不明显,但最好始终考虑到意外情况。

结论是

在任何技术上,都存在优点和问题。多年来,我发现事件流架构的优点远远超过了问题。

Apache Kafka®有陡峭的学习曲线!

一旦接受“事件优先”这个思维模式,应用程序将变得更灵活、稳定和可塑。由于Apache Kafka拥有出色的综合生态系统,将会开放许多新的机会和案例。

迄今的路程真是非常美妙的一段历程。

我們衷心感謝 Aiven 團隊的每一位成員,他們長期以來一直是我們建築事業中可靠且出色的合作夥伴,使我們得以成長壯大。?

关于尼克。

倪克·赵(Nick Chiu)是James Job AG的首席技术创新官(CTIO),他在一家致力于为求职者提供最佳工作机会的初创企业工作,力求以最少的努力实现这一目标。他在软件服务建设领域已经工作了二十多年,在不同行业中工作的机会使他获得了关于解决方案架构的许多深入见解。他自五年前开始专注于事件驱动系统,并且通过多年的构建证明了这个方案的优秀性。他热爱美食和漫画。

要获取关于Aiven和我们的服务的最新消息以及有关开源的各种信息,请订阅我们的每月简报!关于Aiven的日常新闻也可以在LinkedIn和Twitter的动态中查看。

广告
将在 10 秒后关闭
bannerAds