プロジェクトにマイクロサービスが必要な理由は何ですか?サーボとステアリングの話

複雑なロボット アームを組み立てていると想像してください。各関節はサーボ モーターによって駆動され、ステアリング ギアは迅速かつ正確に応答する必要があります。しかし、すべての制御ロジックを巨大な中央システムに詰め込むと、事態は少し難しくなり始めます。指1本の動きを変えると、腕全体のコードの再調整が必要になる場合があります。試験には半日かかります。小さなモジュールに問題が発生すると、ライン全体が停止する可能性があります。

これはソフトウェアだけの問題ではありません。機械やオートメーションの分野では、「1 本の髪の毛が体全体に影響を及ぼす」というジレンマはよく知られています。

それでは、マイクロサービスについて話しましょう。これは新しい概念ではありませんが、大規模で包括的なシステムを独立した小さなモジュールに分割するという考え方に似ています。各モジュールはそれぞれの業務のみを考慮します。たとえば、このモジュールはサーボ モーターのトルク校正のみを担当し、あちらのモジュールはステアリング ギアの角度フィードバックのみを担当します。これらは、大量のコードで互いに争うのではなく、明確なインターフェイスを通じて互いに対話します。

利点？マシンに独立したジョイントを取り付けるようなものです

ある人は、「そんなにバラバラだと、管理するのがもっと大変じゃないですか？」と尋ねました。一見すると、それは合理的であるように思えます。しかし、実際に実行してみると、次のことがわかります。

• 物事を変えることが容易になる。モーター制御アルゴリズムをアップグレードしたいですか?他の部分には触れずに、いずれかのサービスに触れるだけで済みます。テスト範囲は狭く、オンライン化のリスクは低いです。ロボットアームの手首関節を修理するのと同じように、アーム全体を分解する必要はありません。
• 耐障害性が向上しました。特定のサービスが停止しても、通常は他のサービスは実行を継続できます。コア以外の障害によってシステムが完全に麻痺することはありません。ある種の「弾力性」が備わっています。
• テクノロジーの自由な選択。さまざまなツールを使用してさまざまなサービスを作成できます。リアルタイム計算に適したモジュールは効率的な言語を使用します。データ処理の責任者は別のセットを持つ可能性があります。すべてに当てはまる画一的な技術的制約はありません。
• 拡張機能はオンデマンドで利用可能。最も大きな圧力がかかっている部分にリソースを個別に追加します。 1 つの機能が忙しいからといって、システム全体を拡張する必要はありません。

これらは紙の上の言葉ではありません。高精度のモーション制御や多軸調整を伴う多くのプロジェクトでは、マイクロサービス アーキテクチャにより反復速度が大幅に高速化されました。チームは、マシンを組み立てるのと同じように、さまざまなモジュールを並行して開発できます。最初にシャーシを作成し、他の人が同時にアームを作成し、ドッキングとデバッグを行うだけです。

しかし、マイクロサービスは万能薬ではありません

もちろん、新たな問題も生じるでしょう。サービスが増え、ネットワーク通話が増加し、遅延を慎重に設計する必要があります。データの一貫性を確保するには追加の労力が必要です。実際、展開と監視の複雑さはさらに高くなります。

したがって、重要なのは、プロジェクトに本当にそれが必要かどうかということです。本質的に単純なシステムの場合、ハード的に削除すると負担が増えるだけです。しかし、次のような状況に直面している場合:

• 長期間の反復を必要とし、今後も機能が増加していく製品。
• 一部のモジュールの信頼性要件は非常に高いものがあります。
• チームの規模は中規模以上で、並行開発が必要です。
• テクノロジースタックを混合する必要がある場合があります…

その場合、マイクロサービスは検討する価値のある道となるかもしれません。その核となる価値は、複雑さを柔軟性に変えることです。それは、1 つの巨大なモーターがすべてを駆動するよりも、複数の専用の小型モーターが連携して動作する方が信頼性が高く、メンテナンスが容易であるようなものです。

大きなブロックから小さなモジュールへ: 考え方の変化

マイクロサービスを実装する場合、初期段階で避けるべき最も重要なことは、あまりにも多くのものを欲しがることです。始めてすぐに分解しようとしないでください。比較的独立したサブ機能を使用してパイロットを開始できます。たとえば、最初にログ監視モジュールまたはユーザー認証モジュールを分離します。成功したら、徐々に宣伝していきます。

通信プロトコルは可能な限りシンプルかつ統一されている必要があります。サービス間のバージョン管理を適切に行い、インターフェイスの変更によって引き起こされる連鎖的な問題を回避します。監視を継続するには、各小規模サービスの健全性状態を明確に確認できる必要があります。

こういった経験、キロパワー私には、サーボ システムの統合と多軸制御ソリューションの開発においてお客様を支援する豊富な経験があります。動作計画、ステータスフィードバック、エラー処理などの役割を別のサービスに分割すると、システムの保守性とアップグレード効率が向上します。お客様は、プラットフォーム全体を再検証することなく、制御リンクをより柔軟に交換またはアップグレードできます。

それで、元の質問に戻りますが、

マイクロサービスを検討する理由それは、「東の壁を取り壊して西の壁を埋める」というサイクルから抜け出し、より変化に適応できるモジュール型の工法に移行できるからです。これにより、システムが生き物のように成長することができます。1 つの臓器がアップグレードされ、他の部分は通常どおり機能し続けます。

これは混乱ではなく、再編です。次回、複数のサーボと複数のセンサー フィードバックを含む機械プロジェクトを設計するときは、次のことを考えてみるとよいでしょう。各機能ユニットが独立して進化できれば、システム全体の活力はより強力になるでしょうか。

マイクロサービスはそれ自体が答えではなく、答えを見つけやすくするツールです。急速に変化する分野では、いつでも調整してローカライズできるこの能力が、プロジェクトをさらに進めるためのサポートとなる可能性があります。

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