Закрыть

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Плюсы и минусы микросервисов

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

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

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

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

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

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

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

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

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

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

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

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

Будущее микросервисов

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

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

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

Клэр Мейнард
Клэр Мейнард

Клэр Мейнард — руководитель отдела маркетинга продукта подразделения Bitbucket Cloud в Atlassian. Она работает в сфере разработки ПО более семи лет, а последние четыре года — в составе Atlassian. Помогая Atlassian рассказывать интересные истории о своих продуктах, она привлекает новых клиентов и поддерживает лояльность существующих. В свободное время Клэр любит путешествовать, заниматься серфингом и посещать новые рестораны.

продолжение темы
Создание микросервисов