Открыть список
Как стать автором
Обновить

Комментарии 4

В микросервисах можно взять отдельный компонент, определить, что в нем происходит и работать только с ним.

Этот аргумент никогда мне не был понятен. В Go очень просто разбить монолит на модули, каждый модуль вести в своем репозитории и цеплять их к монолиту через go.mod.


Микросервисная архитектура может оправдать себя, например, если есть требование масштабировать кластер по каждому модулю(сервису) отдельно.


А то, что описано в статье, больше подходит под заголовок "Переписываем часть проекта с PHP на Go — правильно и безболезненно".

Ваше понимание монолита неправильное, а значит и статья фигня. Код, который проходит всё проверки solid и grasp не рушится хоть его с ноги пинай. Проблемы лежат совершенно в иной плоскости — невозможности запустить его целиком на доступном железе, либо возможности запустить, но не разрабатывать или отлаживать. Понаберут "экспертов" за 200 рублей за 1000 знаков

Честно ну реально не понимаю какие проблемы решает эта архитектура. Ну возьмём обычный пхп монолит. Ставим перед ним балансировщик, раскидывает код в кластер, общие ресурсы делаем общими ресурсами, типо мемкеш сервер, файловая система какая-то для загрузок и т.д.
Надо вести разработку отдельно и не давать доступ в общий проект? Ок выносим модули в гит сабмодули и даём интерфейсы для автокомплита и т.д.


Преимущество что микросервисная архитектура падает частями? Это вообще стремный кейс, обычно оно либо работает либо нет. Делам обработку ошибок и перенаправдяем юзера на страницу ошибки зайдите позже что-то пошло не так. В случае с СПА еще проще.

Деплоить раздельно, тестировать.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.