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

Небольшие однофункциональные приложения — так называемые микросервисы — можно развертывать, масштабировать и тестировать независимо друг от друга [1], что вполне можно считать естественным продолжением сервисной концепции. Разделение монолитных систем, модули которых не могут выполняться независимо друг от друга, на гранулярные, взаимодействующие с помощью сообщений (например, через API на основе RPC или веб-сервисы REST), позволяет организациям ускорять выпуск продуктов на рынок. Agile-команды могут строить стратегию своей работы, основываясь на микросервисах [2], так как, что они по определению разрабатываются независимо друг от друга [3].

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

Как бы то ни было, методы, основанные на микросервисах, активно внедряются многочисленными компаниями, включая Amazon, Deutsche Telecom, LinkedIn, Netflix, SoundCloud, Uber, Verizon и крупные онлайн-издания. Нередко с помощью микросервисов модернизируют унаследованные приложения, с помощью рефакторизации разделяя монолитную систему на микросервисы, что обеспечивает инкрементальную модернизацию унаследованного ПО и потенциально снижает риски по сравнению с разработкой на базе микросервисов всей системы с нуля.

Технологии для микросервисов

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

В таблице приведен обзор существующих микросервисных технологий [1, 3] вместе с их рейтингом, построенным на основе реального опыта применения.

Переход на микросервисы

При осуществлении проектов миграции на микросервисы следует придерживаться ряда практических рекомендаций.

Будьте готовы к организационным изменениям. Микросервисы потребуют перехода на новую корпоративную культуру.

Изучите систему. Выясните зависимости с помощью специальных средств, таких как Retrace, Dynatrace, SchemaCrawler и т. п., либо сделайте это вручную.

Формализуйте архитектуру (инструменты, фреймворки и т. д.). Не откладывайте выбор платформы и по возможности предусмотрите необходимые механизмы поддержки DevOps, причем чем раньше, тем лучше.

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

Разделите проект на этапы проектирования, написания кода, тестирования и интеграции. Освойте agile-методы. По возможности используйте средства DevOps на каждом этапе, например Fuge, Git/GiHub, Jenkins, Phantom или Kubernetes.

Переход на микросервисы, как и любое преобразование ПО, способен сильно повлиять на качественные характеристики приложения:

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

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

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

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

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

Пример: микросервисы и безопасность

При разработке приложения на базе SonarQube и AngularJ возник ряд проблем с технологией Cross-Origin Resource Sharing (CORS). С помощью SonarQube выполнялся анализ исходных кодов на различных сайтах, информацию с которых собирал главный сервис приложения. С помощью CROS и дополнительных заголовков HTTP-приложение получало разрешение на доступ к выбранным ресурсам сервера в другом домене (рис. А).

Рис. А. Типовой сценарий: пользователь обращается через браузер к сайту, который получает информацию от других сервисов

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

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

Сама CORS реализуется как серверами, так и браузерами. Согласно стандартам W3C, пользовательские агенты обычно блокируют сетевые запросы, исходящие из «чужих» доменов. Эти ограничения не позволяют клиентскому веб-приложению, работающему в одном домене, получать данные из другого, а также ограничивают ненадежные HTTP-запросы к доменам, отличающимся от того, в котором работает приложение.

С учетом этого риск безопасности, связанный с CORS, был ограничен путем настройки браузеров.

***

Технологии микросервисов развиваются сегодня весьма стремительно, в частности, получили развитие бессерверные вычисления — предоставление облачным микросервисом стандартных функций, которые можно использовать в приложениях для реализации необходимой бизнес-логики. Такие платформы могут называться «бессерверными» или предоставляющими «функции в виде сервиса» (Function-as-a-Service, FaaS): Amazon Web Services Lambda, Iron.io и Google Functions.

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

Литература

J. Thones. Microservices // IEEE Software. — 2015. Vol. 32, N. 1. — P. 116, 113–115.
A. Balalaie, A. Heydarnoori, P. Jamshidi. Microservices Architecture Enables DevOps: Migration to a Cloud-Native Architecture // IEEE Software. — 2016. Vol. 33, N. 3. — P. 42–52.
C. Pautasso et al. Microservices in Practice, Part 1: Reality Check and Service Design // IEEE Software. — 2017. Vol. 34, N. 1. — P. 91–98.

Хавьер Ларрусеа (xabier.larrucea@tecnalia.com), Изаскун Сантамариа (izaskun.santamaria@tecnalia.com ) — руководители проектов Tecnalia; Рикардо Коломо-Паласьос (ricardo.colomo-palacios@hiof.no) — профессор Эстфоллского университетского колледжа; Кристоф Эберт (christof.ebert@vector.com) — управляющий директор Vector Consulting Services.