>>15594

>Или как это? Что-то не особо представил себе.

Можно папка, можно целый сервак, можно что угодно.
Вот, допустим, у тебя есть сервис авторизации и управления доступом, с неким API, пользователь открывает страницу/карточку в системе/ещё какую-нибудь хурму, большой сервис берёт и по API спрашивает "SIDSession ID, PathЧто пытаются открыть: можно?" и получает "да"/"нет"/"пусть сначала авторизуется".
Если получил "да", то открывает запрошенный ресурс, если "нет" -- выдаёт access deny, если третий -- открывает окошко логина.
Так вот, для внешней системы не интересно, как внутри сервиса авторизации устроено назначение и разграничение доступов, проверка пароля и прочее, оно знает только как спросить за доступ и как реагировать на ответы.
Если сервис авторизации и контроля доступа кроме этого ничего не делает, то это микросервис вне зависимости от того, насколько он большой.
И ещё раз, неважно, есть ли там папочки, Docker (который вообще говоря хоть и позволяет удобно работать с микросервиами не заточен именно на них), Swarm/Kubernetes или ещё что, хотя они дают свои плюшки (про них я отдельно кое-что могу рассказать, конечно, но сейчас не важно).

С другой стороны -- монолит. В монолите нет выделенного сервиса, авторизацией занимается совокупность методов, находящихся в основном коде системы.

Итак, о профитах:

> Упрощает разработку и поддержку

Когда приходит тикет на доработку системы авторизации ты берёшь ограниченную часть кода, которая ничем кроме разграничения доступа не занимается. Кода меньше, связей с внешними системами меньше, разобраться проще, наделать ошибок -- сложнее. Бонус: повышается качество и надёжность системы в целом.

> Упрощает тестирование

Ты запустил этот сервис в тестовом контуре с тестовой БД и шлёшь ему по API разные запросы и слушаешь всякие ответы. Это легче, чем взять целиком сайт или программу и тыкать в разные её куски, чтобы понять, не сбойнёт ли где контроль доступа.

> Упрощает масштабирование

Пусть даже без кубера. Система контроля доступа изолирована и может быть запущена отдельно от остальной системы, а значит, если ей не хватает ресурсов можно поднять 2, 3,...100 инстансов и настроить балансировщик (DNS Round-robin, NGINX или аппаратный балансер, HA-Proxy, ReplicaSets -- не важно, главное, чтобы Ops это умел).

О недостатках:
1. Накладные расходы ВЫШЕ. Передать значения в свою же функцию проще и быстрее, чем обернуть их в запрос, передать, дождаться ответа, распарсить этот ответ...
2. Повышается общая сложность проекта. Иметь разрозненные куски и поддерживать связи между ними, вовремя актуализировать API в случае изменений... В общем, возни уйма.

Реально профиты от микросервисов превышают недостатки только в больших и выше проектах, они прекрасно живут в огромных, иногда приживаются в крупных, в гигантских это просто единственный пристойный путь потому что там внутренних связей OVER ДОХУЯ.
В мелких же, небольших и даже средних проектах (вплоть до интернет-магазина со средней нагрузкой, примерно) лучше не заморачиваться. Но это не значит, что нужно класть хуй на HA-DB, CDN, DDoS-Protection и прочее.