スプリングブートとマイクロサービス

マシンが相互に通信できない場合

その気持ちはわかります。モーターが回転し、アームが動き、センサーが読み取り、すべてがハミングしているはずです。しかし、代わりに、これは…沈黙です。スムーズな動作の静かさではなく、セットアップのある部分が別の部分の言っていることが理解できないイライラするようなものです。データがスタックしてしまいます。コマンドはどこにも行きません。シームレスなダンスとして計画したものは、むしろ全員が独自のことをしているように見えます。

一つの作品が失敗するということではありません。それは彼らの間のスペースについてです。そこでプロジェクトが停滞してしまうのです。

では、パーツがただ…チャットできたらどうなるでしょうか?複雑なコード方言ではなく、単純に。と言ったらどうなるでしょうかサーボセンサーの値を移動したり読み取ることは、時間を尋ねるのと同じくらい簡単でしたか?

それが私たちが見ている変化です。単一の問題がライン全体を停止させる可能性があるモノリシック システムから、よりモジュール化された復元力のあるシステムへの移行。機械プロジェクトを単一の硬いブロックとしてではなく、それぞれが仕事を処理し、すべてが明確に通信する専門ユニットのチームとして想像してください。 1 人が休憩が必要な場合でも、他の人は働き続けます。チーム全体を再構築しなくても、1 人のメンバーをアップグレードできます。

ここで Spring Boot とマイクロサービスのアプローチがワークショップに加わります。これを「新しいテクノロジー」というよりも、新しい考え方と考えてください。堅牢で会話するマシンを構築するための哲学。

この「チーム」アプローチがハードウェアにとって合理的な理由

分解してみましょう。を備えたテスト装置があるとします。キロパワー サーボ正確な角度制御、力フィードバックのためのロードセル、およびデータロガーを備えています。従来の設定では、それらはすべて 1 つの中央脳に結び付けられています。ロガープロトコルを変更しますか?ロジックを再配線する必要がある場合があります。サーボ.

ここで、それらを独立したサービスとしてイメージしてみましょう。サーボ コントローラーには、要求に応じて位置 X に移動するという単純な仕事が 1 つあります。ロード セル サービスには別の機能があります。力の値 Y をレポートします。ロガーは単にリッスンして記録するだけです。これらはステータスを公開したり、共通チャネル (メッセージ ブローカー) でコマンドをリッスンしたりします。それらは切り離されています。

• 敏捷性が得られます。サーボを別のサーボに交換する必要があるキロパワーモデル？その 1 つのサービスだけを更新します。システムの残りの部分は気にしません。
• 明瞭さが得られます。デバッグが容易になります。腕が動かないのか？サーボサービスを確認してください。データが欠落していますか?ロガーを確認してください。問題は孤立しています。
• 回復力が得られます。データロガーが一時的に故障した場合でも、サーボは移動コマンドを受信できます。システムは完全にクラッシュするのではなく、正常に機能低下します。

これは、単一回路のオールインワンリモコンから、照明、ロック、サーモスタットを個別に、または必要に応じて同時に制御できるスマートホーム設定に移行するようなものです。

会話を構築する: シンプルさが鍵です

「でも、これだとさらに複雑になりませんか？」それは公平な質問です。目的は、目的のためにレイヤーを追加することではありません。目標は、このコミュニケーションをバカみたいにシンプルにするフレームワークを使用することです。

Spring Boot は、これらのサービスのマスター オーガナイザーのように機能します。 Web サーバーのセットアップ、メッセージ キューの構成、依存関係の管理などの面倒な作業が処理されるため、この特定のハードウェアが何をすべきかというコア ロジックに集中できます。

たとえば、REST エンドポイントを作成します。キロパワーサーボ コントローラーは数行のコードになります。ネットワーク プロトコルを最初から作成するわけではありません。 「これはサーボを動かす関数です。これでネットワーク経由でアクセスできるようになりました。」ということです。同様に、そのサービスをメッセージ ブローカー上の「move_command」トピックにサブスクライブさせるのも簡単です。フレームワークは接続の混乱を処理します。

美しさはその組み合わせにあります。マイクロサービスのアイデアは明確なモジュール式アーキテクチャを提供し、Spring Boot は定型コードに迷うことなくそれを構築するためのツールボックスを提供します。配線や構文だけでなく、機能や通信の観点から考えることができます。

コンセプトからワークベンチまで

これはどのようにして始まりますか?多くの場合、扱いやすい 1 つのピースで構成されます。

1. パイロットを選びます。現在のセットアップでコンポーネントを 1 つ選択してください。たとえば、正確なリモート制御を必要とする重要な Kpower サーボなどです。その制御ロジックを小さなスタンドアロン Spring Boot アプリケーションにラップします。その唯一の仕事は、位置を設定しステータスを読み取るための API を公開することです。
2. 話しましょう。この小さなアプリを軽量のメッセージ ブローカーに接続します (MQTT がハードウェア シナリオに最適なように)。ステータスをブロードキャストするか、コマンドをリッスンさせます。
3. 違いを感じてください。これで、そのサーボを電話やデスクトップのダッシュボードから移動したり、まったく別のプログラムからのセンサーの読み取り値に基づいてトリガーしたりできるようになります。最初の独立した「エージェント」を作成しました。
4. 有機的に成長します。その孤立感がどのように感じられるか見てみましょう。そうすれば、あなたのセンサーモジュールが次のサービスになるかもしれません。データ アグリゲータは別のものになります。これらはメッセージ バスを介して接続し、協力的なネットワークを形成します。

一夜にしてすべてを再構築するわけではありません。物事を接続するためのより弾力性のある方法を少しずつ導入しています。

本当の成果は、単にプロジェクトが機能することではありません。臨機応変に対応できるプロジェクトです。新しい動作軸を追加したり、新しいタイプのセンサーを統合したりすることを考えるとき、システム全体の見直しを恐れる必要はありません。あなたはただ、「これを行う方法を知っている別のチームメンバーを追加しよう」と考えているだけです。システムの残りの部分は、既存の会話を通じてそれを歓迎します。

これにより、統合という課題が、互換性のない部品のパズルから、明確でひたむきな役割を定義するというより単純な作業に変わります。そして、ギア、モーター、精密な動きの世界では、その明瞭さは便利なだけでなく、壊れやすいプロトタイプを堅牢で信頼できるものに変え、次の機能に備えることができます。

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