マイクロサービスでの Kafka の用途は何ですか

サーバー システムがマイクロサービスと出会うとき: データをフローさせましょう

次のシナリオを想像してください。ロボット アームの生産ラインをデバッグしているとします。 6 つのサーボ モーターが連携して動作する必要があり、各サーボ モーターはリアルタイムで位置指示を受信し、温度と速度のデータをコントロール センターに送信します。突然、1 つのモーターのフィードバック データが遅れ、アクション シーケンス全体に遅れが生じ始めました。まるでスムーズだったはずのダンスが、誰かがビートを遅くしたように、チームは混乱に陥りました。

機械とオートメーションの世界では、リアルタイムで信頼性の高いデータ フローが生命線であることを私たちは知っています。信号の遅延により、アセンブリの位置がずれる可能性があります。指示を紛失すると、機器の衝突が発生する可能性もあります。データの即時性と順序に対するこの厳しい要件は、実際には、現代のソフトウェア アーキテクチャの「マイクロサービス」が直面する課題と驚くほど似ています。

マイクロサービスの「データダンス」はどこで行き詰まっているのでしょうか?

当初は 1 つのソフトウェア アプリケーションとして統合されていましたが、ユーザー管理、注文処理、在庫照会など、複数の独立した小さなサービスに分割されました。彼らはそれぞれの職務を遂行し、柔軟に対応します。しかし、問題が発生します。サービス A は新しい注文を生成し、サービス B は在庫を更新する必要があり、サービス C は物流に通知する必要があります。彼らはどのようにして「出来事」が起こったことを知るのでしょうか？従来のアプローチは、すべてのモーターを配線接続するのと同じように、相互に直接呼び出しを行うことです。特定のサービスがビジーになるか障害が発生すると、チェーン全体が待機したり、ブロックされたり、さらには崩壊したりします。

これにより、話さなければならないことの核心、つまりイベント駆動型アーキテクチャとその主要なプレーヤーの 1 つが見えてきます。それは高度に知的な、終わりのない神経中枢のように機能します。

これは単純なメッセージ キューではなく、イベント ログのバックボーンです。

継続的に記録される「グローバル イベント ログ ブック」と考えるとより直感的かもしれません。任意のマイクロサービス (「注文が正常に作成されました」など) は、「イベント ID: 107、タイプ: 新しい注文、内容: 注文番号 XXX、時刻: 14:00」などのイベント レコードをこのログ ブックに簡単に発行できます。理由は問いません。ただ、すべてを順番に、そして永続的に記録する責任があります。

これに関係する他のすべてのサービス (インベントリ サービス、ロギング サービス、分析サービスなど) はいつでもこのログ ブックを購読できます。最初から読むことも、中断したところから続けることもでき、イベントを生成した「オーダー サービス」を妨げることなく、これらのイベントを自分のペースで独立して消化することができます。在庫サービスは新しい注文イベントを読み取ると、在庫を差し引きます。分析サービスがそれを読み取ると、販売統計が更新されます。

これは、特に私たちのエンジニアリングの考え方に沿って、いくつかの安心できる利点をもたらします。

1. デカップリングと復元力:発行者と購読者はお互いを知りません。在庫サービスが一時的にアップグレードおよび保守された場合でも、注文イベントは引き続きログに着実に記録されます。インベントリ サービスが復帰すると、データを失うことなくバックログを冷静に処理できます。このシステムは緩衝バネのようなもので、壊れやすいものではありません。
2. 順序とトレーサビリティ:各イベントには厳密な順序があります。これは、「支払い-発送」などの厳密な因果関係を持つビジネス プロセスを扱う場合に非常に重要です。イベントの完全なコンテキストを明確に追跡できるため、デバッグと監査が容易になります。
3. リアルタイムと非同期:データはほぼリアルタイムで流れますが、処理は非同期です。サービスは応答を待つ必要がなく、次のリクエストの処理を続行できるため、当然のことながらスループットが大幅に向上します。

そのような「神経中枢」を選択するとき、私たちは何を気にするのでしょうか？

精密機械のサーボシステムを選ぶ場合と同様に、応答周波数、制御精度、動作の安定性を重視します。ソフトウェアの世界でも、次のような同様の考慮事項があります。

• 高スループットと低遅延:ミリ秒の配信速度を維持しながら、大量のイベントの急流を処理できるでしょうか?
• 耐久性と信頼性:データは安全に保存されており、サーバーが再起動されても失われることはありませんか?
• 水平方向のスケーラビリティ:ビジネスが成長した場合、システム全体を置き換えるのではなく、マシンを追加するだけでスムーズに容量を拡張できますか?

存在するキロパワー私たちが参加した多くの統合プロジェクトでは、このイベント駆動型の考え方をシステム設計に導入することは、ディスクリート サーボ ユニットに正確な同期バスを導入することに似ていることがわかりました。これにより、データ フローが整理され、堅牢になり、管理しやすくなります。マイクロサービスは密結合ではなくなりましたが、イベントを通じてスムーズに連携します。システム全体の保守性や拡張性が質的に向上しました。

単純な考え

多数の独立したサービスで構成される複雑なシステムを計画している場合は、次のように自問したほうがよいでしょう。サービスが常に相互に「呼び出し」を行って相互に要求し、回線が話し中または無応答になることがよくありますか。それとも、全員が共通の「掲示板」に情報を公開したり入手したりすることに慣れていて、それぞれがのんびりと仕事をしているのでしょうか？

後者のモデルは、マイクロサービス アーキテクチャがその能力を真に発揮できるようにするための鍵の 1 つです。それは技術的な問題を解決するだけでなく、データコラボレーションの哲学も変えます。データが価値を持つこの時代において、情報フローを効率的かつエラーなく配信することは、機械ラインであれソフトウェア クラスターであれ、あらゆる複雑なシステムが成熟し信頼性を高めるための基礎となります。

2005年に設立され、キロパワーは、中国広東省東莞に本社を置く、コンパクトモーションユニットの専門メーカーです。モジュラードライブテクノロジーのイノベーションを活用し、キロパワー高性能モーター、高精度減速機、マルチプロトコル制御システムを統合し、効率的でカスタマイズされたスマート ドライブ システム ソリューションを提供します。 Kpower は、スマート ホーム システム、自動エレクトロニクス、ロボティクス、精密農業、ドローン、産業オートメーションなどのさまざまな分野をカバーする製品で、世界中の 500 を超える企業クライアントにプロフェッショナルなドライブ システム ソリューションを提供してきました。