Микросервисы и микросервисная архитектура
Узнайте о плюсах и минусах микросервисов и об их отличиях от монолитных решений.
Еще недавно программные приложения создавались преимущественно на базе монолитной архитектуры, где каждое приложение представляет собой самостоятельную единицу. Такой подход приносил пользу многим командам разработчиков до тех пор, пока приложения не становились слишком сложными. Чтобы изменить небольшой участок кода в монолитной системе, приходится заново собирать всю систему, тестировать ее и развертывать новую версию приложения.
Затем появились микросервисы. С ними программные системы разбиваются на небольшие элементы, которые можно разрабатывать и развертывать независимо друг от друга. Микросервисная архитектура развивалась при поддержке приверженцев DevOps, которым требовалась быстрая поставка обновлений — новых возможностей, исправлений багов и улучшений безопасности. Кроме того, с такой архитектурой многие компании могли переписать устаревшие приложения с использованием современных языков программирования и обновленного стека технологий.
Микросервисы — это набор небольших модулей, на основе которых выполняется непрерывная поставка и развертывание больших и сложных приложений.
Что такое микросервисы?
Микросервисная архитектура (или просто «микросервисы») — это подход к созданию приложения в виде набора независимо развертываемых сервисов, которые являются децентрализованными и разрабатываются независимо друг от друга. Эти сервисы слабо связаны, независимо развертываются и легко обслуживаются. Монолитное приложение создается как единое и неделимое целое, тогда как в микросервисной архитектуре его разбивают на множество независимых модулей, каждый из которых вносит свой вклад в общее дело. Микросервисы неразрывно связаны с DevOps, поскольку лежат в основе методики непрерывной поставки, благодаря которой команды могут быстро адаптироваться к требованиям пользователей.
Микросервис — это веб-сервис, отвечающий за один элемент логики в определенной предметной области. Приложение создают как комбинацию микросервисов, каждый из которых предоставляет функциональные возможности в своей предметной области. Микросервисы взаимодействуют друг с другом через API-интерфейсы, такие как REST или gRPC, но не обладают информацией о внутреннем устройстве других сервисов. Такое согласованное взаимодействие между микросервисами называется микросервисной архитектурой.
При использовании микросервисной архитектуры разработчики могут разделиться на небольшие команды, которые будут работать над разными сервисами, использовать разные стеки и независимо выполнять развертывания. Например, в основе Jira лежит множество микросервисов, каждый из которых предоставляет определенные возможности: поиск задач, просмотр сведений о задачах, комментирование, изменение состояния задач и многое другое.
Характеристики микросервисной архитектуры
У микросервисной архитектуры нет формального определения, но есть некоторые общие особенности (или характеристики), о которых важно знать.
Автономные компоненты
Основным структурным элементом микросервисной архитектуры является компонент. Это может быть пакет ПО, веб-сервис, ресурс, приложение или модуль, содержащий несколько взаимосвязанных функций. Проще говоря, как объяснил Мартин Фаулер, «программные компоненты — это вещи, которые можно заменять и обновлять независимо друг от друга».
В микросервисной архитектуре каждый компонент можно разрабатывать, развертывать, эксплуатировать, изменять и развертывать повторно, не нарушая работу других сервисов и целостность приложения.
Компоненты используются совместно для качественного обслуживания клиентов или поставки ценных продуктов. Наиболее распространенными компонентами являются сервисы и библиотеки, однако в качестве компонентов могут также выступать инструменты командной строки, мобильные приложения, интерфейсные модули, конвейеры данных, модели машинного обучения и многие другие концепты, применимые в микросервисной архитектуре.
Четкие и понятные интерфейсы
После создания отдельных компонентов потребуется значительный объем логики, чтобы обеспечить их взаимодействие в рамках выбранного механизма (например, RPC, REST через HTTP или система, управляемая событиями). В микросервисной архитектуре в качестве таких механизмов могут использоваться синхронные или асинхронные методы либо комбинация таких методов.
Важнее всего, чтобы у каждого микросервиса был четкий и понятный контракт, в котором описан способ его использования клиентом. Обычно для этих целей используют API-интерфейс, который публикуется вместе с сервисом.
Кто разработал, тот и поддерживает
Принцип DevOps «кто разработал, тот и поддерживает» подчеркивает, что микросервисную архитектуру можно внедрить только при наличии продуманной структуры команд. DevOps изменяет мотивацию всех функциональных ролей — разработчиков, специалистов по контролю качества, а также инженеров по релизам и эксплуатации — и делает их частью единой команды, в которой все участники стремятся создавать высококачественное ПО. Методики DevOps, такие как CI/CD, автоматизированное тестирование и флажки возможностей, ускоряют развертывание и помогают поддерживать стабильность и безопасность системы. Кроме того, каждая команда может создавать и развертывать свои микросервисы, не мешая работе других команд.
Благодаря развитию облачных технологий стало проще создавать и развертывать микросервисы, а также работать с ними. Команды могут облегчить работу с помощью таких методов автоматизации инфраструктуры, как непрерывная интеграция, непрерывная поставка и автоматизированное тестирование.
Сравнение сервис-ориентированной и микросервисной архитектуры
Сервис-ориентированная архитектура (SOA) и микросервисная архитектура — это две разновидности архитектуры веб-сервисов. Подобно микросервисной архитектуре, SOA состоит из многократно используемых специализированных компонентов, которые работают независимо друг от друга. Разница между этими двумя типами архитектур заключается в формальной классификации типов сервисов.
В рамках SOA выделяют четыре основных типа сервисов:
- Business
- Enterprise
- Приложение
- Инфраструктурные сервисы
От типа сервиса зависит его сфера ответственности в конкретной предметной области. Для сравнения: в архитектуре микросервисов есть лишь два типа сервисов — функциональные и инфраструктурные.
В обеих архитектурах используется один и тот же набор стандартов, действующих на разных уровнях компании. Микросервисная архитектура возникла благодаря успеху модели SOA, поэтому можно сказать, что такая архитектура является подмножеством данной модели. В ней основное внимание уделяется независимой работе каждого сервиса.
Преимущества микросервисной архитектуры
Agility
Сервисы в микросервисной архитектуре обычно создаются небольшими независимыми командами, поэтому такая архитектура побуждает команды внедрять методы agile. Команды получают возможность работать независимо и быстро двигаться вперед, в результате чего сокращаются циклы разработки.
Гибкое масштабирование
Поскольку микросервисы изначально являются распределенными и могут развертываться в кластерах, становится возможным динамическое горизонтальное масштабирование через границы сервисов. Если нагрузка на микросервис достигает предела, можно быстро развернуть новые экземпляры этого сервиса в сопутствующем кластере и таким образом снизить нагрузку.
Частые релизы
Одним из основных преимуществ микросервисной архитектуры являются частые и быстрые циклы релизов. Благодаря микросервисной архитектуре, которая выступает ключевым элементом непрерывной интеграции и непрерывной поставки (CI/CD), команды могут экспериментировать с новыми возможностями, а если что-то пойдет не так — выполнить откат и вернуться к предыдущей версии. Это упрощает обновление кода и ускоряет вывод новых возможностей на рынок.
Гибкая технология
При использовании микросервисной архитектуры от команд не требуют строго следовать определенному подходу и работать с одним пакетом инструментов. Они могут свободно выбирать ПО с учетом своих предпочтений.
Ориентация на качество
Когда бизнес-задачи разделены между независимыми микросервисами, команда, владеющая каждым сервисом, сосредоточена на качестве конечного результата.
Высокая надежность
В рамках микросервисной архитектуры функциональные возможности работают отдельно друг от друга, благодаря чему снижается риск отказа всего приложения или базы кода при выпуске обновлений. Кроме того, в отдельных сервисах легче искать и исправлять ошибки и баги. С таким подходом повышается надежность, поскольку можно развернуть изменения в одном конкретном сервисе, не нарушая работу всего приложения.
Проблемы микросервисной архитектуры
Разрастание процесса разработки
Переход от монолитной архитектуры к микросервисной усложняет работу. Повсюду появляется больше сервисов, созданных разными командами. Иногда бывает сложно определить, как различные компоненты связаны друг с другом, кто владеет конкретным компонентом и как избежать негативного воздействия на работу зависимых компонентов. Если разрастание не контролируется, оно приводит к замедлению разработки и снижению операционной эффективности. По мере роста системы возникает потребность в опытной команде по эксплуатации, которая будет управлять постоянными повторными развертываниями и частыми изменениями в архитектуре.
Неопределенность в вопросах владения
Микросервисная архитектура вносит путаницу в вопросы владения. Команда DevOps может использовать комбинацию API-интерфейсов, библиотек компонентов, инструментов мониторинга и образов Docker, чтобы пользователи могли развернуть приложение. Важно быть в курсе текущей ситуации по компонентам, включая их владельцев, ресурсы и меняющиеся отношения между другими компонентами. Нужно обеспечить четкое взаимодействие и координацию между многочисленными командами, чтобы каждый участник мог легко найти необходимые знания и разобраться в работе продукта.
Экспоненциальный рост расходов на инфраструктуру
Каждый новый микросервис, развертываемый в рабочей среде, создает дополнительные расходы на комплект тестов, планы развертывания, инфраструктуру хостинга, инструменты мониторинга и т. д.
Дополнительные организационные расходы
Для координации обновлений и интерфейсов необходим дополнительный уровень взаимодействия и совместной работы команд, разрабатывающих микросервисную архитектуру.
Отладка
Отладка приложения со множеством микросервисов, каждый из которых имеет собственный набор журналов, может оказаться сложной задачей. Кроме того, отладка дополнительно осложняется за счет того, что один бизнес-процесс может выполняться на нескольких машинах в разное время.
Реагирование на инциденты
Важно иметь оперативную информацию о реагировании на инциденты в микросервисах, в том числе о том, кто использует микросервис, где и как он был развернут и к кому обращаться при нештатных ситуациях.
Микросервисы и DevOps — одного поля ягоды
Учитывая повышенную сложность и зависимости между микросервисами, методы DevOps при развертывании, мониторинге и автоматизации управления жизненным циклом становятся неотъемлемой частью микросервисных архитектур. Поэтому микросервисную архитектуру часто считают первым шагом к внедрению культуры DevOps, которая дает следующие преимущества:
- Автоматизация
- Улучшенная масштабируемость
- Управляемость
- Agility
- Ускоренная поставка и развертывание
Ключевые технологии и инструменты для микросервисной архитектуры
Контейнеры, Docker и Kubernetes
Контейнер — это просто упаковка для приложения и всех его зависимостей, которую можно легко и согласованно развернуть. Контейнеры не предполагают накладных расходов на собственную операционную систему, поэтому они меньше по размеру и «легче», чем традиционные виртуальные машины. Их можно быстро развернуть и свернуть, так что они идеально подходят для небольших сервисов, характерных для микросервисных архитектур.
В связи с распространением сервисов и контейнеров возникла необходимость в оркестрации больших групп контейнеров и управлении ими. Docker — это популярная платформа контейнеризации и среда выполнения, с помощью которой разработчики могут создавать, развертывать и запускать контейнеры. Однако с помощью только лишь Docker сложно запускать контейнеры и управлять ими в большом масштабе. Решить проблему контейнеризации при любом масштабе помогают Kubernetes и другие решения: Docker Swarm, Mesos, HashiCorp Nomad и др.
Контейнеризация и развертывание контейнеров — это новая модель распределенной инфраструктуры. С помощью Docker и Kubernetes сервис упаковывают в полнофункциональный контейнер, который можно быстро развернуть или удалить. Эти инфраструктурные инструменты дополняют микросервисную архитектуру. Микросервисы можно помещать в контейнеры, без труда развертывать, а также управлять ими с помощью системы управления контейнерами.
API-шлюзы
В микросервисной архитектуре отдельные сервисы взаимодействуют друг с другом с помощью четко определенных API-интерфейсов. API-шлюз действует как обратный прокси-сервер: он принимает вызовы API-интерфейсов, собирает сервисы для их выполнения и возвращает результаты. API-шлюзы обеспечивают абстракцию в виде единой конечной точки API, даже если API-интерфейсы обслуживаются несколькими микросервисами. Кроме того, с помощью API-шлюзов можно объединить такие задачи, как ограничение скорости, мониторинг, аутентификация, авторизация и маршрутизация к соответствующему микросервису.
Обмен сообщениями и потоковая передача событий
Микросервисы по своей природе являются распределенными, поэтому командам требуются средства для обмена информацией об изменениях состояния и других событиях. Через систему обмена сообщениями можно передавать информацию между микросервисами, благодаря чему отдельные микросервисы могут обрабатывать события в рамках своего основного интерфейса. Например, при изменении страницы Confluence возникает событие, которое запускает переиндексацию поиска и отправку уведомлений пользователям, отслеживающим эту страницу.
Ведение журналов и мониторинг
С микросервисной архитектурой становится сложнее выявлять и решать проблемы в рамках нескольких сервисов. Вот почему важно иметь инструменты наблюдения для ведения журналов, мониторинга и трассировки. Они помогают понять поведение микросервисов, а также выявить потенциальные проблемы, неисправности и ошибки отладки.
Непрерывная интеграция и непрерывная поставка
Одним из основных преимуществ микросервисной архитектуры являются частые и быстрые циклы релизов. Благодаря микросервисной архитектуре, которая выступает ключевым элементом CI/CD, команды могут экспериментировать с новыми возможностями, а если что-то пойдет не так — выполнить откат и вернуться к предыдущей версии. Это упрощает обновление кода и ускоряет вывод новых возможностей на рынок.
Портал разработчиков
Поскольку сложность распределенных архитектур растет, командам разработчиков может пригодиться инструмент, который объединяет сведения о совместной работе команд и результатах разработки в одном центре. Так, решение Atlassian Compass было разработано, чтобы помочь командам побороть разрастание микросервисов путем распространения данных и аналитики по всему пакету инструментов DevOps.
Будущее микросервисов
Контейнеризация и развертывание контейнеров стали общепринятой моделью распределенной инфраструктуры. Чтобы упаковать сервис в полноценный контейнер, который можно быстро развернуть или удалить, применяются такие инструменты, как Docker и Kubernetes. Эти инфраструктурные инструменты дополняют микросервисную архитектуру, поскольку позволяют помещать микросервисы в контейнеры, легко развертывать их, а также управлять ими с помощью системы управления контейнерами.
К процессу внедрения микросервисов нужно относиться скорее как к долгому путешествию, а не как к ближайшей цели команды.
Начните с малого, чтобы понять технические требования распределенной системы и определить, как можно масштабировать отдельные компоненты. Затем постепенно выделяйте больше сервисов по мере накопления опыта и знаний.
Навигация по микросервисам с помощью Compass
При работе с микросервисной архитектурой можно использовать Atlassian Compass для управления сложностью масштабируемой распределенной архитектуры. Это расширяемая платформа для разработчиков, которая объединяет разрозненные сведения о совместной работе команд и результатах разработки в одном центре с возможностью поиска. Решение Compass поддержит вас в борьбе с разрастанием микросервисов благодаря каталогу компонентов. Кроме того, с его помощью можно внедрить рекомендации, оценить работоспособность программного обеспечения по картам оценки, а также распространить данные и аналитику по всему пакету инструментов DevOps с помощью расширений на платформе Atlassian Forge.
