Комментарии 4
В микросервисах можно взять отдельный компонент, определить, что в нем происходит и работать только с ним.
Этот аргумент никогда мне не был понятен. В Go очень просто разбить монолит на модули, каждый модуль вести в своем репозитории и цеплять их к монолиту через go.mod.
Микросервисная архитектура может оправдать себя, например, если есть требование масштабировать кластер по каждому модулю(сервису) отдельно.
А то, что описано в статье, больше подходит под заголовок "Переписываем часть проекта с PHP на Go — правильно и безболезненно".
Честно ну реально не понимаю какие проблемы решает эта архитектура. Ну возьмём обычный пхп монолит. Ставим перед ним балансировщик, раскидывает код в кластер, общие ресурсы делаем общими ресурсами, типо мемкеш сервер, файловая система какая-то для загрузок и т.д.
Надо вести разработку отдельно и не давать доступ в общий проект? Ок выносим модули в гит сабмодули и даём интерфейсы для автокомплита и т.д.
Преимущество что микросервисная архитектура падает частями? Это вообще стремный кейс, обычно оно либо работает либо нет. Делам обработку ошибок и перенаправдяем юзера на страницу ошибки зайдите позже что-то пошло не так. В случае с СПА еще проще.
Из монолита на микросервисы — меняем архитектуру правильно и безболезненно