Close

Микросервисы и микросервисная архитектура

Узнайте о плюсах и минусах микросервисов и об их отличиях от монолитных решений.

Что такое микросервисы?

Термин «микрослужбы» используется для описания традиционной схемы «разделения интересов» в рамках распределенного сетевого проекта. Идея микрослужб берет свое начало в зрелой философии системы UNIX, основой которой являются «маленькие, но острые инструменты». Обе эти концепции основаны на еще одной фундаментальной модели информатики, называемой композицией, согласно которой сложные системы представляют собой совокупность составных сущностей более низкого уровня.

Статьи о микросервисах

[ПРОДОЛЖЕНИЕ]

Композиция используется на всех уровнях проекта по разработке ПО. На самом низком уровне, т. е. уровне модулей, отдельные независимые функции кода взаимодействуют друг с другом через общий интерфейс и создают таким образом коллекции, или библиотеки, кода. На уровне оболочки операционной системы можно сочетать команды оболочки и таким образом создавать конвейеры, обладающие функциональностью более высокого уровня. Микрослужбы — это уровень композиции, возникающей между веб-службами. Микрослужба — это веб-служба, отвечающая за один элемент логики в некой предметной области. Микрослужбы взаимодействуют друг с другом через простые сетевые протоколы, например REST, и совместно выполняют некоторые действия, но при этом ни одна из них не имеет сведений о внутреннем устройстве других служб. Такое согласованное взаимодействие между микрослужбами называется архитектурой микрослужб.

Архитектура микрослужб (MSA) позволяет командам, разрабатывающим программное обеспечение, оптимизировать рабочие процессы выпуска релизов. В число компаний, которые открыто выбирают этот метод разработки программного обеспечения, входят Amazon, Netflix и eBay. Стремясь внести свой вклад в работу сообщества, они поделились своим опытом и инструментами разработки, чтобы помочь другим внедрить данный метод.

Основной принцип микросервисной архитектуры — создание приложения путем разделения компонентов его бизнес-логики на небольшие сервисы, которые можно развертывать и использовать независимо друг от друга.

Схема, иллюстрирующая разделение большого куба на несколько кубов меньшего размера.

При таком подходе разработчики могут разделиться на небольшие команды и работать над разными службами, использовать разные стеки технологий и независимо выполнять развертывание. Такое разделение интересов и независимая эксплуатация позволяют использовать оптимизированные agile-подходы к разработке ПО, например непрерывную поставку и интеграцию.

Ориентированная на службы архитектура (SOA) или микрослужбы?

Ориентированная на службы архитектура (SOA) и микрослужбы — это две разновидности архитектуры более высокого порядка (архитектуры веб-служб). Микрослужбы можно назвать облегченной версией SOA. Разница между двумя типами архитектур заключается в формальной классификации типов служб. SOA включает четыре базовых типа служб: бизнес-службы, корпоративные службы, службы приложений и инфраструктурные службы. В соответствии с типом службы определяется ее ответственность, связанная с конкретной областью. В свою очередь, архитектура микрослужб включает лишь два типа служб: функциональные и инфраструктурные.

В обеих архитектурах используется один и тот же набор стандартов, действующих на разных уровнях компании. Модель MSA обязана своим существованием успеху модели SOA. Следовательно, модель MSA является подмножеством модели SOA. В ней основное внимание уделяется автономному выполнению каждого сервиса.

Монолитное приложение или микрослужбы?

Схема, показывающая разницу между монолитными приложениями и микросервисами с непрерывной поставкой.

Микрослужбы разделяют крупные задачи, характерные для конкретного бизнеса, на несколько независимых баз кода. Монолитная архитектура приложений является противоположностью микрослужб. Монолит — это единая база кода, в которой объединены все бизнес-задачи. Использовать монолиты удобно на начальных этапах проектов для сокращения умственных усилий по управлению кодом и облегчения развертывания. Это позволяет сразу выпускать все, что есть в монолитном приложении.

Многие проекты начинаются как монолитные, а затем, по мере развития, переходят к архитектуре микрослужб. По мере добавления в монолитный проект новых возможностей рано или поздно возникают сложности при работе нескольких разработчиков с единой базой кода. Учащаются конфликты в коде и увеличивается риск того, что при обновлении одной возможности появятся баги в другой, несвязанной возможности. Если такие нежелательные ситуации возникают, возможно, настало время обсудить переход на микрослужбы.

Как работает микросервисная архитектура

Давайте в качестве примера рассмотрим гипотетический проект разработки программного обеспечения для электронной коммерции. В этой сфере существуют некоторые четко определенные области. Сайты электронной коммерции имеют систему аутентификации для входа пользователей в систему и выхода из нее. Предусмотрена также корзина для сохранения списка товаров, заинтересовавших пользователя. Биллинговая система позволяет пользователям оплачивать свои покупки.

В архитектуре микрослужб указанным областям соответствовали бы независимые службы. В качестве конкретного примера можно привести биллинговую систему. При условии достаточного большого числа сотрудников в компании может быть сформирована «биллинговая команда», которая отвечает за разработку и контроль качества этой биллинговой микрослужбы. Для биллинговой микрослужбы составлялись бы графики релизов и планы развертывания. Для биллинговой службы также был бы создан задокументированный API с поддержкой разных версий, чтобы службы могли подключаться к ней и использовать ее функциональные возможности.

Плюсы и минусы микрослужб

+ Горизонтальное масштабирование

Микрослужбы являются изначально распределенными, их развертывание можно выполнять в кластерах. Это позволяет осуществлять динамическое горизонтальное масштабирование за пределы границ служб. Когда микрослужба достигает предельной нагрузки, можно быстро выполнить развертывание новых экземпляров данной службы в сопутствующем кластере.

+ Независимая работа команд

Команды, ответственные за микросервисы, могут работать независимо от других функциональных команд в организации. Это обеспечивает условия для ускоренной реализации и поставки новых функциональных возможностей.

+ Более пристальное внимание к качеству

При разделении бизнес-задач по независимым микросервисам команда, владеющая каждым сервисом, будет ориентирована на результат высшего качества.

- Экспоненциально растущие расходы на инфраструктуру

Каждый новый микросервис, развертываемый организацией в рабочей среде, предполагает отдельные расходы на комплект тестов, инструкции по развертыванию, инфраструктуру хостинга, инструменты мониторинга и т. д.

- Дополнительные организационные расходы

Для координации обновлений и интерфейсов необходим дополнительный уровень коммуникации и совместной работы между командами, разрабатывающими архитектуру микросервисов.

- Сложность среды разработки

Разделение проекта на множество микросервисов создает дополнительную проблему воспроизведения распределенной архитектуры во время настройки локальной разработки.

Будущее микрослужб

Контейнеризация и развертывание контейнеров — это новая модель распределенной инфраструктуры. Чтобы упаковать службу в полноценный контейнер, для которого развертывание и отключение выполняются очень быстро, применяются такие инструменты, как Docker и Kubernetes. Эти новые инфраструктурные инструменты дополняют архитектуру микрослужб. Микрослужбы можно помещать в контейнеры и легко развертывать, а также управлять ими с помощью системы управления контейнерами.

К процессу внедрения микросервисов нужно относиться скорее как к долгому путешествию, а не как к ближайшей цели команды. Начините с малого, чтобы понять технические требования распределенной системы, каким образом можно элегантно исправлять ошибки и как масштабировать отдельные компоненты. После этого, по мере накопления опыта и знаний, вы сможете постепенно использовать все больше и больше сервисов.

Микросервисная архитектура — методика довольно новая, но она представляет собой перспективный способ разработки приложений, на который обязательно стоит обратить внимание. При этом, однако, следует помнить, что она может (пока) не подходить вашей команде.

Claire Maynard
Claire Maynard

Клэр — опытный специалист по маркетингу, которая за время своей карьеры в Atlassian успела поработать в различных направлениях, включая growth-маркетинг, performance-маркетинг и маркетинг продуктов. В настоящее время она отвечает за стратегию бренда компании, контент-стратегию и стратегию вывода продукции на рынок для продуктов Confluence Cloud. На досуге Клэр любит кататься на волнах, заниматься бегом и пробовать что-нибудь новенькое в еще неизведанных ресторанах Сан-Франциско и других городах по всему миру.

продолжение темы
3 Secrets to Building Microservices