對 IPC 使用 websockets 是個好主意嗎？

Question

我有一個“主”進程和一些“工作”進程，我想在它們之間傳遞一些消息。 消息可以是二進制 blob，但每個都有固定的大小。 我想要一個抽象，它可以為我巧妙地緩沖和分離每條消息。 我不想在 TCP 之上發明我自己的協議，而且我找不到任何可以跨語言移植的簡單+輕量級的解決方案。 （截至目前，“main”進程是一個 Node.js 服務器，“worker”進程計划在 Python 中。）

Answer 1

這個問題純粹是基於意見的，但無論如何我都會試一試：

WebSocket 是一個矯枉過正的 imo。 首先，為了使 WebSockets 工作，您必須實現 HTTP（或至少它的某些基本形式）來進行握手。 如果你這樣做，那么最好堅持使用“普通”HTTP，除非有全雙工通信的原因。 到處都有很多工具可以通過（unix 域）套接字處理 HTTP。

但這也可能是一種矯枉過正。 如果你有工人，那么我想性能很重要。 最簡單且（可能）最有效的解決方案是以下協議：每條消息以 1-8（選擇一個數字）字節開始，這些字節決定了后續內容的大小。 內容是您想要的任何內容，例如 protobuf 消息。 例如，如果您想發送foo ，則發送0x03 0x00 0x66 0x6f 0x6f 。 前兩個字節對應於內容的大小（為3 ），然后 3 個字節對應於foo 。

Answer 2

聽起來您需要某種消息代理。

例如，您對“緩沖”的要求將排除 ZeroMQ（它是進程間通信的理想選擇，但沒有內置的消息持久性）。

如果您碰巧在 AWS 上，這會給您留下諸如 RabbitMQ 或 SQS 之類的選項。 您還可以查看 Kafka（AWS 上的 Kinesis）。 這些服務都提供消息“緩沖”，RabbitMQ 提供最大范圍的配置，但可能是最大的實現障礙。

另一種選擇是將 Redis 用作簡單的消息傳遞服務。

有許多選項，所有選項都適合不同的用例和環境。 我應該補充一點，“簡單和輕量級”並不真正適合除 - 也許 - ZeroMQ 之外的任何解決方案