マイクロサービス間の通信方法

機械デバイスが「話し始め」るとき: マイクロサービス間の通信技術

これを想像してください: あなたは洗練されたロボット アームを設計します。各関節のサーボモーターは完璧に反応し、ステアリングギアの角度制御はミリ単位で正確に行われます。しかし、システム全体を調整しようとすると、腕の動きが動かなくなったり、同期が取れなかったり、場合によっては「喧嘩」したりすることがあります。何が問題ですか?多くの場合、単一のモーターに問題があるのではなく、モーター間の「対話」が混乱していることが原因です。機械部品が連携して動作する必要があるのと同様に、最新のソフトウェア アーキテクチャのマイクロサービスにも、明確で信頼性の高い通信方法が必要です。

これは単なるコードの問題ではなく、システムがどのように「存続」し、連携して動作するかという問題です。

マイクロサービス間の通信はなぜ「チェーンのドロップ」が簡単なのでしょうか?

以前は、多くのシステムは、すべてのロジックがバンドルされた、統合された機械アセンブリのようなものでした。小さなギアを変更する場合、調整のために機械全体を停止する必要がある場合があります。マイクロサービス アーキテクチャは、複雑なマシンを標準的なモーター、センサー、コントローラーにモジュール化するのと同じように、システムを機能に特化した独立した小さなユニットに分割します。これにより、柔軟性と保守性がもたらされますが、新たな課題も生じます。これらの分散した「小さなモジュール」は、どのようにして効率的、正確、安定して情報を交換できるのでしょうか?

一般的な状況は次のとおりです。

• 情報が遅れたり失われたりする：一方のサービスが指示を送信しましたが、もう一方のサービスがそれを受信しなかったか、応答に時間がかかり、プロセスが中断されました。
• データに一貫性がありません: サービス A はステータスを更新しますが、サービス B は古いデータで動作しており、結果が矛盾しています。
• カップリングがきつすぎる：サービス間の依存関係が深すぎます。どれか一つでも問題があれば、連鎖的にシステム全体がダウンしてしまい、マイクロサービスの「独立性」の意味が失われてしまいます。
• 追跡が難しい: 問題が発生しましたが、どの「会話」でエラーが発生したのかわかりません。トラブルシューティングは迷路をぐるぐる回っているようなものです。

これは、統一通信プロトコルを使用せずに、分散した機械ユニットのグループに指示を与えるようなものです。歯車伝送信号に依存するもの、空気圧伝送を使用するもの、さらにはフラッシュ ライトに依存するものもあります。カオスじゃないとおかしいですね。

会話をスムーズに進める: いくつかのコアコミュニケーション「言語」

これらのマイクロサービスを、よく訓練された機械チームのようにスムーズに連携させるにはどうすればよいでしょうか?重要なのは、適切な通信モデルを選択することです。これらは、信号を送信するさまざまなコネクタまたは方法のようなものです。

1. 同期通話: 直接質問し、回答を待ちます。最も一般的なのは、HTTP API に似たリクエスト/レスポンス モードです。サービス A はサービス B にリクエストを直接送信し、明確な応答を待ってから作業を続行します。これは、コントロール パネルのボタンを押して、ライトが点灯するかモーターが回転してフィードバックが得られるまで待ってから、次のステップに進むようなものです。

• 利点: シンプルかつ直感的で、明確なロジックを備えています。
• 注意が必要です: 相手のサービスが遅かったり、電話を切ったりすると、発信者も「スタック」し、チェーン全体が待たされやすくなります。高いリアルタイム要件と安定したダウンストリーム サービスを必要とするシナリオに適しています。

2. 非同期メッセージ: メモを残し、メッセージ キュー (RabbitMQ、Kafka コンセプトなど) またはイベント バスを通じて個別に処理します。サービス A が何かを完了すると、イベントまたはメッセージを「メッセージ リレー」に発行するだけで、それは忘れられます。イベントを扱うサービス B および C は、イベントを自身で取得して処理します。これは、機械ユニットがアクションを完了した後、共有掲示板に完了メモを投稿するようなものです。他の関連ユニットはそれを自分で調べて、何をすべきかを決定できます。

• 利点: 完全な分離。送信側は受信側のリアルタイム ステータスに依存しません。圧力を緩衝し、突然のリクエストによってシステムが圧倒されるのを防ぐことができます。
• 注意が必要です: アーキテクチャが複雑になり、メッセージの信頼性の高い配信を保証する必要があり、イベント処理の順序を考慮する必要があります。

3. パブリッシュ/サブスクライブ: ブロードキャスト通知により、誰もが必要なものを入手できます。これは、非同期メッセージの一般的なパターンです。サービスはパブリッシャーとして機能し、イベントをトピック チャネルにパブリッシュします。このトピックを購読するサービスはコピーを受け取ります。ワークショップの中央ブロードキャスト システムが「パート A が設置されています」と通知するのと同じように、この情報を必要とするすべてのワークステーションはその情報を同時に聞き、自律的に応答できます。

どの「言語」を選択するかについて、絶対的な答えはありません。それはシステムの「個性」によって異なります。つまり、ぴったりとした即時的なフィット感が必要ですか、それとも回復力とスループットを重視しますか?多くの場合、システム内に複数のモードが混在します。

キロパワー視点: 精密機械のようにコミュニケーションをデザインする

私たちの中でキロパワーさまざまなハードウェア統合とモーション制御を扱った経験から、ソフトウェア マイクロサービス間の通信は物理的な機械システムの調整と驚くほど類似していることがわかりました。信頼性、リアルタイム性、耐障害性 - これらの要件は共通です。

この問題を考察する場合、純粋にソフトウェア レベルから始めるだけではありません。たとえば、メッセージを電気信号と同じくらい安定して送信するにはどうすればよいでしょうか?一部のユニットに障害が発生した場合に、機械的な冗長設計のようにシステムを劣化レベルで動作させ続けるにはどうすればよいでしょうか?センサーを使用して各ドライブシャフトの速度とトルクを監視するなど、情報の流れを監視するにはどうすればよいですか?

いくつかの簡単な質問について考えると、自分の考えが明確になることがあります。

• サービス間で厳密な「アクションの確認」が必要ですか、それとも「トリガーして忘れる」ことができますか?
• 情報伝達の遅れはビジネスにどの程度の影響を与えるのでしょうか?
• サービスが一時的にダウンしている場合、メッセージはキューに入れられるべきですか、それとも当面は無視できますか?

マイクロサービスが適切に通信できるようにします。目標は、最もファッショナブルなテクノロジーを追求することではなく、システムの「生理学的構造」に最も適したニューラル ネットワークを見つけることです。これにより、データ フローが十分に油を塗られたベアリングのようにスムーズになり、サービスの独立性と協調性の両方が可能になり、最終的には物理的な機械の駆動やデジタル トランザクションの処理など、アプリケーション全体が柔軟、堅牢、効率的に実行できるようになります。

優れたアーキテクチャはそれ自体が洗練されたマシンのようなものであり、通信のあらゆる詳細は慎重に磨き上げる必要があります。サービス間の通信の問題を解決すると、複雑で信頼性の高いシステムの構築が突然より明確になり、より制御しやすくなることがわかります。

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