Микросервисы используются для разделения бизнес-процессов на отдельные части или услуги, которые можно проектировать, улучшать и масштабировать независимо. Это стиль архитектуры информационных систем, который возник, когда цифровые амбиции начали опережать возможности монолитных, жестких, универсальных программных платформ.
За последнее десятилетие этот подход приобрел большую популярность: согласно опросу разработчиков Stack Overflow, проведенному в 2023 году, 49% разработчиков теперь работают с микросервисами в своих организациях.
Микросервисы стали особенно популярным вариантом для создания масштабируемых систем электронной коммерции и поддержки композитных стеков технологий, которые позволяют компаниям смешивать и сопоставлять возможности различных лучших в своем классе инструментов вместо того, чтобы ограничиваться негибким набором функций одного и того же инструмента единого поставщика программного обеспечения.
Что такое микросервис
Допустим, у вас есть бизнес по производству скворечников. Изготовление каждого дома состоит из четырех шагов: принять заказ, распилить дерево, построить домик, покрасить домик.
Сначала вы нанимаете одного человека для выполнения всех четырех шагов, и это работает невероятно эффективно. По мере того, как бизнес начинает расти, вы просто расширяете производство скворечников, нанимая небольшую команду, где каждый человек отвечает за весь процесс.
Затем все начинает усложняться. Клиентам нужны скворечники разных размеров и форм, вы находите более эффективный способ распиловки древесины или хранения инструментов, на рынке появляются новые краски, но обновление процесса с целью включения этих новых вещей означает переподготовку всей команды.
Вы собираете все обновления, и вводите команду в курс дела. Изменение процесса становится настолько хлопотным, что вы начинаете довольствоваться «достаточно хорошими» скворечниками, а когда у вас возникают идеи относительно модификаций продукта, таких как кормушки для птиц или купальни для птиц, мысль о расширении возможностей настолько устрашает, что вы никогда даже не захотите расшириться.
Но есть другой подход — специализация и разделение труда. Вы решаете разбить процесс на эти четыре отдельных операции. Вы назначаете разных людей на отдельные этапы:
- принимать заказы,
- готовить материалы,
- сделать домик,
- красить домик .
Каждый человек может работать автономно: человек, принимающий заказ, может просто объявить об этом, и ему не нужно ждать ответа лесоруба, прежде чем принять следующий заказ, плотник может построить домик, не зная, как его покрасить, а маляр будет просто красить уже готовый скворечник.
Такое разделение также означает, что каждый человек может постоянно вносить небольшие улучшения в свои методы работы, не мешая остальным, поэтому больше нет необходимости закрывать магазин для обучения всей команды. Это также означает, что вы можете более точно масштабировать производство: например, чтобы изготавливать 100 скворечников в день, вам может понадобиться только один человек, который будет принимать заказы, а четыре человека будут рисовать.
Другими словами, каждый микросервис — это:
- Автономность: служба может использовать логику, язык программирования и хранилище данных, которые подходят для задачи. API используются для стандартизации передачи информации между службами;
- Независимое развертывание: изменения в одной службе не повлияют на логику другой. Сервисы можно обновлять непрерывно и параллельно, не рискуя вызвать каскад ошибок во всей системе;
- Индивидуальное масштабирование: ресурсы можно предоставлять только тем службам, которые в них нуждаются, что позволяет применять более точные стратегии масштабирования.
Микросервисы против модульной и монолитной архитектуры
Монолитная архитектура
В монолитном приложении все процессы и возможности сильно зависят друг от друга благодаря общему языку, логике и базе данных. Из-за этой зависимости изменение в одной части системы может иметь непредвиденные последствия в другой части системы, поэтому обновления обычно выполняются большими пакетами, что приводит к созданию различных версий приложения.
Небольшие приложения с простыми процессами прекрасно работают как монолит. Компании начинают сталкиваться с проблемами, когда монолит находится в основе ключевой части бизнеса, такой как цифровой опыт, и со временем накапливается неуклюжие расширения и «одноразовые» обходные пути, которые делают монолит дорогим в поддержке и трудным в адаптации к новым требованиям клиентов.
Микросервисная архитектура
Архитектура микросервисов находится на другом конце спектра зависимостей, где программное обеспечение спроектировано как набор небольших сервисов, каждый из которых отвечает за отдельную часть бизнес-функциональности, такую как оформление заказа, складской учёт, блог или даже части внешнего интерфейса. Каждый микросервис отвечает за свои процессы, базу данных и API. Изменения можно вносить в один микросервис, не нарушая работу других, при условии, что он по-прежнему обменивается данными согласованным образом, поэтому обновления могут происходить по мере поступления без управления версиями.
В микросервисной архитектуре структура команды так же важна, как и технология. Обычно каждый микросервис принадлежит специализированной межфункциональной команде, которая отвечает за разработку, поддержку и постоянное улучшение сервиса.
Модульная архитектура
Модульную архитектуру и микросервисную архитектуру иногда можно воспринимать как одно и то же, но хотя микросервисы обычно являются ключевым компонентом составного подхода, они не являются единственным типом используемого решения. Модульность — это идея создания технологического стека инструментов, наиболее подходящих для различных областей бизнеса, и подключения их через API, чтобы решения можно было легко добавлять, изменять и удалять по мере необходимости.
Полностью микросервисная архитектура может быть конечной целью модульной архитектуры для некоторых организаций, но большинство компонуемых архитектур будут представлять собой смесь собственных сервисов, решений поставщиков, построенных на принципах MACH (микросервисы, API-интерфейс, облачный доступ, безголовые), и даже некоторые приложений, которые лучше оставить монолитом.
Когда и как использовать архитектуру на основе микросервисов
Не существует четких указаний о том, когда компании следует переходить на микросервисы. Даже Сэм Ньюман, автор определяющей книги о микросервисах, не имеет однозначного ответа.
Микросервисы могут принести много преимуществ, но также могут и усложнить работу. Поэтому их внедряют только в том случае, если этот подход может обеспечить необходимый бизнес-результат. Некоторые общие бизнес-факторы включают в себя:
- Когда вам нужно, чтобы ваше решение развивалось быстро и независимо: микросервисы обладают гибкостью, позволяющей адаптироваться к меняющимся требованиям клиентов, разнообразным внутренним потребностям и поворотам бизнеса. Сервисы могут быть составлены по-разному, чтобы быстро реализовать новые идеи, и они упрощают создание гибкого технологического стека, позволяющего заменять и отключать инструменты по мере изменения потребностей бизнеса;
- Когда вам нужна высокая доступность: микросервисы поддерживают подход непрерывной разработки (CI/CD) и не требуют простоя для обновлений. С помощью небольших сервисов, которые можно развернуть независимо, вы уменьшаете «радиус взрыва» любых ошибок.
- Когда вам нужно изолировать данные: поскольку каждый микросервис владеет собственной базой данных, появляется больше гибкости в разделении данных и процессов, которые с ними связаны. Это может быть особенно полезно для соблюдения корпоративных стандартов;
- Когда вам нужно задействовать автономные команды: когда большие команды работают над сложными монолитами, необходимы огромные усилия по координации, чтобы внести даже самые незначительные изменения. Если команды уже внедряют DevOps, но их сдерживают устаревшие технологии, микросервисы могут позволить командам быстро принимать решения для своей области и двигаться в том темпе, к которому они готовы.
Более того, «когда» внедрять микросервисы и «как» это делать определяется в каждом конкретном случае. Вот некоторые ведущие голоса в сфере микросервисов, говорящие о ключевых сценариях, которые организациям следует учитывать при переходе:
- Как начать работу с микросервисами: Мартин Фаулер, Microservices (видео);
- Как организовать команды для поддержки микросервисов: Джеймс Льюис, Архитектура программного обеспечения, топологии команд и наука о сложности (видео);
- Как перейти от монолита к микросервису: Сэм Ньюман, Шаблоны декомпозиции монолита (видео);
- Как настроить связь между микросервисами: Крис Ричардсон, Not Just Events: Developing Asynchronous Microservices (видео).
Микросервисная структура платформы дает предприятиям гибкость в использовании разнообразных платформ различными способами. Компании могут использовать модели структурированных данных для объединения данных из своего коммерческого стека в богатый контент, легче интегрировать его с другими решениями или платформами.
Перестаньте позволять ограничениям вашего устаревшего монолита определять качество обслуживания клиентов и начните создавать технологический стек, отвечающий цифровым амбициям вашего бизнеса.
