Микросервисы позволяют разбить ПО на небольшие, независимые друг от друга части, что обеспечивает бóльшую гибкость. Ввиду того, что микросервисная технология продолжает набирать популярность, портал Techopedia рассказывает о ее плюсах и минусах.

Если дюжине специалистов задать вопрос: «Что такое микросервис?», то все ответы на него будут разными. Ведущий эксперт по микросервисам, а также автор книги «Microservices for the Enterprise» Прабат Сиривардена определяет их назначение следующим образом: «Любое приложение можно построить при помощи нескольких микросервисов. Например, приложение для э-коммерции может состоять из следующих микросервисов: заказы, товары, отправка, выставление счетов и т. д. Мы должны иметь возможность разрабатывать, развертывать и поддерживать каждый из этих микросервисов с минимальной зависимостью друг от друга».

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

Сэм Ньюман в своей книге «Building Microservices» нарек микросервисы небольшими автономными службами, которые работают вместе. Чтобы понять принцип их работы, нужно привести простую аналогию. Гигант слишком массивен, чтобы перемещаться по заводу и ловко выполнять различного рода задачи. Чтобы делать свою работу быстрее и эффективнее, он нуждается во множество помощников, которые помогали бы ему справиться с каждым отдельным фрагментом работы. Этот гигант — традиционное монолитное приложение, созданное в виде единого целого. В него входит пользовательский интерфейс на стороне клиента, серверное приложение и база данных. Другими словами, приложение содержит полный комплект функций для всех бизнес-операций, которые оно выполняет.

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

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

Как работают микросервисы

Допустим, приложение захочет обработать заказ, а также обновить товарные запасы. В этом случае микросервис заказов свяжется с микросервисом товарных запасов и затем с микросервисом по выставлению счетов.

Как микросервисы взаимодействуют друг с другом

Это происходит при помощи интерфейсов прикладного программирования (API), которые определяют виды вызовов или запросов, устанавливают пути их выполнения, диктуют выбор форматов данных, конвенции и т. д. Для хранения своего ПО большинство микросервисных приложений используют контейнеры, такие как Docker или Kubernetes. Микросервисы идеально подходят для DevOps, сглаживая проблемные моменты в работе разработчиков и инженеров, чтобы те могли быстрее создавать высококачественное ПО. Именно так действует Amazon, что позволяет ей каждые 11,7 с выпускать новый код, а Netflix — тысячи раз в день его развертывать.

Шесть особенностей микросервисов:

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

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

Почему люди переходят на микросервисы? К числу преимуществ, которые организации получают от развертывания микросервисов, относят следующие:

  • повышенная масштабируемость. Вы можете добавлять (и перемещать) микроприложения в зависимости от масштаба бизнеса;
  • лучшая изоляция ошибок. Если один микросервис выходит из строя, остальные продолжают работать;
  • повышение гибкости бизнеса. Поскольку отказ микросервиса затрагивает только один конкретный модуль, инженеры могут экспериментировать с ними по методологии «fail fast»;
  • упрощенная отладка и техническое обслуживание. Любой микросервис можно просканировать, улучшить и изменить без последствий для целостности всей системы;
  • перспективные приложения. Компании могут обновлять отдельные услуги без необходимости тратить время и средства на демонтаж системы.

К недостатки приложений микросервисов можно отнести следующие:

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

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

Согласно опросу, проведенному в 2017 г. поставщиком ПО LeanIx, с каждым годом все больше компаний переходят на микросервисы. К ним относятся Netflix, Google, Amazon, а также другие технологические лидеры. 118 респондентов, которые применяли микросервисы, разворачивали новые выпуски ПО в пять раз быстрее, чем приверженцы традиционных монолитных программ.

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

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