ソケットを介して接続された複数の小さなプログラムと1つの大きなプログラム

私はいくつかのセンサーからの読み取りとそれらのセンサーからのデータの融合を含むプロジェクトの始まりです。全体として、USBを介して接続された4つのセンサーと、同じくUSBを介して接続されたWebカメラがあります。

私の同僚の1人は、プログラムを小さな部分に分割し、それらをネットワーク経由で通信させることがいかに素晴らしいかについて非常に声高に言っています。彼は、各センサー（またはカメラ）の実行可能ファイルを用意し、次に他のユーザーと通信する中央制御アプリケーションを用意する必要があることを示唆しています。

私は直感的にこの考えが好きではありません。問題の同僚は、そのアプローチを使用し、追跡およびデバッグが困難な問題の終わりのない別のプロジェクトに取り組みました。

それは非常にステートフルなデザインのようではなく、ややエレガントではないように思えます。各センサーを処理するためのライブラリを作成し、別のスレッドで実行したいと考えています。

また、実行する必要がある計算により、1000Hz近くで別のシステムの更新が提供されることも指摘しておく必要があります。ネットワーク通信の層を追加すると、潜在的なボトルネックが追加されるように見えます。

これに関する他の人々の意見、そしておそらくこの種の実践に関するいくつかの参考文献を聞きたいと思います。

私は直感的にこの考えが好きではありません。

まあ、直感的には、プログラムを小さな部分に分割するアイデアが好きです。しかし、異なるプロセスが常に同じマシン上で実行される場合、ネットワーク通信はおそらくIPCの最適な形式ではありません。プロセス間の高速通信では、共有メモリの方が適している場合があります。しかし、どのようなアプローチを選択する場合でも、判断を下す前に、パフォーマンスを測定するか、少なくとも推定する必要があります。

問題の同僚は、そのアプローチを使用し、追跡およびデバッグが困難な問題の終わりのない別のプロジェクトに取り組みました。

どのような問題があり、根本的な原因がどこにあるのかを確認する必要があります。同時実行性が原因で問題が発生した場合、マルチスレッドソリューションを試行すると、ほとんど同じ問題が発生します（それ以上ではない場合）。

1000Hz近くで別のシステムにアップデートを提供する

それが「高速」である場合、本番マシンの速度、および各更新に含まれる操作のサイズによって異なります。パフォーマンスに関しては、直感は非常に信頼性が低く、測定する必要があります。あなたの同僚が彼のアプローチが十分に速いと信じて、あなたがそれがそうではないと信じるなら、あなたの少なくとも一人は彼の信じていることを証明するか偽造する必要があります。たとえば、小さなプロトタイプを実装してプロセス間通信をシミュレートし、速度を測定することができます。それ以外はすべてガラスのボウルを調べています。

それらはアプリケーションに関連する場合と関連しない場合がありますが、マルチプロセスソリューションに考慮していないと思われるいくつかの利点があります。

• よりきめの細かい権限制御。Webカメラと他のセンサーに対して別々の権限を持つことができます。
• センサーを分離してテストするのが簡単になります。
• 実行時にセンサーをモックアウトするのが簡単になりました。
• コードを開かなくても、サードパーティにセンサーのコードを記述してもらうのが簡単になります。
• 開発中および現場でのトラブルシューティングのためのWiresharkなどのツールの使用。
• システムのステートフルな部分はのような小さな範囲に制限されているとき、私は肯定的属性として見られているところ、「ステートフル」を知ってる唯一のコンテキストがある俳優のあなた以上にあなたの同僚の設計をサポートするようです。
• システム全体を再起動することなく、ロックを解除して1つのセンサーのプロセスのみを再起動するのが簡単になります。
• ハードウェアを追加するだけで拡張できます。
• 同じマシン上のsourceとdestとのソケット通信は比較的効率的です。

マルチプロセスソリューションのその他の欠点：

• バックプレッシャーへの対応はより複雑です。
• 基本的に、フィルタリングや処理を行わずに各センサーからの生データを渡すだけの場合は、コントローラーアプリケーションを、USBドライバーからの読み取りから、ネットワークドライバーからの読み取りに変更しましたが、抽象化に実質的な利点はありません。

同僚が提唱しているアプローチは、マイクロサービスアーキテクチャと呼ばれることが多く、最近非常に流行しています。いくつかの潜在的な利点があります。

• スケーラビリティ：マシンやVMインスタンスを追加するだけで、比較的簡単にスケーリングできます。
• 堅牢性：適切な設計により、個々のマイクロサービスプロセスがクラッシュしたり、接続が失われたり、その他の方法で利用できなくなったりする場合に対応できます。
• 拡張性：標準のWebテクノロジーを使用してマイクロサービス間のインターフェース（通常、JSONまたはXML応答を伴うhttp REST要求）を使用すると、サードパーティまたは顧客がシステムとのインターフェースを容易にし、独自のニーズに合わせてシステムを拡張できます。

また、いくつかの欠点もあります。

• パフォーマンス：通常、プロセス間通信のパフォーマンスコストを支払います。これは、HTTP RESTスタイルのAPIを構築する場合に非常に重要です。
• 複雑さ：通常、プロセス間でデータをマーシャリングする場合と、単一のプロセス内のスレッド間でデータを渡すだけの場合は、かなり多くの追加コードが必要になります。また、ネットワーク通信、httpサポートなどのライブラリへの依存関係も紹介します。
• デバッグ可能性：単一のプロセスでIDEの統合デバッガーを使用する場合と比較して、複数の独立した通信プロセスで構成されるアプリケーションをデバッグすることは、通常、より複雑です。

デザインが「非常にステートフルなデザインのように見えない」と言ったとき、あなたが何を意味しているのかよくわかりません。一般に、「ステートフル」は設計の悪い特性と見なされ、「ステートレス」マイクロサービスは優れた設計と見なされます。

ただし、投稿で提供する要件に関する情報を考えると、マイクロサービスベースの設計はユースケースにとってはやり過ぎであり、利点は追加の複雑さを正当化しないと思います。マイクロサービスアーキテクチャの利点は、スケーラビリティ、堅牢性、および拡張性を重視する大規模なWebサービスを構築するときにのみ実際に利用される傾向があります。

マイクロサービスアーキテクチャの潜在的な利点は、十分に考慮された設計によっても実現されます。私の意見では、このようなアーキテクチャは、問題の解決に成功するためには、単一のプロセス設計よりも（特にマイクロサービス間の通信プロトコルに関して）事前設計が必要です。