Miroservices interervice communication with Sockets

Question

В настоящее время я разрабатываю систему для следующего сценария: Данные передаются от клиента, обрабатываются несколькими службами один за другим (без параллелизма). Затем данные передаются обратно клиенту во время его анализа. Важно, чтобы сервер возвращался к частичным анализируемым данным клиента во время процесса (вот почему мне нужны сокеты).

Клиент может даже отправлять дополнительную информацию во время анализа на сервере, и это может повлиять на результаты анализа.

A high level sketch I made

Я сделал много исследований в этом, и я видел только REST microservices ИЛИ обработку асинхронной с сокетами с использованием всех видов очередей сообщений. Я не видел никого, кто реализует микросервисы с таким количеством открытых сокетов непосредственно между службами.

Теперь на мой вопрос: Я правильно делаю здесь? Является ли открытие сокетов между всеми моими серверами неправильным или ненадежным?

Answer 1

Это очень широкий вопрос, так что я постараюсь дать вам несколько общих мыслей по этому вопросу:

Прежде всего, я думаю, что общая идея прекрасно. Все микросервисы используют сокеты так или иначе, вы просто берете их на более низкий уровень, без различных абстракций сверху. Это имеет смысл, особенно если у вас есть некоторые очень специфические требования.

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

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

Прежде всего, вам понадобится сервисное обнаружение для микросервисов, чтобы найти друг друга.

Тогда вам нужно будет разработать протокол между каждой парой служб - вам нужно будет указать сообщения и правила о том, когда и как их отправлять. Вам нужны сборщики сообщений и синтаксические анализаторы; а также логику обработки различных ошибок сообщений и совместимость с обратной/обратной совместимостью. Это сложнее, чем кажется, особенно если сообщение должно быть надежным, что приводит меня к следующему пункту - обработка сетевых сбоев.

Какие сетевые сбои? TCP надежный, не так ли? Ну, не совсем. Во-первых, есть разъединения и различные сетевые ошибки. Затем возникают некоторые тихие сбои - попробуйте открыть сокет на удаленном компьютере, затем вдруг потянув за свой сетевой кабель. Сколько времени потребуется, чтобы локальный сокет выбрал исключение? Ну, получается, что это может занять минут, минуты, в течение которых вы местный сокет думает, что машина для удаления жива и хорошо. Конечно, если он прибывает, то он прибывает без ошибок и в правильном порядке. Но это только если он прибывает.

Тогда есть резьба. Хотя это не уникально для чистых сокетов, нарезка имеет тенденцию быть более болезненной на более низких уровнях абстракции.

Так что, хотя это может быть сделано, вы можете попытаться избежать повторного изобретения некоторых колес здесь. Например, как насчет использования библиотеки RPC? Они существуют для всех современных языков, и уже решены некоторые проблемы, с которыми вам придется иметь дело.