Comments 10
По теме не выскажусь, но огромное вам спасибище!
Можно было бы назвать это микросервисной архитектурой
Где та грань, когда наличие воркеров и очередей позволяет сказать что проект использует SOA архитектуру а не обычный монолит? Ведь если это все что требуется — значит подавляющее большинство проектов построено с использованием SOA.
Я по вашему описанию вижу монолит. С неплохим разделением ответственности, с грамотным выбором инструментов, который не стыдно показать, но все же монолит. (в этом к слову плохого ничего нет)
Вот если бы в рамках вашего проекта был еще сервис позволяющий публиковать объявления, то какие компоненты подвергнутся изменениям?
Очереди используются только в 1 сервисе и не служат основным инструментом для общения между сервисами (на начальном этапе очереди не использовались).
Из 5ти сервисов можно выделить 2 полноценных микросервиса — сервис для бота и сервис классификации объявлений. Они могут работают полностью независимо от других сервисов по HTTP протоколу и один из них имеет свою БД (другому она не нужна).
Действительно, остальные 3 сервиса общаются через БД и их можно было бы назвать монолитом, будь они написаны на одном языке и имея бОльшую связанность. Но в этом и есть суть SOA или микросервисного подхода:
- использовать необходимые технологии по необходимости
- независимо разрабатывать сервис
- при необходимости горизонтально масштабироваться
- функционировать независимо от других сервисов
Например в книге «Шаблоны интеграций корпоративных приложений» одним из рассматриваемых способов связи между различными сервисами служит «Общая БД». Не думаю, что такое приложение можно назвать монолитом.
Я мог бы сделать для каждого из этих сервисов свою БД и HTTP API, что обеспечило бы им большую независимость, но это отняло бы у меня больше времени.
Поэтому я не могу назвать эту архитектуру микросервисной или монолитом, но вот сервис-ориентированной — да.
и не служат основным инструментом для общения
Очереди лишь для примера. Как таковой шины данных у нас нет, иначе нам нужно было бы как-то пулить данные что бы действия получать. У вас же просто есть 2 процесса которые работают с одной базой, и живут себе независимо. Одна часть грубо говоря пишет, другая читает. Это в целом можно назвать cqrs, если хотите (хотя тоже будет расплывчато) но не SOA и уж тем более микросервисами. Иначе любой проект где есть Cron и общая база может называться SOA.
Из 5ти сервисов можно выделить 2 полноценных микросервиса
Выходит так. Сервис разбора объявлений (который как я понимаю stateless) в целом можно так же отдельным микросервисом назвать.
Но в этом и есть суть SOA или микросервисного подхода:
ну там основной момент — это независимый цикл разработки сервиса, в частности деплоймент. А все что вы перечислили в целом и под монолит подходит. Разве что "функционировать отдельно"… Но тут такой момент — вспомним пример с cron, там тоже части работают независимо. Но мы же не называем это SOA.
но вот сервис-ориентированной — да.
в этом и суть, сегодня SOA это настолько широкий термин что в целом он не имеет смысла.
Архитектура сервиса сбора и классификации объявлений жилья из Вконтакте