Микросервисная не архитектура: плюсы и минусы стратегии деплоя
Вопрос микросервисной архитектуры стал особенно популярным в последние несколько лет. С одной стороны, мы имеем подход, который позволяет разделять сложные монолитные системы на более мелкие сервисы. А с другой - огромное количество мифов и вопросов о том, когда же действительно необходимо использовать микросервисы, а когда же останавливаться на монолитной архитектуре.
Что такое архитектура IT-проекта?
Для начала давайте представим, что из себя представляет IT-архитектура, но на примере чего-то реального, не связанного с софтом. К примеру, представим себе архитектурный план библиотеки. Мы увидим чертеж, на котором указаны наиболее важные и наиболее значительные детали. Там будет схема расположения читального зала, схема расположения стеллажей с книгами, схема входа и выхода в это здание. Но в этом чертеже не будет ничего того, что к библиотеке не относится. То есть на чертеже мы не увидим, какая там плитка, какие там ковры, люстра, светильники и т.д. Всё это будет второстепенной подробностью для этой архитектуры. И хороший архитектор, когда рисует чертеж, он дает владельцу библиотеки возможность выбрать, какая конфигурация ему нужна. Кому-то нравятся персидские ковры, кому-то - турецкие, а кому-то вообще, возможно, нравится плитка.Так же и в программе. Главным чертежом программы является вариант использования системы. То есть, если у нас есть чертеж интернет-магазина, мы видим вариант использования «Купить товар». В этом варианте использования нет упоминания того, как именно он сохраняется. То есть даже если мы сохраняем товар в базу данных, мы благодаря инверсии зависимости создаем абстракцию и говорим, что товар сохраняется в хранилище товаров, а потом реализуем его с помощью полиморфизма, с помощью разных ковров – персидских, турецких, базы данных файлов, оперативной памяти и так далее.И микросервисы по своей сути являются всего лишь ковром для нашей программы. То есть это деталь, которую можно при необходимости поменять. И хороший архитектор пишет код так, чтобы можно было легко перейти от микросервисов в монолит и обратно, в зависимости от текущей потребности бизнеса.
Сервис и микросервис
Давайте теперь разберем понятие сервиса. Сервис – это процесс, запущенный на компьютере пользователя. Но этот сервис, в отличие от обычных процессов, которые есть в системе, принимает и отдает данные по интернету. То есть он использует технологию socket. Взаимодействие с таким сервисом обычно происходит очень сложно, потому что передать информацию по сети – это очень дорогостоящая операция с точки зрения скорости. Поэтому если мы создаем сервис, нужно очень хорошо подумать, нужно ли это делать. И делать это только тогда, когда это реально необходимо.
Микросервис, по сути своей, - это сервис, который содержит очень мало кода.Код связан внутри сервиса по признаку того, что каждая функция делает что-то одно. То есть если есть, к примеру, приложение, занимающееся погодой, у нас может быть микросервис погоды. Если приложение занимается интернет-торговлей, у нас может быть микросервис Корзина товара. То есть микросервис - это компонент, код, в котором соединен по признаку одной функции.
Причины популярности микросервисов: миф или реальность?
Если микросервисы - это неважные архитектурные решения, то возникает вопрос, почему тогда они так популярны сейчас? Главная причина популярности заключается в том, что есть два заблуждения, касающиеся микросервисов. Первое - это то, что микросервисы независимы друг от друга. Возникает такое ощущение, что если микросервис, то есть компонент находится в своем адресном пространстве, на собственном сервере, то он полностью независим от всех остальных сервисов. Второе заблуждение в том, что каждый микросервис можно отдать собственной команде или каждому программисту в компании так, чтобы они могли работать над этими сервисами, никак не координируя действия друг с другом. Это на самом деле тоже миф и неправда. И сейчас мы разберемся, почему это не так.
Мнение, что микросервисы независимы - это заблуждение. К примеру, если микросервисы взаимодействуют с какой-то структурой данных, и программисту необходимо добавить поле в эту структуру данных, придется изменить каждый микросервис. Если есть 20 микросервисов, то нужно будет произвести 20 изменений в 20 микросервисах, что получается косвенно связывает их друг с другом.
Второе заблуждение заключается в том, что микросервис можно отдать команде разработчиков, чтобы каждая команда работала над каждым микросервисом отдельно. Это тоже неправда, потому что микросервисы очень сильно связаны друг с другом одной причиной для изменения. Почему? Потому что если мы делим код на маленькие компоненты, то в этом случае их пронизывает одна и та же причина для изменения. Система, которая разделена по функциональному признаку на маленькие компоненты, очень уязвима для сквозных задач, т.е. для задач, которые требуют изменения каждого микросервиса.
А это уже по сути - определение плохой архитектуры. Плохая архитектура – это та архитектура, которая требует на небольшую задачу изменить всю программу сразу. А хорошая архитектура – это та, которая вообще не требует изменять программу. Можно расширять её с помощью принципов полиморфизма, плагинов. И если это изменение и происходит, то происходит только в одном месте. Это - самый лучший, самый идеальный вариант для архитектуры. Это то, к чему мы стремимся, когда пишем хорошие программы. Это - известный принцип открытости системы.
Так что в итоге?
Антиподом микросервиса считается монолит. Монолит предполагает, что все компоненты программы находятся в одном адресном пространстве и выполняются на одном процессоре.
Но смысл деления монолита на микросервисы не в том, чтобы было проще и лучше писать код, а в том чтобы система лучше реагировала на повышающуюся нагрузку. И если вам нужен стабильно работающий сервис, то лучше обратиться к проверенным специалистам, например, в ICONICA.