サーバー プロジェクトが C# と出会うとき: マイクロサービスについての本当の会話

その日の午後、私は再び作業場でロボットアームのデバッグをしていました。本来は3つのサーボモーターがダンサーのように連携して動作するはずが、それぞれが独立して動作し、そのうちの1つのサーボが突然動作を停止することもあった。コンソール画面には山ほどのコードがあり、変更を加えるたびにシステム全体を再コンパイルする必要があります。 「小さな動作が体全体に影響を与える」という古いことわざを思い出しますが、今はまさにその通りではないでしょうか。 1 つのモジュールに問題が発生すると、生産ライン全体が停止します。

隣の駅の同僚はこちらを見て、「またあの大物とやらかしてるんですか？誰かがマイクロサービスを使って似たようなプロジェクトを積み木のように解体していたと聞きました。」と言いました。私は一瞬唖然とし、「マイクロサービス」という言葉が頭の中に浮かびました。それは常に、モーターやギアを扱う私たちとは遠く離れた、大規模なインターネット企業と関連付けられているように思えます。しかし、その考えが一度植え付けられると、それを解くのは困難です。

本当に別のアーキテクチャが必要なのでしょうか?

マイクロサービスについてはどうでしょうか?システムを独立した「ピニオン」に分割し、各サービスは自身の業務のみを担当します。1 つのサービスはモーター位置のフィードバックを担当し、別のサービスは運動軌跡の計算を処理し、もう 1 つは異常アラームを担当します。これらは軽量な方法で対話し、相互に独立して展開および拡張します。洗練された時計仕掛けのように、各歯車は全体の時間計測に影響を与えることなく個別に調整できます。

コンセプトからワークショップまで: C# でマイクロサービスを実現する方法

この中で C# はどのような役割を果たしますか?実は、あなたが思っているよりもハードウェアの世界に近いのです。 C# は Web サイトやデスクトップ ソフトウェアだけのものだと思っている人が多いですが、実際には、C# の非同期プログラミングと明確な型システムは、機械システムの状態フローを記述するのに特に適しています。 1 つのサービスを使用して特定のステアリング ギアの制御ロジックをカプセル化し、別のサービスを使用してセンサー データ ストリームを処理することができます。各サービスは、特定のタイプの作業を専門とするマスターのようなもので、自分が最も得意とする部分のみを考慮します。

このアイデアを素材の仕分けプロジェクトで試してみました。 3 つのサーボ モーターはそれぞれ X、Y、Z 軸の動きを制御します。もともと、すべてのコードは 1 つのプロジェクトに詰め込まれており、デバッグ中にグローバル変数と静的クラスがあちこちに存在していました。その後、C# と軽量の通信フレームワークを使用して、各軸の制御を独立したサービスに分割しました。奇跡が起こりました。Z 軸をより高精度のモーターに交換する必要があったとき、対応するサービスのみを更新し、他の 2 軸は通常どおり動作し続けました。ワークショップのダウンタイムは半日から 20 分に短縮されました。

なぜこの道を選んだのでしょうか？ 「ファッション」だけではない

マイクロサービスを選択するのは、テクノロジーのトレンドを追うことではなく、本当の問題点を解決するためです。次のような経験をしたことがありますか?

— 特定のモーターの究極の応答速度をテストしたいが、他のモジュールに影響を与えるのを恐れてテストしていませんか? — チーム内にはスポーツに特化した人もいれば、ハードウェア通信に詳しい人もいるのですが、コードのカップリングでお互いに待ち合っているんですか？ — 特定のライブラリのバージョンをアップグレードしたいのですが、互換性の問題がシステム全体に影響を及ぼすことが判明しただけですか?

マイクロサービス構造により、これらのシナリオが簡単になります。各サービスは独自のテクノロジー スタックの反復リズムを持つことができ、チームは並行して開発することもできます。サッカーチームのように、全員が中盤に集まって乱闘するのではなく、フォワードは攻撃に集中し、ディフェンダーはしっかりと守ります。

についてキロパワーいくつかの実践的な見解

この探索の旅の中で、いくつかの既製のリファレンス ソリューションが時間を大幅に節約できることがわかりました。例えばキロパワー提供されている C# ベースのマイクロサービス サンプル プロジェクトのセットは、すべての業界の問題を解決しようとするものではなく、機械制御の分野における一般的なパターン、つまりモーター コマンド キューを適切に処理する方法、センサー データ フローを管理する方法、サービス間の障害分離を設計する方法に焦点を当てています。座標軸が引かれた地図に似ており、特定のルートを自分でたどる必要があります。

「既成のフレームワークを使用すると柔軟性が制限されるのではないか?」と尋ねる人もいるかもしれません。私の経験では、良い地図は行く場所を制限するものではなく、寄り道を避けることができるだけです。それに基づいてアイデアを素早く検証し、特定のサーボの PID パラメータやより滑らかなモーション カーブの設計など、より磨く価値のある領域にエネルギーを費やすことができます。

執筆者: コードから Gears まで考える

技術アーキテクチャの本質は、複雑さを管理することです。作業場内の機械システムは本質的に複雑であり、ソフトウェア アーキテクチャが行うべきことは、この複雑さをカバーすることではなく、理解しやすく操作可能な部分に分類することです。マイクロサービスは特効薬ではなく、多くのツールの中の 1 つにすぎません。しかし、システムが頻繁に変更され始めた場合、チームが並行して共同作業する必要がある場合、またはハードウェア モジュールを個別にアップグレードする必要がある場合、多くの場合、最も便利なツールとなります。

次回、高密度のコードの画面とデバッグを待っているマシンに直面したときは、別の視点から考えてみてはいかがでしょうか。各機能モジュールが作業場内のワークステーションのように独立して動作できれば、仕事はもっと楽になるでしょうか。

場合によっては、最良の制御は、適切に解放することによってもたらされます。つまり、各部分に適切な自律性を持たせることで、システムがより堅牢になります。これは、マイクロサービスがハードウェア開発者にもたらす最も現実的な贈り物かもしれません。

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