Блог

Итак, у нас есть веб-служба, которая, помимо прочего, автоматизирует запуск двоичного файла. Этот двоичный файл имеет std:out, который мы хотели бы передавать клиентам в режиме реального времени. Мы хотим, чтобы это было идемпотентным в том смысле, что при разрыве соединения клиент может повторно подключиться и продолжить с того места, где он остановился, включая просмотр истории того, что передавалось в прошлом. Наш веб-сервер написан на go.

Какие технологии я могу использовать для чего-то подобного, поскольку я не совсем знаком с тем, как разрабатываются подобные системы?

С моей головы вот что приходит мне в голову:

Один процесс, который записывает в файл, клиент подключается к серверу через сокеты, а сервер считывает данные из файла и отправляет данные в сокет. Потребуется маркер, чтобы указать, что файл завершен. С точки зрения масштабируемости это кажется раздражающим, поскольку нам нужно управлять подключениями к сокетам, узкими местами на диске и т. Д.

Можно ли здесь использовать что-то вроде kafka или kinesis? Может быть, cloudwatch или существующие системы ведения журнала? Как, например, действия github делают это?

Похоже, это идеальный вариант использования для потоковой передачи сокетов. Для аналогичного варианта использования нам пришлось передавать журналы Kafka Connect от рабочих в пользовательский интерфейс, который мы создали. Этот фреймворк Frontail, написанный на Node JS, может быть хорошим началом.

Сервер журнала узла / перехода, который передает данные из сокетов и записывает в Kafka, — это все, что вам нужно в принципе. Клиенты будут подключаться к службе журналов (а не к серверу двоичных журналов), который принимает сообщения от Kafka. Следовательно, вам не нужно поддерживать столько подключений, сколько имеется клиентов.

Еще несколько вещей:

• Idempotency это не то, что вы определили здесь в контексте потерянного соединения с повторным подключением. Это скорее ожидание надежности.
• Вы не указали, насколько большими будут потоки файлов журнала и количество клиентов, которые будут их использовать. Вы также не указали, насколько важна потоковая передача этого журнала. Если это критически важно, дизайн меняется.
• Выполняется ли двоичный файл локально или удаленно. Если локально, создается ли журнал локально или удаленно?
• Служба, которая автоматизирует двоичный файл при отправке веб-запросов, является анти-шаблоном. Вы должны запланировать это «задание» в кластере, предназначенном для планирования, например, on Azkaban . У вас будет больше гибкости, и ваш сервис избавится от запутанной автоматизации.

Если вы выберете Azkaban и правильно настроите свой стандартный вывод, весь журнал заданий можно получить с помощью API

 GET /executor?ajax=fetchExecJobLogsamp;session.id={{azkabanSessionId}}amp;execid=<>amp;offset=0amp;length=10000amp;jobId=<>