Микросервисы на протяжении уже нескольких лет остаются одним из ведущих трендов разработки программного обеспечения. Сегодня предлагаем выяснить, зачем нужна такая архитектура и кому она подходит.
Увеличить
Что такое микросервисы
Микросервисная архитектура — это подход к разработке, согласно которому приложения и программные продукты строятся из разных слабо связанных друг с другом компонентов (то есть сервисов), поддерживающих независимое развертывание.
Компоненты, из которых строится продукт:
- имеют разные бизнес-функциональности;
- «общаются» друг с другом с помощью REST API, потоков событий и агентов сообщений;
- обладают своим стеком технологий, в том числе БД и моделью управления данными.
При этом конечный продукт, то есть само приложение на микросервисах, не имеет ограничений по масштабу. Оно может быть сложным и большим, а может быть и совсем скромным — все зависит от его задач и предполагаемой функциональности.
Микросервисы vs. монолиты
Как правило, приложениям на базе микросервисной архитектуры противопоставляются монолиты. Подробно мы сравнивали преимущества и недостатки обоих подходов в другой статье нашего блога. Сейчас же кратко пройдемся по отличиям архитектур.
Монолитные приложения изначально разрабатывались как цельные и неделимые. Конечно, они могут иметь модульную структуру (включать в себя разные Namespace, классы, объекты и прочее). Однако связь между этими компонентами так сильна, что изменения в одном непременно скажутся на работе программного продукта целиком.
Приложение с монолитной архитектурой — будто крепкая кирпичная стена. Несмотря на то, что она сделана из отдельных блоков, заменить какой-то отдельный кирпич просто так не получится. Связи между кирпичами так сильны, что, скорее всего, вам придется брать кувалду, рушить старую стену или ее часть, а затем строить все заново.
На практике это может выглядеть так.
Допустим, у вас есть интернет-магазин. Он состоит из:
- фронтенда (пользовательского интерфейса);
- бэкенда (серверной части, которая отвечает за обработку запросов);
- базы данных (БД).
Бизнес-функциональности интернет-магазина как приложения достаточно разнообразны:
- добавление/удаление карточек товаров;
- оплата и обработка заказов с их последующим отслеживанием;
- управление пользователями и так далее.
Увеличить
На application-уровне функциональности этого приложения будут выполняться в едином монолитном блоке. А при размещении интернет-магазина на стороне хостинг-провайдера весь код придется поместить на один сервер.
Это накладывает определенные ограничения:
- любое изменение в большинстве случаев потребует пересборки всего приложения;
- при выходе из строя одного модуля может перестать работать все приложение;
- масштабировать какой-то конкретный модуль отдельно не получится;
- выпуск новых релизов и обновлений замедляется, т.к. внесение изменений требует внимательного и разнопланового тестирования.
В ответ на недостатки монолитной архитектуры и появились микросервисы. Микросервисная архитектура предполагает, что приложение будет строиться как набор слабо связанных друг с другом компонентов. Каждый из них должен выполнять какую-то одну простую задачу и передавать результат своей работы другим сервисам.
Преимущества микросервисной архитектуры
Микросервисы предлагают новые возможности не только разработчикам, но и бизнесу. Рассмотрим их подробнее.
- Простое развертывание
- Повышение скорости обновлений
- Оптимизация масштабирования
- Повышение отказоустойчивости
- Отсутствие ограничений при разработке
- Повышение эффективности
- Повышение гибкости приложения
Так как все компоненты связаны друг с другом достаточно слабо, нет необходимости каждый раз разворачивать приложение целиком — только микросервисы, в которые были внесены какие-то изменения.
Когда есть возможность разворачивать отдельные компоненты и не тратить много времени на тестирование, скорость выпуска обновлений существенно повышается. А значит, вы можете быстрее доставлять пользователям новые возможности и совершенствовать продукт.
Ваше приложение развивается, пользовательская база растет и приходит время масштабироваться? Вы можете ограничиться лишь конкретными сервисами, которые нуждаются в «росте». Это намного ускоряет процесс и позволяет сэкономить на вычислительных ресурсах.
Если один из модулей микросервисного приложения сломается, вся остальная система продолжит работать. Для восстановления работоспособности на 100% придется только исправить ошибку или устранить сбой на «пострадавшем» модуле и, как вы уже знаете из предыдущего пункта, быстро обновить этот компонент.
При создании приложения с микросервисной архитектурой разработчики могут выбирать любые нужные технологии и формировать стэк.
Как правило, в разработке микросервисного приложения не участвует вся команда целиком. Разработчики разделяются на группы, за каждой из которых закрепляется некая функциональность приложения. Это значительно упрощает процесс управления и позволяет сократить time-to-market цифрового продукта.
Так как между сервисами нет сильных связей, можно без труда заменить какой-либо из компонентов. И сделать это в приложении с микросервисной архитектурой намного быстрее и проще, чем в монолите.
Недостатки микросервисов и способы их устранить
Помимо преимуществ, у микросервисов есть и недостатки.
- Распределенность системы
- минимизировать количество вызовов в приложении;
- внедрить асинхронные запросы — чем больше запросов удасться запараллелить, тем меньше будет время их выполнения.
- Повышение операционной сложности и требований к специалистам
- Необходимость постоянно поддерживать согласованность
Поскольку микросервисные приложения имеют распределенное устройство, разработчики могут столкнуться с такой проблемой, как снижение скорости вызовов и возникновение задержек. Один компонент может обращаться к десяти другим, а они, в свою очередь, к множеству третьих. Все это вкупе увеличивает риск отказов из-за увеличения времени отклика.
Как решить эту проблему:
Конечно, и тот, и другой метод требуют от разработчика определенного опыта и квалификации.
Чем больше сервисов задействовано в приложении, тем выше операционная сложность и важнее роль автоматизации. Кроме того, возрастает роль мониторинга, который нужно не только внедрить, но и грамотно настроить.
Решить эти проблемы поможет методология DevOps. Она поможет синхронизировать между собой команды разработки, тестирования, эксплуатации и других задействованных в создании приложения специалистов, вне зависимости от того, в каком этапе его жизненного цикла они участвуют.
Из-за децентрализации управления данными при разработке приложения с микросевисной архитектурой могут возникнуть проблемы с согласованностью. Например, монолитная архитектура допускает выполнение массы связанных изменений в рамках одной транзакции. Даже если случится откат, вы сможете быть уверены, что согласованность данных не потеряется.
А вот микросервисным приложениям для реализации цепочки изменений требуется несколько ресурсов, при этом распределенные транзакции не приветствуются. По этой причине вы можете столкнуться с ситуацией, когда один компонент перестанет отвечать, пока не завершится обновление другого.
В любом случае между согласованностью и доступностью стоит выбрать второе. Ведь намного лучше, когда работоспособность всех компонентов не «рушится» из-за сбоев на каком-то одном.
При разработке приложения всегда стоит помнить, что неоправданное внедрение микросервисной архитектуры способно свести на нет любые ее преимущества.
Как разрабатываются приложения с микросервисной архитектурой
Чтобы микросервисное приложение одинаково работало и на ПК разработчика, и в тестовой среде, и в продакшене, используют технологии контейнеризации. Контейнеры упрощают перенос микросервисных приложений в «боевую» среду и помогают исключить возникновение сюрпризов при развертывании.
Увеличить
Чем больше микросервисов в составе приложения, тем больше потребуется контейнеров для упаковки. Но мере увеличения их числа, растёт и сложность управления. Для решения этой проблемы придумали технологию Kubernetes.
Увеличить
Преимущества Kubernetes
Давайте посмотрим, какие возможности открывает Kubernetes перед компаниями, которые используют этот инструмент:
- Сокращение time-to-market
- Ускорение внедрения новых технологий
- Распределение вычислительных ресурсов в автоматическом режиме
Kubernetes позволяет централизованно управлять развернутыми контейнерами. Например, с его помощью буквально в один клик можно обновить конкретную часть приложения или же, наоборот, отменить изменение. Это позволяет сократить срок разработки цифровых продуктов, быстрее выпускать их на рынок и совершенствовать.
Используя Kubernetes, можно быстро переносить приложения в облачные среды и управлять ими одинаково эффективно как в облаке провайдера, так и на собственной площадке. Это актуально, когда приложение разрабатывается локально, а тестируется уже в виртуальной инфраструктуре. Также с K8s проще внедрять технологии машинного обучения (ML) и работать с большими данными (Big Data).
Когда нагрузка на приложение растет (например, из-за маркетинговых активностей или сезонных факторов), приходится масштабировать ресурсы. Если компания использует традиционную инфраструктуру, придется докупать и подключать новые серверы. Тем, кто живет в облаке, запрашивать дополнительные мощности у провайдера.
С Kubernetes этот процесс значительно упрощается. K8s умеет автоматически масштабировать ИТ-систему в зависимости от текущего уровня нагрузки и потребностей приложения. Даже если ваш продукт столкнется с внезапным наплывом пользовательских запросов, он практически мгновенно получит дополнительные мощности. В то же время, когда нагрузка снизится, сократится и объем выделенных для приложения ресурсов, а значит, вам не придется за них переплачивать.
