オープンソースのメッセージングエンジンシステム

メッセージ・キュー」や「メッセージ・ミドルウェア」という言葉を聞いたことがあると思います。しかし、正直なところ、私は、メッセージキューはKafkaが構築するキューの方法の使用であるかのように、非常に不明確なヒントを与えるため、このタイトルは、メッセージエンジンシステムを使用することを好む;とメッセージミドルウェアの参照は、人々が最終的にミドルウェアが何をすべきかを把握することができないように、"ミドルウェア "を誇張しすぎの疑いがあります。

この種のシステムは何のためにあるのでしょうか？まずは公式の真面目な答えから。ウィキペディアの定義によると、メッセージエンジンシステムは仕様のセットです。企業はこの仕様のセットを使用して、異なるシステム間で意味的に正確なメッセージを配信し、疎結合の非同期データ配信を可能にします。確かに、これは公式の定義であり、すべてを備えています。もし理解しにくいと感じたら、以下の私の庶民的なバージョンを試してみてください：

システムAはメッセージエンジンシステムにメッセージを送信し、システムBはAから送信されたメッセージをメッセージエンジンシステムから読み取ります。

最も基本的なメッセージングエンジンはまさにそうです！どのバージョンであっても、それらはすべて2つの重要な事実を述べています：

• メッセージ・エンジンが送信するオブジェクトはメッセージです；
• メッセージがどのように送信されるかは、メッセージ・エンジンの設計メカニズムの一部です。

メッセージエンジンは、異なるシステム間でメッセージを転送するために使用されるため、転送するメッセージのフォーマットをどのように設計するかは常に大きな課題です。メッセージはどのようにしてビジネス・セマンティクスを曖昧さなく表現し、同時に最大限の再利用性と汎用性を提供できるのでしょうか。数秒間立ち止まって、メッセージのエンコード形式をどのように設計するか考えてみてください。

いったんメッセージが設計されると、メッセージ・エンジン・システムが特定のトランスポート・プロトコル、つまりメッセージを送信するために使う方法をセットアップするだけでは十分ではありません。一般的な方法は2つあります：

• ピアツーピアモデル：メッセージキューモデルとも呼ばれます。上記の定義の "フォークバージョン "を取る場合、システムAによって送信されたメッセージは、システムBによってのみ受信することができ、他のシステムは、Aによって送信されたメッセージを読むことはできません。日常生活の例では、このような電話の顧客サービスは、このモデルに属する：同じ顧客のインバウンドコールは、顧客サービススタッフによってのみ処理することができ、2番目の顧客サービススタッフは、顧客にサービスを提供することはできません。
• Publish/Subscribeモデル: 上記とは異なり、トピックという概念があります。これは、同様の論理的セマンティクスを持つメッセージコンテナとして理解することができます。このモデルにも送信者と受信者が存在しますが、呼び方が異なるだけです。送信者はパブリッシャーとも呼ばれ、受信者はサブスクライバーとも呼ばれます。ピアツーピアモデルとは異なり、このモデルでは、同じトピックにメッセージを送信する複数のパブリッシャーと、同じトピックのメッセージを受信する複数のサブスクライバーを持つことができます。典型的なパブリッシュ/サブスクライブモデルは、新聞購読です。

素晴らしいのは、Kafkaが両方のメッセージエンジンモデルをサポートしていることです。

メッセージエンジンシステムというと、JMSとの関係を聞かれるかもしれません。 JMSとはJava Message Serviceのことで、上記2つのメッセージエンジンモデルにも対応しています。JMSとはJava Message Serviceのことで、上記の2つのメッセージエンジンモデルをサポートしています。 JMSは厳密にはトランスポートプロトコルではなく、単なるAPIのセットです。しかし、JMSは、ActiveMQ、RabbitMQ、IBMのWebSphere MQとApache Kafkaのような多くの主要なメッセージエンジンシステムは、JMS仕様をサポートしているように有名かもしれません。

さて、ここまではメッセージエンジンシステムが何をしているのか、どのようにするのかを理解しただけですが、なぜそれを使うのかという重要な疑問があります。上記の "民間版 "を例にとると、「なぜシステムAは、メッセージエンジンの途中で、システムBに直接メッセージを送ることができないのか？答えは"山と谷"です。この4つの単語は、単にメッセージエンジン自体よりも有名です。

いろいろな文献を調べましたが、この4つの言葉が一番多いですね。いわゆる「山と谷」とは、上流と下流の瞬間的なバーストトラフィックをバッファリングしてスムーズにすることです。特に上流システムの送信能力が強い種類の場合、メッセージエンジンの保護がなければ、「もろい」下流システムが直接圧倒され、リンクサービス全体が「雪崩」を起こす可能性があります。しかし、メッセージエンジンがあれば、上流のトラフィックの影響を効果的に打ち消し、上流の「山」を「谷」に埋めて、トラフィックショックを回避することができます。メッセージエンジンシステムのもう一つの大きな利点は、送信側と受信側の結合が緩やかであることで、アプリケーション開発がある程度簡素化され、システム間の不要な相互作用が減少します。

この問題を解決する一般的なアプローチは、上流システムに速度制限を課すことですが、このアプローチは上流システムにとって明らかに不合理です。そこで、より一般的なアプローチは、Kafkaのようなメッセージエンジンシステムを導入して、上流システムと下流システム間のTPSと一時的なピークトラフィックのミスマッチに対処することです。

Kafkaが導入された場合の例です。アップストリームのオーダーサービスは、ダウンストリームのサブサービスと直接やり取りすることはありません。新しい注文が発生すると、Kafka Brokerに注文メッセージを送信するだけです。同様に、下流の各サブサービスはKafkaの対応するトピックをサブスクライブし、そのトピックの各パーティションから注文メッセージをリアルタイムで取得して処理するため、上流の注文サービスと下流の注文処理サービスは切り離されます。こうすることで、ビジネスが急増したときに、Kafkaは対応するトピックに保存されたメッセージの形で、オーダーのトラフィックを瞬時に増加させることができ、上流サービスのTPSに影響を与えず、下流のサブサービスにも十分な消費時間を残すことができます。これがKafkaのようなメッセージエンジンシステムの最大の意義です。

Kafka Broker、トピック、パーティションなどの用語に馴染みがなくても心配しないでください。このコラムの後半で、一般的なKafkaの概念や用語について説明します。

オフトピック

RocketMQは金融ビジネスのシナリオに特化していると主張していますが、私は個人的にそう信じています。

Kafkaはメッセージング・エンジンとして始まり、後にストリーム処理プラットフォームへと変貌を遂げました。悪気はないのですが、私はメッセージングエンジンをストリーム処理の一種だとは思っていません。実際、ストリーム処理は無限のデータセットをどのように扱うかに関心があります。両者は異なる領域です。）

MQとRPCの違いは、データフローのパターンの問題に属します。1.データベース経由、2.サービスコール経由、3.非同期メッセージング経由 RPCとMQは似ています：

1. MQは、過負荷や利用不可能なシナリオに対処するための独自のバッファを持っています。
2. MQは再試行をサポートします。
3. パブリッシュ/サブスクライブ・パターンを許可 もちろん、両者には他にも違いがあります。RPCはデータベース経由とMQ経由の間のデータフローパターンであると言うべきです。

• Kafka