Banyak Program Kecil Terhubung melalui Soket vs Satu Program Besar

Saya berada di awal proyek yang melibatkan pembacaan dari beberapa sensor dan menggabungkan data dari sensor tersebut bersama-sama. Secara keseluruhan akan ada 4 sensor yang terhubung melalui USB dan webcam, juga terhubung melalui USB.

Salah satu kolega saya sangat vokal tentang betapa menyenangkannya membagi program menjadi bagian-bagian yang lebih kecil dan membuat mereka berkomunikasi melalui jaringan. Dia menyarankan bahwa kita harus memiliki executable untuk setiap sensor (atau kamera) dan kemudian aplikasi pengendali pusat yang berkomunikasi dengan yang lain.

Secara intuitif saya tidak menyukai ide ini. Kolega yang bersangkutan bekerja pada proyek lain yang menggunakan pendekatan itu dan tidak memiliki masalah yang sulit dilacak dan debug.

Itu tidak tampak seperti desain yang sangat canggih dan menganggap saya agak tidak sopan. Saya ingin menulis perpustakaan untuk berurusan dengan masing-masing sensor dan mungkin menjalankannya di utas terpisah.

Juga harus ditunjukkan bahwa perhitungan yang perlu kita lakukan akan memberikan pembaruan ke sistem lain di hampir 1000Hz. Menambahkan lapisan komunikasi jaringan sepertinya menambah hambatan potensial.

Saya tertarik mendengar pendapat orang lain tentang hal ini dan mungkin beberapa referensi mengenai jenis praktik ini.

Secara intuitif saya tidak menyukai ide ini.

Yah, secara intuitif, saya suka gagasan membagi program menjadi bagian-bagian yang lebih kecil. Tetapi jika proses yang berbeda berjalan selalu semua pada mesin yang sama, komunikasi jaringan mungkin bukan bentuk optimal dari IPC. Untuk komunikasi kecepatan tinggi antar proses, memori bersama mungkin merupakan opsi yang lebih baik. Tetapi pendekatan apa pun yang Anda pilih, Anda harus mengukur atau setidaknya memperkirakan kinerja sebelum membuat penilaian apa pun.

Kolega yang bersangkutan bekerja pada proyek lain yang menggunakan pendekatan itu dan tidak memiliki masalah yang sulit dilacak dan debug.

Anda harus memeriksa masalah seperti apa, dan di mana akar masalahnya. Jika mereka memiliki masalah karena konkurensi, Anda akan menghadapi masalah yang sama (jika tidak lebih) ketika Anda mencoba solusi multi-threaded.

memberikan pembaruan ke sistem lain di hampir 1000Hz

Jika itu "kecepatan tinggi", tergantung pada kecepatan mesin produksi, dan ukuran operasi yang terlibat dalam setiap pembaruan. Ketika datang ke kinerja, firasat sangat tidak dapat diandalkan, Anda perlu mengukur hal-hal . Jika kolega Anda yakin pendekatannya akan cukup cepat, dan Anda yakin itu tidak akan terjadi, setidaknya salah satu dari Anda harus membuktikan atau memalsukan keyakinannya. Sebagai contoh, salah satu dari Anda dapat mengimplementasikan prototipe kecil untuk mensimulasikan komunikasi antarproses, dan mengukur kecepatan. Yang lainnya melihat ke dalam mangkuk kaca.

Mereka mungkin atau mungkin tidak relevan dengan aplikasi Anda, tetapi beberapa manfaat untuk solusi multi-proses yang tampaknya belum Anda pertimbangkan adalah:

• Kontrol izin yang lebih halus. Anda dapat memiliki izin terpisah untuk webcam dan sensor lainnya.
• Lebih mudah untuk menguji sensor secara terpisah.
• Lebih mudah untuk mengejek sensor saat runtime.
• Lebih mudah untuk membuat pihak ketiga menulis kode untuk sensor mereka tanpa harus membuka kode Anda.
• Gunakan alat seperti wireshark untuk pemecahan masalah, baik selama pengembangan dan di lapangan.
• Satu-satunya konteks yang saya tahu di mana "stateful" dilihat sebagai atribut positif adalah ketika bagian stateful dari sistem dibatasi untuk lingkup kecil seperti aktor , yang tampaknya mendukung desain kolega Anda lebih dari Anda.
• Lebih mudah melepaskan kunci dan memulai kembali hanya satu proses sensor tanpa harus memulai ulang seluruh sistem.
• Dapat mengukur hanya dengan menambahkan perangkat keras.
• Komunikasi soket dengan sumber dan dest pada mesin yang sama relatif efisien.

Kelemahan tambahan untuk solusi multi-proses:

• Berurusan dengan tekanan balik lebih kompleks.
• Jika pada dasarnya Anda hanya meneruskan data mentah dari masing-masing sensor tanpa pemfilteran atau pemrosesan, Anda baru saja mengubah aplikasi pengontrol Anda dari membaca dari driver usb ke membaca dari driver jaringan, tanpa keuntungan nyata dalam abstraksi.

Pendekatan yang dianjurkan oleh rekan kerja Anda sering disebut sebagai arsitektur layanan mikro dan cukup populer saat ini. Ini memiliki sejumlah keunggulan potensial :

• Skalabilitas: itu dapat membuatnya relatif mudah untuk skala hanya dengan menambahkan mesin tambahan / instance VM.
• Robustness: dengan desain yang tepat dapat dibuat toleran terhadap proses-proses layanan mikro individual yang macet, kehilangan konektivitas atau jika tidak tersedia.
• Extensibility: menggunakan teknologi Web standar untuk antarmuka antara layanan microser (biasanya permintaan http REST dengan respons Json atau XML) dapat memudahkan pihak ketiga atau pelanggan untuk berinteraksi dengan sistem Anda dan memperluasnya untuk kebutuhan mereka sendiri.

Ini juga memiliki sejumlah kelemahan:

• Kinerja: umumnya Anda akan membayar biaya kinerja untuk komunikasi antar-proses. Ini mungkin sangat signifikan jika Anda membangun API gaya http REST.
• Kompleksitas: biasanya Anda akan memerlukan kode tambahan yang cukup banyak untuk menyusun data antar proses vs hanya meneruskan data di antara utas dalam satu proses tunggal. Anda juga akan memperkenalkan dependensi pada perpustakaan untuk komunikasi jaringan, dukungan http, dll.
• Debuggability: biasanya lebih kompleks untuk men-debug aplikasi yang terdiri dari beberapa proses komunikasi independen vs menggunakan debugger terintegrasi IDE pada satu proses.

Saya tidak yakin apa yang Anda maksud ketika Anda mengatakan desain "sepertinya bukan desain yang sangat canggih". Secara umum "state-ful" dianggap sebagai karakteristik yang buruk dari suatu desain dan layanan mikro "stateless" dianggap sebagai desain yang baik.

Namun, mengingat informasi tentang persyaratan yang Anda berikan di pos Anda, saya pikir desain berbasis microservices akan berlebihan untuk kasus penggunaan Anda dan manfaatnya tidak akan membenarkan kompleksitas tambahan. Manfaat arsitektur layanan microsoft cenderung hanya benar-benar ikut berperan ketika membangun layanan web skala besar yang mengutamakan skalabilitas, kekokohan, dan ekstensibilitas.

Manfaat potensial dari arsitektur layanan microsoft hanya diwujudkan dengan desain yang dipikirkan dengan baik juga. Menurut pendapat saya, arsitektur seperti itu membutuhkan desain yang lebih maju (terutama ketika menyangkut protokol untuk berkomunikasi antara layanan microser) daripada desain proses tunggal jika ingin berhasil memecahkan masalah yang dihadapi.