В чем преимущество SOA и когда такую архитектуру нужно юзать?
Всем привет! Знаю, много букв, но...
У нас обычный проект - что то типа магазина, доставка, эквайринг, админка для менеджеров и все такое. Вся-вся бизнес-логика у нас находиться в так называемых "фасадах".
Для каждого контекста свой фасад: ФасадЗаказов, ФасадДоставки и т.п. Там даже та логика, которая принадлежит непосредственно объекту. Таким образом сами объекты у нас превращаются в просто структуры данных, а мы все больше уходим от ООП в сторону функционального программирования. Причем большинство методов в фасадах принимают не объекты, а их id. И сам метод уже выбирает нужный объект из БД и работает с ним.
В общем, я в проекте новенький, но уже прекрасно вижу насколько сильно такое решение усложняет разработку.
Когда я спросил почему так делается, сказали что проект планируется международный, и будет разнесен по разным серверам в разных частях света, а из каждого фасада будет сделан свой SOA сервис - это для удобства и для масштабирования.
Я понимаю, что некоторую логику можно оформить в качестве SOA, например, сервис отправки почтовых сообщений, сервис аутентификации. Но я совершенно не понимаю как разделить на сервисы высокосвязанную предметную логику, чтоб разнести по разным серверам, например, каталог товаров и список заказов.
На мою констатацию что нынче проблемы масштабирования решаются немного другими путями (всякие там разносы по серверам, кластеризацией, шардингами и пр) реакции не поступило.
Ну и прежде чем делать выступление почему такой подход неправильный, хотелось бы понять: может я чего-то не понимаю в SOA? Может он имеет место быть в нашем проекте?
В общем, я в проекте новенький, но уже прекрасно вижу насколько сильно такое решение усложняет разработку.
В чем именно неудобство?
Вообще проблема с SOA в том, что многие воспринимают этот термин немножко по разному. Кто-то вспоминает IBM ESB, кто-то что-то слышал про микросервисы и SCM...
Если под СОА разработчики понимают именно вещи типа SCM и микросервисов грамотно организованных, то я не думаю что "шардинги. кластеризация и т.д." вам сильно помогут (хотя кто его знает, сложно удить не зная бизнес логики, но если это магазин но думаю не помогут).
При использовании SOA и т.д. можно на каждый микросервис посадить свою команду. И так у вас скейлиться будет приложение не только в плане производительности но и в плане поддерживаемости и управления командами.
Словом... погуглите на эту тему может для начала. У Мартина Фаулера например есть неплохие лекции на эту тему И да:
нынче проблемы масштабирования решаются немного другими путями (всякие там разносы по серверам, кластеризацией, шардингами и пр) реакции не поступило.
Я не знаю откуда вы взяли эту информацию. Все крупные проекты которые я знаю скейлятся именно за счет микросервисов.
ex Software Engineer at Reddit TS/React/GraphQL/Go
удобно понимать в терминах: микросервисы или монолит
1) микросервисы имеют преимущество горизонтального масштабирования, но они stateless, поэтому для организации общей памяти необходим сервис кэширования, взаимодействие сетевое
2) монолит имеет преимущество, когда требуется общая память (быстрый отклик) для частей приложения, он statefull, поэтому сетевые задержки минимальны или отсутствуют
стоит помнить: операции I/O всегда медленней CPU, поэтому выбор зависит от зачади, а в целом применяют комплексные решения состоящие из первого и второго
Простой
