antonb73 Dec 15 at 14:37

Архитектура подсистемы управления заданиями

Medium

6 min

System Analysis and Design * High performance * Distributed systems *

Case

Comments 4

LeoD Dec 20 at 08:47

неплозо. подсвечу еще место, которое ограничивает горизонтальную масштабиркемость.

ваш же пример с employee. Если придет 10 событий для одного конкретного employee и будет несколько workers для обработки заданий с типом employee то не получится сделать гарантированный порядок обработки сообщений. возможно в вашей задаче это не критично, но я с таким сталкивался не раз

antonb73 Dec 20 at 08:52

У нас можно каждый доменный объект обрабатывать независимо.
Если кретична последовательность выполнения заданий, то это другая задача, которая параллелится на более высоком уровне, либо вообще не параллелится, уж зависит от задачи.

Masnin Dec 21 at 14:05

Возникло несколько вопросов, ответ в статье не нашел:

1) Есть ли у заданий какой-то payload? Например, собрать данные по конкретному сотруднику с идентификатором, скажем "42"? Если есть - то как он сохраняется? В бд или в виде JSON в отдельном хранилище?

2) Судя по схеме - в одну PG базу данных ходят сразу 3 микросервиса (планировщик ,менеджер и диспетчер). Обычно это антипаттерн при проектировании распределенных систем. Такое решение осознанно выбрано? Почему?

3) Если под каждый тип задания создаётся свой пул микросервиса - что требуется изменить в коде системы (вроде как точно нужно менять воркеров как минимум)? В случае изменений в коде для нового типа задания - как мутирует код? Дописывается в том же репозитории или форк может быть?

antonb73 Dec 21 at 15:10

1) по необходимости можно любой payload хранить в отдельном поле "payload", строка, мы храним там json, Worker сам знает как его десериализовать.

2) Обычно это пространные рассуждения про один микросервис одна СУБД идут от диванных архитекторов, которые пишут книги по теории микросервисов и выдумывают всякую муть, чтобы добавить в книгу еще страниц 30. СУБД справляется, вопросов по конфединциальным данным нет, аутентифиция доступа к данным не нарушается, СУБД справляется с нагрузкой, иных требований по изоляции данных нет? Значит ок. Второй момент стоимость отдельной СУБД, у нас это SaaS, а микросервисов 200+.

3) Worker как раз создаётся для нового типа задания, как и Scheduler - писал это. Dispatcher он сейчас универсальный, так что его дорабатывать под новый тип задания не нужно. Код остальных подсистем не меняется именно для загрузки данных, меняется конфигурация Kubernetes - добавляются новые микросервисы. Кодом управляйте как вам удобнее - это не влияет на функции системы, это влияет на рабочий процесс разработки приложения. У нас один репозиторий для всего, там много папок и работаем по gitflow - этого хватает.

Если есть ещё вопросы, задавайте.