Pull to refresh

Comments 10

Советую вам попробовать github.com/KnpLabs/KnpGaufretteBundle для абстракции над файловой системой. Удобнее будет потом с переездом куда нибудь (если планируеться или придеться).

Спасибо, попробую.

лучше уж FlySystem. Оно как-то удобнее.

По теме не выскажусь, но огромное вам спасибище!

Можно было бы назвать это микросервисной архитектурой

Где та грань, когда наличие воркеров и очередей позволяет сказать что проект использует SOA архитектуру а не обычный монолит? Ведь если это все что требуется — значит подавляющее большинство проектов построено с использованием SOA.


Я по вашему описанию вижу монолит. С неплохим разделением ответственности, с грамотным выбором инструментов, который не стыдно показать, но все же монолит. (в этом к слову плохого ничего нет)


Вот если бы в рамках вашего проекта был еще сервис позволяющий публиковать объявления, то какие компоненты подвергнутся изменениям?

Спасибо за развернутый комментарий.

Очереди используются только в 1 сервисе и не служат основным инструментом для общения между сервисами (на начальном этапе очереди не использовались).

Из 5ти сервисов можно выделить 2 полноценных микросервиса — сервис для бота и сервис классификации объявлений. Они могут работают полностью независимо от других сервисов по HTTP протоколу и один из них имеет свою БД (другому она не нужна).

Действительно, остальные 3 сервиса общаются через БД и их можно было бы назвать монолитом, будь они написаны на одном языке и имея бОльшую связанность. Но в этом и есть суть SOA или микросервисного подхода:
  • использовать необходимые технологии по необходимости
  • независимо разрабатывать сервис
  • при необходимости горизонтально масштабироваться
  • функционировать независимо от других сервисов


Например в книге «Шаблоны интеграций корпоративных приложений» одним из рассматриваемых способов связи между различными сервисами служит «Общая БД». Не думаю, что такое приложение можно назвать монолитом.

Я мог бы сделать для каждого из этих сервисов свою БД и HTTP API, что обеспечило бы им большую независимость, но это отняло бы у меня больше времени.

Поэтому я не могу назвать эту архитектуру микросервисной или монолитом, но вот сервис-ориентированной — да.
и не служат основным инструментом для общения

Очереди лишь для примера. Как таковой шины данных у нас нет, иначе нам нужно было бы как-то пулить данные что бы действия получать. У вас же просто есть 2 процесса которые работают с одной базой, и живут себе независимо. Одна часть грубо говоря пишет, другая читает. Это в целом можно назвать cqrs, если хотите (хотя тоже будет расплывчато) но не SOA и уж тем более микросервисами. Иначе любой проект где есть Cron и общая база может называться SOA.


Из 5ти сервисов можно выделить 2 полноценных микросервиса

Выходит так. Сервис разбора объявлений (который как я понимаю stateless) в целом можно так же отдельным микросервисом назвать.


Но в этом и есть суть SOA или микросервисного подхода:

ну там основной момент — это независимый цикл разработки сервиса, в частности деплоймент. А все что вы перечислили в целом и под монолит подходит. Разве что "функционировать отдельно"… Но тут такой момент — вспомним пример с cron, там тоже части работают независимо. Но мы же не называем это SOA.


но вот сервис-ориентированной — да.

в этом и суть, сегодня SOA это настолько широкий термин что в целом он не имеет смысла.

Особенно порадовали проектируемые станции метро в Екатеринбурге.
Да, станции могут быть закрыты или в стадии проектирования, но они все равно могут служить ориентирами как для тех, кто сдает жилье, так и для тех, кто его ищет.
Sign up to leave a comment.

Articles