ドメイン駆動設計とマイクロサービス

サーバー システムが「怒り」始めたら: ドメイン ドライバーとマイクロサービスについて話しましょう

これを想像してください。生産ラインがフルスピードで稼働していると、突然サーボが振動し始め、その後、酔ったかのようにロボット アーム全体が揺れ始めます。長い間チェックした結果、ある制御モジュールのコードが「競合」していることがわかりました。温度監視ロジックと動作軌跡が互いに矛盾しており、誰もそれらの方が重要だと感じていませんでした。この光景は見覚えがありますか？

多くの場合、問題はハードウェアにあるわけではありません

多くの人の最初の反応は、「モーターが壊れている? 交換してください!」です。しかし、頻繁に分解すると、巻線に損傷がなく、エンコーダが正常であることがわかります。本当の核心は、複雑に絡み合ったソフトウェア ロジックにあります。従来のモノリシック アーキテクチャは、すべての工具を引き出しに詰め込んだようなものです。ドライバー、レンチ、テープがすべて混在しており、何かを見つけるたびにそれらを探さなければなりません。システムが複雑になればなるほど、この引き出しはさらに乱雑になり、ある日完全に動かなくなってしまいます。

ドメイン駆動設計: 各ツールに専用のツールボックスを提供します。

ドメイン駆動設計 (DDD) の中核となる概念は、実際には非常に現実的なものであり、専門的なことは知識のある人に任せましょう。たとえば、温度制御モジュールは放熱と過熱保護のみを考慮します。運動軌跡の詳細を知る必要はありません。位置校正モジュールは精度補償に重点を置いており、電圧変動を心配する必要はありません。これは、生産ラインに専用のツールボックスがあるようなものです。電気技師のボックス、機械工のボックス、プログラマーのボックスがカテゴリに分けられ、それぞれが独自の役割を果たします。

マイクロサービスについてはどうでしょうか?これは、各ツールボックスに独自の管理者がいると考えることができます。管理者は、標準化されたインターフェイスを通じて、「温度が臨界値に達しました。速度を下げてもらえますか?」などのメッセージを相互に受け渡します。 「受け取りました、加速カーブを調整しました。」長時間にわたる会議や複雑な承認プロセスはなく、効率的なポイントツーポイントのコラボレーションのみが行われます。

この組み合わせは実際にどのような違いをもたらすのでしょうか?

6 軸マニピュレータのセットの応答遅延は、当初は約 50ms でしたが、場合によっては 200ms に跳ね上がる場合がありました。変換後は各軸の制御が独立したマイクロサービスとなり、遅延も20ms以内で安定しました。さらに優れているのは、視覚認識モジュールをアップグレードする必要がある場合、交換する必要があるのは「ツールボックス」の 1 つだけで済み、互換性テストのためにライン全体を 3 日間停止する必要がないことです。

でもあまり細かく分けすぎると管理が難しくなりますか？誰かが尋ねた。

良い質問です！これには境界線を引く技術が関係します。 DDD は、工場内の作業場エリアを分割するのと同じように、「境界のあるコンテキスト」を通じてテリトリーを定義することを提唱しています。機械的な伝送制御は 1 つのコンテキストであり、信号処理は別のコンテキストであり、これらは明確なプロトコルを通じて相互作用します。キロパワー実践により、合理的な境界分割により、システムがレゴ ブロックのように独立し、再編成が容易になることがわかっています。

プランを選ぶときのいくつかのポイント

チーム構成を見てください。ハードウェア チームとソフトウェア チームが通常、通信にシャウトに依存している場合、マイクロサービスを通信プロセスと一致させる必要がある場合があります。チーム自体が緊密に連携していれば、進捗はよりスムーズになります。

変更の頻度を見てください。多くの場合調整が必要なパラメータ モジュール (さまざまな材料に適応するための圧力制御など) は、独立したサービスに適しています。一方、10 年間変化していない根本的な推進要因は、単一のエンティティに留まる方が経済的である可能性があります。

耐障害性の要件について考えてみましょう。かつて、ある顧客はこう言いました。「特定の機能がハングアップして生産ライン全体が停止するよりは、特定の機能が遅くなるほうがいいのです。」ここでは、マイクロサービスの分離がその価値を示しています。特定のサービスに問題がある場合、それは組み立てラインの特定のステーションを一時的に調整するようなものですが、他のステーションは通常どおり動作し続けます。

着陸時の進歩的な知恵

一夜にして車輪を再発明する必要はありません。毎週デバッグする必要があるサーボ モーターの校正プログラムなど、最も問題を引き起こすモジュールから始めることができます。それを独立したサービスに抽出し、明確なインターフェイスを使用してメイン システムと通信します。 3 か月後、デバッグ時間が半日から 1 時間に短縮されたことに気づくかもしれません。

次に、複数のセンサーが関与する同期や調整ロジックなど、全身に影響を与える機能に対処します。独立した後は、他のモジュールへの影響を心配することなく、より適切な言語 (高いリアルタイム要件には C++、複雑なビジネス ロジックには Go など) で書き直すことができます。

避けられない課題とその対応

分散システムでは、ネットワーク遅延などの新たな問題が発生します。しかし、産業環境では、ローカライズされた展開と専用ネットワークによってこれを軽減できます。もう 1 つの課題はデータの一貫性です。複数のサービスが状態を共有する必要がある場合、キロパワーイベント追跡モデルがよく使用されます。つまり、各ステータスの変化はイベントとして記録され、サービスは、生産ラインの作業指示フロー記録と同様に、オンデマンドでサブスクライブされ、いつでも追跡できます。

結局のところ、テクノロジー アーキテクチャの本質は複雑さを管理することです。ドメイン駆動設計は論理境界を明確にするのに役立ち、マイクロサービスは物理的な分離手段を提供します。これらの組み合わせは特効薬ではありませんが、精密機械にモジュール式のメンテナンス ソリューションを装備するようなもので、毎回戦争をすることなく、どこにいてもアップグレードや交換が可能です。

次回、機器の異常を見つけたら、「ハードウェアが疲れているのか、それともソフトウェアが『戦っている』のか？」と尋ねてみるとよいでしょう。おそらく考え方を変えてコード構造を整理すれば、マシンは再びスムーズに踊れるようになるかもしれません。結局のところ、複雑なシステムを確実に動作させ続けることは、常にアートとテクノロジーの間でのダンスでした。

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