Nhiều chương trình nhỏ được kết nối qua ổ cắm và một chương trình lớn

Tôi đang bắt đầu một dự án bao gồm đọc từ một số cảm biến và kết hợp dữ liệu từ các cảm biến đó lại với nhau. Tổng cộng sẽ có 4 cảm biến được kết nối qua USB và webcam, cũng được kết nối qua USB.

Một trong những đồng nghiệp của tôi rất hay nói về việc chia các chương trình thành các phần nhỏ hơn và để chúng giao tiếp qua mạng tốt như thế nào. Ông đề nghị rằng chúng ta nên có một thiết bị thực thi cho từng cảm biến (hoặc máy ảnh) và sau đó là một ứng dụng điều khiển trung tâm giao tiếp với các cảm biến khác.

Tôi trực giác không thích ý tưởng này. Đồng nghiệp trong câu hỏi đã làm việc cho một dự án khác sử dụng phương pháp đó và không có vấn đề gì khó theo dõi và gỡ lỗi.

Nó dường như không phải là một thiết kế rất nhà nước và gây ấn tượng mạnh với tôi. Tôi muốn viết một thư viện để xử lý từng cảm biến và có thể chạy chúng trong các luồng riêng biệt.

Cũng cần chỉ ra rằng các tính toán chúng ta cần thực hiện sẽ cung cấp các cập nhật cho một hệ thống khác ở gần 1000Hz. Thêm vào một lớp truyền thông mạng có vẻ như thêm một nút cổ chai tiềm năng.

Tôi rất muốn nghe ý kiến ​​của những người khác về điều này và có lẽ một số tài liệu tham khảo về loại thực hành này.

Tôi trực giác không thích ý tưởng này.

Chà, theo trực giác, tôi thích ý tưởng chia nhỏ các chương trình thành các phần nhỏ hơn. Nhưng nếu các quy trình khác nhau luôn chạy tất cả trên cùng một máy, giao tiếp mạng có thể không phải là hình thức tối ưu của IPC. Đối với giao tiếp tốc độ cao giữa các quy trình, bộ nhớ dùng chung có thể là lựa chọn tốt hơn. Nhưng bất cứ cách tiếp cận nào bạn chọn, bạn phải đo lường hoặc ít nhất là ước tính hiệu suất trước khi thực hiện bất kỳ cuộc gọi phán xét nào.

Đồng nghiệp trong câu hỏi đã làm việc cho một dự án khác sử dụng phương pháp đó và không có vấn đề gì khó theo dõi và gỡ lỗi.

Bạn phải kiểm tra loại vấn đề và nguyên nhân gốc rễ. Nếu họ gặp vấn đề vì đồng thời, bạn sẽ gặp khá nhiều vấn đề tương tự (nếu không phải là nhiều hơn) khi bạn thử một giải pháp đa luồng.

cung cấp cập nhật cho hệ thống khác ở gần 1000Hz

Nếu đó là "tốc độ cao", tùy thuộc vào tốc độ của các máy sản xuất và quy mô hoạt động liên quan đến mỗi bản cập nhật. Khi nói đến hiệu suất, cảm xúc ruột thịt là vô cùng không đáng tin cậy, bạn cần phải đo lường mọi thứ . Nếu đồng nghiệp của bạn tin rằng cách tiếp cận của anh ta sẽ đủ nhanh, và bạn tin là không, ít nhất một trong hai bạn sẽ phải chứng minh hoặc làm sai lệch niềm tin của anh ta. Ví dụ, một trong số bạn có thể thực hiện một nguyên mẫu nhỏ để mô phỏng giao tiếp giữa các quá trình và đo tốc độ. Mọi thứ khác đang nhìn vào một cái bát thủy tinh.

Chúng có thể có hoặc không liên quan đến ứng dụng của bạn, nhưng một số lợi ích đối với giải pháp đa quy trình mà bạn dường như chưa xem xét là:

• Kiểm soát cấp phép chi tiết hơn. Bạn có thể có quyền riêng cho webcam và các cảm biến khác.
• Dễ dàng hơn để kiểm tra các cảm biến trong sự cô lập.
• Dễ dàng hơn để giả lập một cảm biến trong thời gian chạy.
• Dễ dàng hơn để khiến các bên thứ ba viết mã cho các cảm biến của họ mà không cần phải mở mã của bạn.
• Sử dụng các công cụ như wireshark để khắc phục sự cố, cả trong quá trình phát triển và tại hiện trường.
• Bối cảnh duy nhất tôi biết về nơi "trạng thái" được coi là thuộc tính tích cực là khi các phần trạng thái của hệ thống bị giới hạn trong phạm vi nhỏ như diễn viên , dường như hỗ trợ thiết kế của đồng nghiệp của bạn nhiều hơn của bạn.
• Dễ dàng hơn để phát hành khóa và khởi động lại chỉ một quá trình của cảm biến mà không phải khởi động lại toàn bộ hệ thống.
• Có thể mở rộng quy mô chỉ bằng cách thêm phần cứng.
• Giao tiếp ổ cắm với nguồn và mệnh trên cùng một máy tương đối hiệu quả.

Hạn chế bổ sung cho giải pháp đa quy trình:

• Đối phó với áp lực là phức tạp hơn.
• Nếu về cơ bản bạn chỉ truyền dữ liệu thô từ mỗi cảm biến mà không có bất kỳ bộ lọc hoặc xử lý nào, bạn vừa thay đổi ứng dụng bộ điều khiển của mình từ đọc từ trình điều khiển usb sang đọc từ trình điều khiển mạng, mà không có bất kỳ sự trừu tượng hóa thực sự nào.

Cách tiếp cận mà đồng nghiệp của bạn đang ủng hộ thường được gọi là kiến trúc microservice và khá thịnh hành những ngày này. Nó có một số lợi thế tiềm năng :

• Khả năng mở rộng: nó có thể làm cho việc mở rộng tương đối dễ dàng bằng cách thêm các máy / VM phụ.
• Tính mạnh mẽ: với một thiết kế phù hợp, nó có thể được chấp nhận đối với các quy trình dịch vụ vi mô riêng lẻ bị sập, mất kết nối hoặc không có sẵn.
• Khả năng mở rộng: sử dụng các công nghệ Web tiêu chuẩn để giao tiếp giữa các dịch vụ micros micros (thường là các yêu cầu http REST với phản hồi Json hoặc XML) có thể giúp các bên thứ ba hoặc khách hàng giao tiếp với hệ thống của bạn tương đối dễ dàng và mở rộng nó theo nhu cầu của riêng họ.

Nó cũng có một số nhược điểm:

• Hiệu suất: nói chung bạn sẽ trả chi phí hiệu suất cho giao tiếp giữa các quá trình. Điều này có thể rất quan trọng nếu bạn xây dựng API kiểu http REST.
• Độ phức tạp: thông thường bạn sẽ cần khá nhiều mã bổ sung để sắp xếp dữ liệu giữa các tiến trình so với việc truyền dữ liệu xung quanh giữa các luồng trong một quy trình. Bạn cũng sẽ giới thiệu các phụ thuộc vào thư viện để liên lạc qua mạng, hỗ trợ http, v.v.
• Khả năng gỡ lỗi: việc gỡ lỗi một ứng dụng được tạo thành từ nhiều quá trình giao tiếp độc lập thường phức tạp hơn so với sử dụng trình gỡ lỗi tích hợp của IDE trên một quy trình.

Tôi không chắc ý của bạn là gì khi bạn nói rằng thiết kế "không giống như một thiết kế rất nhà nước". Nói chung "trạng thái tối ưu" được coi là một đặc điểm xấu của thiết kế và các dịch vụ siêu nhỏ "không trạng thái" được coi là thiết kế tốt.

Tuy nhiên, dựa vào thông tin về các yêu cầu bạn cung cấp trong bài đăng của mình, tôi nghĩ rằng thiết kế dựa trên microservice sẽ quá mức cho trường hợp sử dụng của bạn và lợi ích sẽ không chứng minh được sự phức tạp bổ sung. Lợi ích của kiến ​​trúc microservice có xu hướng chỉ thực sự phát huy khi xây dựng các dịch vụ web quy mô lớn hơn, ưu tiên cho khả năng mở rộng, mạnh mẽ và mở rộng.

Những lợi ích tiềm năng của kiến ​​trúc microservice chỉ được hiện thực hóa với một thiết kế được cân nhắc kỹ lưỡng. Theo tôi, một kiến ​​trúc như vậy đòi hỏi thiết kế phía trước nhiều hơn (đặc biệt là khi nói đến giao thức để giao tiếp giữa các dịch vụ micros micros) so với một thiết kế quy trình duy nhất nếu nó thành công trong việc giải quyết vấn đề trong tay.