Уже разобрались в прошлой статье, когда микросервисы не нужны, сейчас рассмотрим обратную ситуацию.
Возможно, получится слегка идеалистично, но представьте, что у вас быстрорастущий проект, постоянно требуются новые сотрудники, необходимо масштабироваться. Здесь встает вопрос о смене архитектуры, когда чувствуете, что монолитная уже не работает на вас.
Объективно оценить свой проект сложно, но начать можно с вопроса с капелькой синдрома самозванца «а вырос ли мой проект до микросервисов? как понять, что нужно переходить на них?»
Начнем с того, что перейти на них быстро не получится, скорее всего, вначале вы разгрузите наиболее загруженный модуль, например, на который приходят заявки. Посередине пути ваша архитектура будет походить на минисервисы, пока каждый модуль не будет вынесен отдельно и связан между собой. Напомню, что если их не «подружить» между собой, вся ваша работа не будет иметь смысла.
Небольшие модули легче контролировать, несколько точек отказа дают большую надежность, это основное преимущество микросервистной архитектуры, ее поэтому все и хотят. Например, у вас большой интернет-магазин, в минуту больше тысячи заказов, страшно хранить эту структуру в монолите, отключится один элемент — прекратит работу весь магазин до решения проблемы, а значит, большая потеря прибыли и лояльности к бизнесу. С микросервисами все обойдется меньшей кровью, если баг обнаружен в модуле «регистрация» , то новые пользователи просто не смогут залогиниться, но смогут выбрать товар и оформить заказ.
