Каждый модуль-микросервис реализуется и работает как малая полностью независимая система [1], предоставляющая доступ к своей внутренней логике и данным с помощью определенного сетевого интерфейса [2]. Это способствует повышению гибкости ПО, поскольку каждый микросервис является независимой единицей в плане разработки, развертывания, эксплуатации, управления версиями и масштабирования.

Будучи независимыми сервисами с четкими границами, микросервисы похожи на традиционную сервисную архитектуру (service-oriented architecture, SOA) [3]. Можно даже сказать, что микросервисы — это подвид SOA. Но в то время как SOA сильно полагается на специальные средства (сервисную шину предприятия и иное «тяжеловесное» связующее ПО), микросервисы используют исключительно малоресурсоемкие технологии.

Кроме того, SOA обычно ассоциируют с протоколами веб-сервисов, форматами вроде SOAP, WSDL и семейством стандартов WS-*. Микросервисы же обычно полагаются на REST, HTTP и другие менее ресурсоемкие форматы, которые принято считать «нативными» для веб-разработки. Наконец, SOA обычно применяют как интеграционное решение, тогда как микросервисы преимущественно используются для «сборки» индивидуальных приложений.

Преимущества микросервисов

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

Архитектуры микросервисов могут различаться, но все они создаются, чтобы ускорить выпуск — то есть обеспечить максимально быстрое превращение первоначальной идеи в функцию, выполняющуюся в рабочей среде. Во многих организациях в ИТ сегодня видят средство улучшения способности адаптироваться к рыночным изменениям, а уже не центр затрат, которые лучше ограничивать. Для целей повышения адаптивности микросервисы обычно упаковывают и развертывают в облаке с помощью облегченных контейнерных технологий, полагаясь на практики DevOps и полностью автоматизированные механизмы интеграции и выпуска ПО. Таким образом обеспечивается быстрота развертывания микросервисов в различных средах выполнения — например, в среде тестирования, подготовки (staging) и предварительного выпуска (canary release) по произвольным графикам при минимуме централизованного управления.

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

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

А если говорить о концепции масштабируемой организации, то каждый микросервис должен представлять собой самостоятельный, изолированный объект принятия решений, относящихся к периодам разработки и выполнения. Другими словами, группа разработчиков имеет возможность изолированно принимать решение по каждому сервису: выбор языка программирования, фреймворков, СУБД и т. п. Тем самым...

Это не вся статья. Полная версия доступна только подписчикам журнала. Пожалуйста, авторизуйтесь либо оформите подписку.
Купить номер с этой статьей в PDF