Связь между процессами: tcp vs unix sockets, ipc vs nats

Question

Я разбиваю большое приложение на несколько процессов, и каждый процесс должен связываться друг с другом.

пока что он будет на том же сервере, но позже несколько серверов в одной локальной сети будут иметь несколько процессов, которые должны будут взаимодействовать друг с другом. (означает сервис на одном сервере, с сервисом на другом сервере на том же vpc)

так что мои необработанные опции: tcp или unix sockets. Я знаю, что сокеты Unix могут быть полезны, только если вы на одном сервере. но мы думаем о написании нашей собственной реализации, что на тех же серверах процессы будут взаимодействовать в UNIX-сокетах и ​​между серверами, которые будут обмениваться данными с помощью tcp.

Стоит ли это? конечно, сокеты tcp медленнее, чем сокеты UNIX. Потому что он не проходит через сеть и не обертывается данными, связанными с tcp. вопрос в том, сколько? Я не смог найти онлайн-доказательство бенчмаркинга между сокетами tcp и unix. если tcp добавляет 3% -5% накладных расходов, это круто, но может быть, это больше? Я хотел бы учиться на опыте больших проектов ... других людей на протяжении многих лет, но не нашел ничего подходящего.

... Следующая

наш проект является NodejS проект.

некоторые люди могут сказать, что я могу использовать брокера для сообщений, так что я попытался с помощью nats.io по сравнению с узлом-IPC (https://www.npmjs.com/package/node-ipc), и я обнаружил, что узел-IPC в 4 раза быстрее, но Nats имеет прохладное публикация-подписка особенность ... но производительность важна.

поэтому у меня есть тонны вариантов, нет конкретного решения.

вся информация относительно выпуска была бы принята с благодарностью.

Answer 1

Вопрос на самом деле слишком широк, чтобы ответить, но один ответ на TCP против UNIX сокеты:

Архитектора вашего кода, так что вы можете легко перемещаться между теми, если это необходимо. Модель программирования для них в основном одинакова (оба являются двунаправленными потоками данных), а API-интерфейсы чтения/записи на уровне ОС, а также в большинстве фреймворков одинаковы. Это означает, например, в узле оба наследуются от интерфейсов Readable/WriteableStream. Это означает, что только один код, который вам нужно изменить для переключения между ними, - это слушатель на стороне сервера, на котором вы вызываете API-интерфейсы TCP, вместо того, чтобы использовать сокеты домена unix, и API-интерфейсы. Вы даже можете, чтобы ваше приложение принимало оба типа подключений, а затем обрабатывало их одинаково внутри.

Поддержка TCP всегда хороша, потому что это дает вам некоторую гибкость. С моим последним измерением накладные расходы были немного больше (я думаю, 30% по сравнению с TCP через loopback), но это все микро-тесты, и это не имеет большого значения для большинства приложений. Сокеты домена Unix могут иметь преимущество, если требуются некоторые из их специальных функций, например. возможность отправки файловых дескрипторов через них.

И касается TCP против NATS & Co: Если вы не знакомы с сетевым программированием и протокольным дизайном, имеет смысл использовать готовые системы IPC. Это может быть что угодно: от HTTP до gRPC до Thrift. Это все системы точка-точка. NATS отличается, поскольку его брокер сообщений, а не RPC. Он также требует дополнительного компонента посередине. Независимо от того, что это имеет смысл, все зависит от приложения.