Микросервисы

menu icon

Микросервисы

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

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

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

  • имеют собственный стек технологий, включая базу данных и модель управления данными;
  • взаимодействуют между собой посредством REST API, потоков событий и агентов сообщений;
  • изолированы по бизнес-функциям с помощью ограниченного контекста.

Несмотря на то что обсуждения часто сводятся к определениям и характеристикам архитектуры, ценность микросервисов можно легко определить по следующим коммерческим и организационным преимуществам:

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

Чтобы лучше понять, что такое микросервисы, важно разобраться, чем они не являются. Чаще всего микросервисную архитектуру сравнивают с монолитной архитектурой и сервис-ориентированной архитектурой (SOA).

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

Более подробно об отличиях между микросервисами и монолитной архитектурой рассказывается в следующем видеоролике (6:37):

 

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

Более подробная информация приведена в публикации «SOA и микросервисы: в чем отличия?».

Преимущества микросервисов для организации

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

Другими словами, архитектурная модель на основе микросервисов облегчает реализацию требуемой операционной модели. Согласно недавнему опросу, проведенному IBM среди 1200 разработчиков и ИТ-руководителей, 87% пользователей микросервисов согласны с тем, что этот подход стоит того, чтобы инвестировать в него время и средства. Дополнительная информация о преимуществах и сложностях микросервисов представлена на следующем интерактивном изображении:

(Источник: «Микросервисы на предприятии: реальные преимущества, превосходящие усилия», 2021 г.)

Вот лишь несколько примеров преимуществ микросервисов для предприятий.

Независимое развертывание

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

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

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

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

Оптимальный инструмент для работы

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

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

Точное масштабирование

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

Но есть и трудности

Обладая ощутимыми преимуществами, микросервисы также требуют решения сложных задач. Переход от монолитного приложения к микросервисам добавляет сложности к процессам управления вследствие роста количества сервисов, команд и сред развертывания. Проблемы с одним сервисом могут распространиться на другие сервисы. Для мониторинга и устранения неполадок необходимо регистрировать огромные объемы данных и согласовывать процессы ведения журналов на уровне сервисов. Появление новых версий может привести к проблемам совместимости с предыдущими версиями. Поскольку приложения используют больше сетевых соединений, появляется риск увеличения времени отклика и проблем связи. Принцип DevOps (как будет сказано ниже) позволяет решить многие из этих проблем, однако внедрение DevOps также сопряжено с определенными трудностями.

Тем не менее, ни одна из этих причин не останавливает энтузиастов от внедрения микросервисов или расширения их использования. Согласно данным нового опроса IBM, 56% организаций, не использующих микросервисы, с высокой или очень высокой вероятностью планируют внедрение микросервисов в ближайшие два года. При этом 78% организаций, которые уже используют микросервисы, планируют вкладывать больше времени, денег и усилий в развитие микросервисов (см. Рис. 1).

Три круговые диаграммы с результатами 56%, 78% и 59%

Рис. 1: Микросервисы — всерьез и надолго. В течение ближайших двух лет 56% организаций планируют внедрение микросервисов; 78% организаций, которые уже используют микросервисы, планируют вкладывать еще больше средств в развитие микросервисов; 59% всех приложений будут создаваться на основе микросервисов. (Источник: «Микросервисы на предприятии: реальные преимущества, превосходящие усилия», 2021 г.)

Микросервисы и DevOps нуждаются друг в друге

Говоря о микросервисной архитектуре, обычно упоминают, что она оптимизирована для DevOps и стратегии непрерывной интеграции и доставки (CI/CD), в контексте высокой частоты развертывания небольших сервисов.

Если же взглянуть на взаимосвязи между микросервисами и DevOps под другим углом, то на самом деле DevOps — необходимое условие для успешной реализации микросервисной архитектуры. Несмотря на отмеченные выше недостатки монолитных приложений, к их преимуществам относится отсутствие сложной распределенной системы с множеством динамичных компонентов и независимых стеков технологий. Учитывая же значительный рост сложности, динамичные компоненты и зависимости, характерные для микросервисов, было бы недальновидно обойти вниманием необходимость инвестиций в инструменты автоматизации развертывания, мониторинга и управления жизненным циклом.

Андреа Кроуфорд помогает детальнее разобраться с DevOps в следующем видеоролике:

Опорные технологии и инструменты

Несмотря на то что микросервисная архитектура поддерживает практически любой современный инструмент или язык, существует также ряд базовых инструментов, которые стали важнейшим определяющим элементом микросервисов:

Контейнеры, Docker и Kubernetes

Одной из ключевых идей микросервисов является их небольшой размер (стоит отметить, что число строк в «микросервисе» ничем не стандартизировано и приставка «микро» — всего лишь часть названия).

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

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

В видеоролике «Kubernetes в деталях» Сай Веннам подробно рассказывает обо всех тонкостях Kubernetes:

 

Шлюзы API

Микросервисы часто взаимодействуют между собой посредством API, в особенно при первоначальной установке состояния. Несмотря на возможность непосредственного обмена данными между клиентами и сервисами, шлюзы API часто выполняют роль важного промежуточного уровня, особенно с увеличением количества сервисов в составе приложения. Шлюз API предоставляет обратный прокси для клиентов, обеспечивая маршрутизацию запросов, разветвление запросов по нескольким сервисам и дополнительные средства защиты и идентификации.

Для реализации шлюзов API можно использовать различные технологии, включая платформы управления API. Однако если микросервисная архитектура основана на контейнерах и Kubernetes, то в качестве шлюза обычно применяется Ingress или, с недавнего времени, Istio.

Обмен сообщениями и потоки событий

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

Вместо этого необходимо объединить вызовы API для установки состояния с системой обмена сообщениям или потоками событий, чтобы сервисы могли транслировать изменения состояния, а другие компоненты отслеживать такие изменения и вносить необходимые коррективы. С этой задачей лучше всего справляется агент сообщений общего назначения, однако в некоторых случаях оптимальным выбором может оказаться платформа потоковой обработки событий, например Apache Kafka. Объединив микросервисы с архитектурой на основе событий, разработчики могут создавать легко масштабируемые, отказоустойчивые и расширяемые системы, способные принимать и обрабатывать очень большое количество событий или информации в режиме реального времени.

Бессерверные решения

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

Общим для бессерверных архитектур и платформ FaaS («функция как услуга») с одной стороны и микросервисов с другой стороны является выгода от создания более мелких единиц развертывания и точное масштабирование по запросу.

Микросервисы и облачные услуги

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

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

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

Базовые паттерны

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

  • Паттерн взаимодействия между клиентскими и серверными компонентами (BFF): этот паттерн добавляет уровень между пользовательским интерфейсом и используемыми ресурсами. Например, приложения для ПК и мобильных устройств будут иметь разные характеристики размера экрана, отображения и производительности. С помощью паттерна BFF разработчики могут создавать и поддерживать один тип серверных компонентов для каждого пользовательского интерфейса, используя оптимальные настройки для этого интерфейса, вместо того чтобы пытаться внедрить универсальное решение, подходящее для всех интерфейсов, что может отрицательно повлиять на производительность на стороне клиента.
  • Паттерны сущностей и объединений: сущность — это объект, различающийся по своим характерным признакам. Например, на сайте интернет-магазина объект Товар может различаться по названию, типу и цене. Объединение — это набор связанных сущностей, которые следует рассматривать как одно целое. Примером объединения для интернет-магазина является Заказ — группа товаров (сущностей), заказанных покупателем. Эти паттерны применяются для осмысленной классификации данных.
  • Паттерны обнаружения служб: помогают приложениям и службам обнаружить друг друга. Микросервисная архитектура предполагает динамическое изменение экземпляров служб во время масштабирования, обновления, сбоев служб и даже прерывания работы служб. Эти паттерны предоставляют механизмы обнаружения, которые помогают справиться с промежуточными состояниями. Распределение нагрузки с помощью паттернов обнаружения служб: оптимизация потока данных на основе проверок работоспособности и сбоев служб, выполняющих роль триггеров.
  • Паттерны микросервисов адаптера: паттерны адаптера выполняют роль переходников по аналогии с универсальными сетевыми адаптерами для туристов. Паттерны адаптера призваны упростить преобразование взаимосвязей между несовместимыми классами или объектами. Приложение, основанное на сторонних API, может с помощью паттерна адаптера обеспечить обмен данными между приложением и API.
  • Паттерн «удушающего» приложения (Strangler): упрощает управление процессом рефакторинга монолитного приложения в приложение на базе микросервисов. Такое образное название паттерна выбрано по аналогии с вьющимся растением (микросервисы), которое постепенно оплетает и сдавливает дерево (монолитное приложение).

Более подробная информация об этих паттернах приведена в статье «Применение паттернов разработки на основе микросервисов (часть 4)». На веб-сайте IBM Developer также можно найти много полезной информации о паттернах разработки с помощью микросервисов.

Антипаттерны

Наряду с паттернами правильного проектирования на основе микросервисов существует не менее важная группа антипаттернов, которые могут быстро привести команду разработчиков к негативному результату. Некоторые из запрещенных приемов работы с микросервисами приведены ниже:

  • Первое правило работы с микросервисами — не создавать микросервисы, а точнее не начинать разработку с микросервисов. Микросервисы хорошо подходят для управления сложными, громоздкими приложениями, обновление и обслуживание которых требует значительных усилий. Только если вы уже столкнулись со сложностями в работе с монолитным приложением, пора задуматься о его рефакторинге на основе микросервисов. До тех пор пока приложение не доставляет вам никаких хлопот, вопрос рефакторинга будет не актуален.
  • Не стоит работать с микросервисами без DevOps или облачных услуг: создание микросервисов означает построение распределенных систем, уровень сложности которых зависит от принимаемых вами решений. Любые попытки внедрить микросервисы без а) правильной стратегии автоматизации развертывания и мониторинга или б) управляемых облачных услуг, поддерживающих расширение гетерогенной инфраструктуры, неизбежно приведут к лишним хлопотам. Избавьте себя от неприятностей для более эффективного управления своим временем.
  • Не создавайте слишком много микросервисов за счет уменьшения их размера: если переборщить с «микроуровнями», вы столкнетесь с новыми расходами и сложностью, которые могут перевесить общую пользу от микросервисной архитектуры. Гораздо лучше отдать предпочтение более крупным сервисам и разделять их на более мелкие части только после того, как возникнут проблемы, решаемые с помощью микросервисов: сложные процедуры развертывания изменений, отнимающие много времени, или разные требования к масштабированию/нагрузке.
  • Не превращайте микросервисы в SOA: микросервисы и сервис-ориентированная архитектура (SOA) часто отождествляются, так как на самом базовом уровне понимания оба подхода направлены на создание отдельных компонентов, допускающих многократное использование другими приложениями. Разница между микросервисами и SOA в том, что проекты микросервисов, как правило, предусматривают рефакторинг приложения с целью упрощения управления, в то время как SOA меняет принцип работы ИТ-услуг в масштабе предприятия. Проект микросервисов, трансформировавшийся в проект SOA, скорее всего рухнет под собственной тяжестью.
  • Не пытайтесь повторить опыт Netflix: компания Netflix одной из первых применила микросервисы для разработки и обслуживания приложения, генерирующего около 30% всего интернет-трафика. В ситуации «идеального шторма» компании требовалось создавать огромное количество строк кода и сервисов, которые не нужны среднестатистическому приложению. Лучше всего начать с комфортной для вас скорости, чтобы избежать излишней сложности, и использовать максимальное число готовых инструментов.

Учебники: формирование навыков работы с микросервисами

Если вы готовы узнать больше об использовании микросервисов или хотите повысить свою квалификацию, просмотрите следующие учебники:

Микросервисы и IBM Cloud

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

Сделайте следующий шаг:

  • Уменьшите нагрузку на разработчиков благодаря автоматизации итераций с помощью облачных инструментов IBM.
  • Начните изучение управляемой службы Kubernetes со знакомства с Red Hat OpenShift on IBM Cloud или IBM Cloud Kubernetes Service. Узнайте больше о бессерверных вычислениях на странице IBM Cloud Code Engine.
  • Микросервисы в равной степени касаются технологий и организации работы в команде. Разработайте стратегический план внедрения DevOps при поддержке специалистов IBM DevOps.

Начните работу с учетной записью IBM Cloud прямо сегодня.