Pulsar: 次世代メッセージングエンジンは本当にそれほど強力なのでしょうか?

[[394573]]

背景

現在、新しいサービスのための技術を選定しており、メッセージミドルウェアの選定も行っています。実際の状況を踏まえると、以下の要件を満たすことができると期待しています。

クラウドネイティブ対応が親切：現在のメイン言語はGoなので、操作やメンテナンスも簡単です。
公式 SDK は複数の言語をサポートしていますが、Python および Java 関連のコードはまだメンテナンスが必要です。
遅延メッセージ、デッドレターキュー、マルチテナントなどの便利で使いやすい機能があれば最高です。

もちろん、水平拡張、スループット、低レイテンシなど、詳しく説明する必要のない機能もあります。ほぼすべての成熟したメッセージミドルウェアは、これらの要件を満たすことができます。

上記のスクリーニング条件に基づいて、Pulsar が私たちの視界に入りました。

Apache のトップレベルプロジェクトとして、上記の機能は十分にサポートされます。

それでは、何がそんなに特別なのか見てみましょう。

建築

公式のアーキテクチャ図から、Pulsar は主に次のコンポーネントで構成されていることがわかります。

ブローカーは、水平方向に拡張できるステートレスコンポーネントです。主にプロデューサーとコンシューマーの接続に使用されます。 Kafka のブローカーに似ていますが、データストレージ機能がないため、拡張が容易です。
BookKeeper クラスター: 主にデータの永続的な保存に使用されます。
Zookeeper はブローカーと BookKeeper のメタデータを保存するために使用されます。

一見すると、Kafka が依存するコンポーネントの数よりも多くのコンポーネントがあり、システムの複雑さが増しているように見えます。しかし、そのメリットも明らかです。

Pulsar はストレージとコンピューティングが分離されているため、容量の拡張が必要な場合でも非常に簡単です。他の精神的な負担なしに、新しいブローカーを直接追加できます。

ストレージがボトルネックになった場合は、BookKeeper を拡張するだけで済みます。 BookKeeper が自動的に負荷を処理するため、手動で再バランス調整する必要はありません。

同じ操作でも、Kafka ははるかに複雑です。

特性

マルチテナント

マルチテナント機能も厳密に必要な機能であり、異なるビジネスやチームのデータを同じクラスター内で分離できます。

永続的://core/順序/作成-順序

このトピック名を例にとると、コアテナントの下に order 名前空間があり、最後に create-order トピック名があります。

実際の使用では、テナントは一般的にビジネスチームごとに分割され、名前空間は現在のチームの下にある異なるビジネスです。これにより、トピックを明確に管理できるようになります。

通常、比較しなくても害はありません。マルチテナントのないメッセージミドルウェアでは、このような問題にどのように対処しますか?

あまり細かく分けず、すべての事業ラインを一緒に使う方が良いでしょう。チームが小さい場合、これは大きな問題ではないかもしれません。しかし、事業が拡大すると管理が非常に面倒になります。
トピックの前に抽象化レイヤーを作成しますが、本質的にはマルチテナントも実装しています。
各ビジネスチームが独自のクラスターを維持することで、確かに問題は解決できますが、運用と保守の複雑さは当然増大します。

上記は、マルチテナンシーの重要性を明確に示しています。

関数

Pulsar は、特定のメッセージを別のトピックに公開する前にクリーンアップして変換する必要があるなどの軽量関数コンピューティングもサポートしています。

このタイプの要件に対しては、単純な関数を記述できます。 Pulsar は、データを簡単に処理し、最終的に公式ツールを使用してブローカーに公開できる SDK を提供します。

これまでは、このような単純な要件でも、ストリーム処理エンジンを自分で処理する必要があったかもしれません。

応用

これらを除けば、プロデューサーやコンシューマーなどの上位レベルのアプリケーションの概念と使用法は、すべての人にとって同様です。

たとえば、Pulsar は次の 4 つの消費モードをサポートしています。

排他: 排他モードでは、一度に 1 つのコンシューマーのみがデータを開始して消費できます。 SubscriptionName は同じコンシューマーであることを示します) であり、適用範囲が狭くなります。
フェイルオーバーモード: 排他モードに基づいて、複数のコンシューマーを同時に起動できます。消費者が失敗すると、他の消費者がすぐに引き継ぐことができますが、消費できるのは 1 つの消費者だけです。いくつかのシナリオでは利用可能です。
共有モード: N 個のコンシューマーが同時に実行でき、メッセージはラウンドロビンモードで各コンシューマーに配信されます。コンシューマーがクラッシュして ack を受信しない場合、メッセージは他のコンシューマーに配信されます。この消費モデルは消費能力を向上させることができますが、メッセージは整然としたものになりません。
KeyShared 共有モード: 共有モードに基づきます。これは、同じトピック内のメッセージをグループ化することと同じです。同じグループ内のメッセージは、同じコンシューマーによってのみ順番に消費されます。

3 番目の共有消費モードが最も一般的に使用されるはずです。 KeyShared モードは、メッセージにシーケンス要件がある場合に使用できます。

開発キット

公式にサポートされている SDK は非常に豊富です。公式 SDK をベースに内部で使用する SDK もカプセル化しました。

dig のような軽量の依存性注入ライブラリを使用するため、次のようになります。

 SetUpPulsar(ルックアップURL)
コンテナ:= dig.New()
コンテナ.Provide(func() ConsumerConfigInstance {
 return NewConsumer(&pulsar.ConsumerOptions{
  トピック: "persistent://core/order/create-order" 、
  サブスクリプション名: "order-sub" 、
  タイプ: pulsar.Shared、
名前: "consumer01" 、
 }, コンシューマーオーダー) 
 
 }) 
 
コンテナ.Provide(func() ConsumerConfigInstance {
 return NewConsumer(&pulsar.ConsumerOptions{
  トピック: "persistent://core/order/update-order" 、
  サブスクリプション名: "order-sub" 、
  タイプ: pulsar.Shared、
名前: "consumer02" 、
 }, 消費者請求書) 
 
 }) 
 
コンテナを起動します(StartConsumer)

2 つの container.Provide() 関数は、コンシューマーオブジェクトを挿入するために使用されます。

container.Invoke(StartConsumer) は、コンテナーからすべてのコンシューマーオブジェクトを取り出し、同時に消費を開始します。

当時、私の限られた Go 開発経験から、次のような疑問も考えていました。Go では依存性注入は必要なのか?

まず、Dig のようなライブラリを使用する利点を見てみましょう。

オブジェクトはコンテナによって管理されるため、シングルトンを実装するのに非常に便利です。
オブジェクト間の依存関係が複雑な場合、オブジェクトの作成と取得のためのコードを大幅に削減でき、依存関係が明確になります。

同様の欠点も存在します:

コードを読むときにトレースはあまり直感的ではなく、依存オブジェクトがどのように作成されるかを一目で確認することはできません。
これは Go が提唱するシンプルさと矛盾しています。

Spring を使用したことがある Java 開発者にとっては、Spring は本当に優れていると間違いなく言うでしょう。結局のところ、それはまだ馴染みのある味です。しかし、同様のニーズに遭遇したことのない Gopher にとっては、それは緊急のニーズではないようです。

市場にはさまざまな Go 依存性注入ライブラリが登場しており、その中には大手メーカーが制作したものも多く、依然として大きな市場があることがわかります。

多くの Gopher は、Java のいくつかの複雑な概念が Go に導入されることに非常に嫌悪感を抱いていると思いますが、依存性注入自体は言語によって制限されるものではなく、さまざまな言語にも独自の実装があると思います。 Java の Spring は単なる依存性注入フレームワークではなく、多くの開発者を困惑させる複雑な機能も多数備えています。

依存性注入だけであれば、実装は複雑ではなく、それほど複雑にはなりません。時間をかけてソースコードを読むと、概念を理解した上ですぐに習得できるようになります。

SDK 自体に戻ると、Go の SDK は現在 Java バージョンよりも機能が少ない (正確には、Java バージョンのみが最も多くの機能を備えています) ですが、コア機能はすべて備えており、日常的な使用には影響しません。