6 причин делать микросервис
Микросервисы имеют и плюсы и минусы, на которых мы сейчас останавливаться не будем. Существует 6 причин разделять компоненты на микросервисы, вместо разработки монолита:
- Разная частота изменений (сервисы, которые меняются часто, имеет смысл выделить в отдельный микросервис).
- Разный жизненный цикл (например, какой-то компонент требует особого вида тестирования или к нему особые требования у регуляторов).
- Разные требования к масштабированию (например, сильно нагружены чаще всего только 1-2 сервиса из десятков).
- Изоляция сбоев (если взорвется один сервис, остальные продолжат работать, но при этом критичных компонентов не так много).
- Фасад к внешним зависимостям (устойчивость к смене их API, всякие AAA, и т.д.).
- Необходимость в разном техническом стеке в разных частях системы.
Все, что изложено выше, является, по сути, вольным пересказом вот этой статьи: https://tanzu.vmware.com/content/blog/should-that-be-a-microservice-keep-these-six-factors-in-mind.
Но давайте приведем пример, ведь вышеперечисленные причины, кажется, можно использовать для создания Outpost в архитектурном паттерне Цитадель.
Цитадель
Citadel — архитектурный паттерн проектирования наряду с паттернами “Монолит” и “Микросервисы”.
Состоит в выделении некоторой функциональности из монолита в виде “Outpost” и сохранении основного условно монолитного ядра.
Для того, чтобы принять решение оставлять ли некоторую функциональность в монолите или же вынести ее в микросервис, мы и можем вспомнить 6 причин делать микросервис.
Хороший пример для выделения в Outpost — сервис аутентификации, на который обычно бывает высокая нагрузка, или сервис-представление для какого-нибудь счетчика, который выдает пользователю количество непрочитанных сообщений.
В итоге получается, что для основной функциональности мы пользуемся плюсами монолита, а для граничных условий пользуемся плюсами микросервисов.
На этом все, больше полезных материалов смотрите в моем блоге.
