Какую выбрать архитектуру для распределённой системы по обработке изображения (docker, микросервисы)?

Question

[log95]

Есть веб-приложение. У него есть потребность по изображению получить некие данные. В формировании данных участвуют три сервиса.



Изображение подаётся на вход Service1. Он возвращает данные, которые подаются на вход Service2. Результат Service2 подаётся на вход Service3. И результат Service3 отдаётся клиенту.
Так как сервисы весьма разрозненные со своим окружением, то решено было выделить их в отдельные контейнеры.
Вопрос - как правильно организовать передачу данных в таком случае?

Как я понимаю, нужен какой-то контроллер, как указал на изображении, который будет передавать данные между сервисами и возвращать результат в основное приложение.
Все узлы (приложение, контроллер, сервисы) вынести в контейнеры.
Передачу данных между всеми узлами выполнять через HTTP-запросы (в частности, изображение передавать через base64).
Так как кол-во нод любого сервиса может быть разное количество, то получается нужен ещё балансировщик для контроллера, который будет помогать определять случайную ноду сервиса.
Вышеописанное - построение "велосипеда" и есть какие-то стандартные техники?
Или же есть статья, описывающая подобное (передача данных, контроллер для сервисов)?

Comments

[sim3x]

Передачу данных между всеми узлами выполнять через HTTP-запросы (в частности, изображение передавать через base64).

мда

Так зачем вам все базворды из вашего вопроса если все делается в одну строку в баше?

[d'Ivan]

Похоже на переусложнение в проектировании ПО. Непонятно зачем нужны все эти контейнеры-сервисы. Один сервис не сможет все сразу получить?

[log95]

sim3x, о какой "одной строке" в баше речь?

[sim3x]

log95,

Можно будет сказать после расшифровки фразы

Изображение подаётся на вход Service1. Он возвращает данные, которые подаются на вход Service2. Результат Service2 подаётся на вход Service3. И результат Service3 отдаётся клиенту.

[log95]

Роман Мирр, Можно сделать один монолит и установить всё туда с 3 сервисов, это да. Но я лично вижу логическое разделение на что-то отдельное, так как 3 сервиса имеют своё окружение (разные ЯП, программы). Как следствие, легко будет заменить один сервис на другой. Или же можно будет для Service1 сделать ноды с разными решениями, чтобы сравнить потом результаты.

[log95]

sim3x, Не знаю, насколько вам интересно будет погружаться в саму бизнес-логику. Вкратце она такая:
- Service1 делает обработку изображения. OpenCV + python скорее всего (нахождение контуров, вырезка и прочее). На выходе будет порядка 3-9 изображений
- Service2 делает распознавание. Тут или tesseract или нейронная сеть. На выходе несколько текстов.
- Service3 делает обработку нескольких текстов и выдаёт результирующий текст. Скорее всего тут будут python-библиотеки.

Всё это вместе с самим приложением в одну машину ставить не хочется. Особенно если будут конфликтовать версии программ у сервисов. И смена окружения одного сервиса на другое, когда всё на одной машине выглядит для меня как-то опасно.

Вы думаете правильнее будет написать bash скрипт и разместить всё на одной машине?

[d'Ivan]

log95, в таком случае Service2 и Service3 стоит логически объединить.
А размещать или не размещать сервис в контейнере - это скорее вопрос необходимости, нежели архитектуры.

[log95]

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

[sim3x]

log95,

Вы думаете правильнее будет написать bash скрипт и разместить всё на одной машине?

да
И пока у вас все будет влезать по памяти/цпу/иопсам - вам стоит держать все на одной машине

Особенно если будут конфликтовать версии программ у сервисов

не будут. И есть много способов сделать так чтоб никто ни с кем не конфликтовал

И смена окружения одного сервиса на другое, когда всё на одной машине выглядит для меня как-то опасно.

ну вот и избавьте от данной боязни вместо создания каши из базвордов

И почитайте, что такое base64

Answer 1

[d'Ivan]

Исходя из

этого

Не знаю, насколько вам интересно будет погружаться в саму бизнес-логику. Вкратце она такая:
- Service1 делает обработку изображения. OpenCV + python скорее всего (нахождение контуров, вырезка и прочее). На выходе будет порядка 3-9 изображений
- Service2 делает распознавание. Тут или tesseract или нейронная сеть. На выходе несколько текстов.
- Service3 делает обработку нескольких текстов и выдаёт результирующий текст. Скорее всего тут будут python-библиотеки.

уточнения, вижу архитектуру такой:
Поскольку сервисы взаимосвязаны между собой так, что их нужно вызывать поочередно, то логично связать обработку данных при помощи очереди сообщений:
Изображение (ID=123) -> Очередь Нарезка Изображений (OpenCV) -> каждое полученное нарезанное изображение кладём в Очередь OCR -> распознанный текст кладём в Очередь Анализ Текста.

Для обработки изображения в Очереди Нарезка Изображений кладем его по некоторому пути (им может быть путь в AWS S3) и воркер этой очереди с инстанса некоторой ВМ обращается по заданному пути и результаты работы сохраняет по заданному пути для обработанных изображений и каждое из них в отдельности (путь и ID изображения) кладёт в Очередь OCR.

Comments

[log95]

Спасибо за подробный ответ.
Несколько уточнений:
1) Получается на каждом из сервисов будет хранится своя очередь (путь до файлов, либо текст), так? А что за реализация очереди здесь подходит?
2) Каждый сервис записывает свой результат на некий storage (AWS S3). Получается очереди всех сервисов мониторят появление новых данных? Service1 же напрямую не пишет в очередь Service2?
3) Как основное приложение узнает о результате? Service3 же результат пишет в storage. У него тоже должен быть мониторинг?

[d'Ivan]

1. очередь сообщений это message queue. Если непонятно что это, то нужно читать. Воркеры могут находиться на любой ВМ.
   
2. Воркеры ведут мониторинг очереди и ждут если в очереди пусто. Воркер 1-й очереди кладет результат в очередь 2.
   
3. основное приложение узнает о результате когда воркер последней очереди обработал сообщение и сообщить приложению можно через pub/sub.
   

ID изображения как идентификатор кдадут во все очереди.

Answer 2

[Ерлан Ибраев]

Асинхроно, через Service Bus на Kafka.
<:o)