私の JavaScript の旅: コールバックから Kafka まで – イベント駆動型システムのカオスを受け入れる

JavaScript: 単純なコールバックから Kafka とイベント駆動型アーキテクチャの複雑な世界への私の旅。 私は当初、ブラウザと Node.js の両方で console.log を使用できるため、フルスタック開発者になれると信じていましたが、その後その考えは修正されました。 私の経験には、React、Node.js、Sequelize、および async/await のトライアルが含まれます。しかし、イベント駆動型アーキテクチャでは真の課題が到来しました。

好奇心 (そしてもっとデバッグしたいという自虐的な欲求!) に駆られて、私は飛び込んでみました。

?私とつながってください

• ウェブサイト: elvissautet.com – 私のプロジェクトとポートフォリオを探索してください!
• LinkedIn: linkedin.com/in/elvissautet
• Twitter: twitter.com/elvisautte
• Facebook ページ: fb.me/elvissautet

協力して素晴らしいものを作りましょう! ?

?従来のシステムの限界

私の過去のアプリケーションは、ユーザーのアクション、フロントエンドのリクエスト、バックエンドの処理、データベースの対話、そして (できれば) 成功したレスポンスという、標準的なリクエストとレスポンスのパターンにほぼ従っていました。 理論的には単純です。 ただし、スケーリングによって次のような欠陥が明らかになりました。

• 大量のリクエスト: 1 秒あたり数千のリクエストをどのように処理しますか?
• タスクの所要時間は変動します: 一部のタスクに他のタスクよりも大幅に時間がかかる場合はどうなりますか?
• 同時操作: 支払い、通知、ログ記録、およびシステム全体の安定性を同時に管理するにはどうすればよいですか?

イベント駆動型システムはソリューションを提供します。 逐次処理の代わりに、独立したコンポーネントがイベントを通じて通信できるようになります。 賑やかなレストランのキッチンを思い浮かべてください。誰もが自分の役割を理解し、注文 (イベント) が効率的に流れる、組織化されたカオスです。

⚡ イベント、キュー、Pub/Sub

オンラインの自動車マーケットプレイスを考えてみましょう。 ユーザーが車をリストすると、データベースの更新、通知、検索インデックスの変更を処理するバックエンドの代わりに、car.posted イベントが発行されます。 その後、さまざまなシステム部分がこのイベントに非同期的に反応します。

?メッセージキュー (BullMQ)

• 遅延処理に最適です。
• 例: 高解像度画像のアップロード。 BullMQ は、即時の処理とユーザーの待ち時間の代わりに、画像圧縮タスクをキューに入れます。後でワーカーが画像を処理し、リストを更新します。

?イベントストリーミング (Apache Kafka)

• 毎秒数百万のイベントを処理するために不可欠です。
• 例: ユーザーのクリック、検索、購入の追跡。 リアルタイムのデータベース書き込みの代わりに、このデータを Kafka にストリーミングして、効率的な処理とストレージを実現します。

? Pub/Sub (Redis、RabbitMQ、Kafka)

• リアルタイムの更新に最適です。
• 例: 購入者と販売者のチャット。 サーバーを定期的にポーリングする代わりに、チャット システムは新しいメッセージ イベントをリッスンし、即座に更新します。

?スケーラビリティと復元力

イベント駆動型システムは本質的に拡張性に優れています。 ストレスがかかると障害が発生しやすいモノリシック システムの代わりに、モジュール式でフォールト トレラントな分散型アーキテクチャが得られます。 さらに処理が必要ですか?労働者をさらに追加してください!

ウーバーはその代表的な例です。 配車リクエストにより、ドライバーのマッチング、運賃計算、位置情報の更新、通知などの多数のイベントがトリガーされます。 イベント駆動型アーキテクチャがなければ、Uber のシステムは崩壊する可能性があります。

?イベント駆動型システムによるスケーリング

<code>graph LR
  A[User Action] -->|Emit Event| B[Event Bus]
  B -->|Queue Job| C[Worker 1]
  B -->|Queue Job| D[Worker 2]
  B -->|Queue Job| E[Worker 3]
  C -->|Processes Task| F[Database Update]
  D -->|Processes Task| G[Send Notification]
  E -->|Processes Task| H[Log Activity]</code>

?私のモチベーション

主に好奇心です。 従来の Web アプリは機能しますが、スケーリングの制限にぶつかります。 長い API リクエストとデータベースのボトルネックとの絶え間ない格闘により、より良いアプローチを模索するようになりました。 イベント駆動型のアーキテクチャは、JavaScript の超大国であるように感じられ、より高速で復元力が高く、将来性のあるシステムを作成できます。

私の旅には、Kafka、BullMQ、WebSocket、そしてリクエストベースからイベントベースの考え方への移行が含まれています。 難しいですが、やりがいがあります。

バックエンドの制限にうんざりしている場合は、イベント駆動型アーキテクチャを検討してください。 注意してください – 中毒性があります!

? 次: 実践的な Node.js イベント駆動型システムの実装。乞うご期待!

以上が私の JavaScript の旅: コールバックから Kafka まで – イベント駆動型システムのカオスを受け入れるの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。