Отечественный бизнес только начинает переходить на микросервисные приложения, однако потенциал у них высокий. По данным прошлогоднего исследования CNews Analytics и «Инфосистемы джет», лишь 45% компаний, у которых есть собственная команда разработки, используют технологию в продуктиве, почти четверть (23%) – в тестовой среде. В планах использовать микросервисы – у 9% опрошенных, 18% – не планируют этого делать.
Рассказываем, почему всё больше компаний смотрят в сторону микросервисов и чем такой подход отличается от монолитного способа разработки.
Содержание
Что это такое микросервисная архитектура
Микросервисная архитектура – это способ создания программных продуктов, предполагающий разработку независимых друг от друга модулей. Каждая часть приложения отвечает за определенную задачу и может быть изменена или расширена без дополнений в других. При этом сервисы взаимодействуют между собой с помощью обмена сообщениями.
Проще говоря, микросервисная архитектура – это деление на модули в соответствии с запросами бизнеса. Набор технологий индивидуален, чаще всего включает в себя хранилище, пользовательский интерфейс, внешние связи. Каждый из сервисов может быть разработан на разных языках, с использованием различных библиотек.
Противоположность микросервисам – монолитная архитектура ИТ-решения, которая объединяет различные компоненты системы на одной платформе. Все части приложения в этом случае унифицированы, управление функциями осуществляется в одном месте.
Впервые термин «микросервисы» появился в середине 2000-х годов, однако сама концепция получила развитие в 2011 году, на семинаре архитекторов ПО в Венеции. После этого стали появляться различные публикации на эту тему, а в своих докладах о внедрении микросервисов рассказывали специалисты Amazon, Twitter, Netflix.
У концепции монолита есть недостатки: сложно разделить ответственность между модулями, невозможность разработки сразу несколькими командами. Так появилась идея более релевантной архитектуры приложений. Компании стали уходить от модели, где все работает в едином ИТ-решении, к системе из нескольких независимых частей, между которыми есть правила взаимодействия.
Микросервисный подход уже пробуют лидеры индустрий. Среди интересных примеров – кейс ВТБ. Год назад банк запустил первый в стране розничный кредитный конвейер, разработанный на микросервисах на базе централизованной AI-платформы. ИТ-инструмент уже помогает оперативно формировать для розничных клиентов предодобренные кредитные предложения. Как отмечает ВТБ, микросервисная архитектура решения позволит лучше и быстрее реагировать на запросы клиентов, даст возможность постоянно совершенствовать систему, повышая производительность отдельных и независимых друг от друга сервисов.
Более того, ВТБ не первый год экспериментирует с микросервисами, значительно улучшая собственные продукты. К примеру, ранее мобильное приложение для розничных клиентов «ВТБ Онлайн» было монолитным и выдерживало нагрузку примерно 85 тысяч человек в минуту, что при росте бизнеса стало не удовлетворять потребности пользователей. А если «вылетала» одна из функций (например, переводы или платежи), то ломались все остальные. Поэтому банк перевёл приложение на микросервисную архитектуру. Сейчас система может выдерживает до 400 тысяч одновременных сессий, а за её стабильное функционирование отвечает сразу несколько независимых платформ. Поэтому количество нештатных ситуаций сведено к минимуму: даже если что-то одно вышло из строя, клиент может зайти в приложение (даже во время технических работ), посмотреть свой баланс на счёте.
На зарубежном рынке микросервисную архитектуру используют такие гиганты, как Facebook, Amazon, Spotify, Uber, Google. Компания Netflix использует свыше 700 микросервисов для каждой конкретной задачи – из них состоит весь сервис. Например, один элемент хранит информацию о сериалах, которые посмотрел тот или иной пользователь. Другой – отвечает за ежемесячную оплату за пользование сервисом. Третий – изучает предпочтения, историю просмотров, чтобы предложить релевантный конкретному человеку сериал.
Преимущества микросервисного подхода
- Стандартная проектная модель разработки, используемая большинством компаний, подразумевает, что после создания и внедрения продукт передается специалистам поддержки, а команда разработчиков распускается.
В случае микросервисного подхода меняется схема работы: поддержкой и развитием продукта занимается та же команда разработчиков, которая эту систему создавала. Преимущество для бизнеса в том, что специалисты, отвечающие за применение приложения, чаще и больше общаются с пользователями, а значит, смогут чутко корректировать функциональность, вносить изменения.
- Эффективность микросервисного подхода привела к тому, что каждая группа разработчиков может создавать или развивать свою часть с помощью разных инструментов, независимо от других команд, на разных языках программирования.
- Разработка и дальнейшая поддержка небольших программных продуктов происходят проще, быстрее, чем в случае больших проектов. Из-за того, что каждый сервис отвечает за одну функцию, не нужно перекраивать весь алгоритм, чтобы внести какое-то изменение.
-
Возможно быстро и легко проводить обновления при микросервисной архитектуре – на общей работы системы это никак не скажется.
-
Сбой у одного из модулей не влияет на работу прочих элементов ИТ-системы.
-
Сервисы, которыми не пользуется бизнес или по каким-то причинам оказались не нужны, можно легко отключить. Это никак не отражается на работе остальных приложений.
-
Микросервисы доступны на любом устройстве, в облачной среде или on-premise.
-
Разработка и внедрение сервисов происходит постепенно, а их очередь зависит от потребностей подразделений компаний.
- При высоком темпе и большой сложности разработки монолитный подход может станет «костылем».
Недостатки микросервисного подхода
Несмотря на такое большое количество преимуществ, у микросервисного способа разработки есть и возможные сложности, которые стоит учитывать.
-
Если взаимодействие в сервисах, которые выполняют несколько задач, локальное, то возникает необходимость автоматизации модулей и взаимодействия их по сети.
-
Отсутствие стандартизации взаимодействия служб, которое может возникать при микросервисном подходе, может приводить ошибкам или сложностям отладки при согласовании форматов обмена между модулями.
-
Сложности соблюдения баланса между отказоустойчивостью и нагрузкой.
-
Различные взгляды внутри команды на архитектуру микросервиса могут вызывать дебаты, потерю производительности в эти периоды.
Что нужно учесть при переходе на микросервисы
Для начала необходимо спланировать инфраструктуру. Происходит это на аппаратном и системном уровнях.
В случае микросервисной архитектуры нет специфических требований к аппаратному уровню ИТ-инфраструктуры, однако при разработке нужно учитывать несколько моментов:
-
распланировать нагрузку на оборудование;
-
не забудьте принять во внимание нагрузку служебных сервисов самой системы управления контейнерами – иногда это условие может сильно сказываться на общем результате из-за учёта множества компонентов (логирование, мониторинг, сетевая маршрутизация);
- и сразу решите, где будет работать микросервисная архитектура – на физическом оборудовании или виртуальной инфраструктуре – этот выбор лучше сделать сразу из-за наличия собственных требований и ограничений у каждого из вариантов.
На системном уровне важно:
-
заранее продумать ландшафты приложений: каждый из них имеет собственные требования, особенности к вычислительным ресурсам;
спланировать интеграцию с другими элементами ИТ-инфраструктуры и внешними подсистемами, а для этого изучите опыт реализации ИТ вашей компании, технологический стек, используемые инструменты (хранилища, сети, резервное копирование, продукты для мониторинга); -
создать стратегию аварийного восстановления, чтобы обеспечить непрерывность работы сервиса – любые аварии в ЦОДе приводят к простоям, которые могут очень дорого обходиться бизнесу.
-
согласовать со службой информационной безопасности схемы сопряжения.
Как перейти от монолита на микросервисы
1) Сформулируйте задачи
Каждый микросервис отвечает за узкую функцию, которая закрывает конкретную потребность пользователя. Сформулируйте эти бизнес-задачи: проанализируйте текущие и проработайте новые, исходя из проблем процесса. Далее определите, какими средствами лучше всего решать каждую задачу, выберете инструменты для решения.2) Соберите команды разработчиков
Важно, чтобы зоны ответственности команд были разграничены, то есть у каждой из них – своя среда разработки. Благодаря этому каждая группа ИТ-специалистов концентрируется на работе своего приложения. Доступ к данным следует сделать распределенным, с разграниченным доступом. Поскольку каждая команда отвечает за весь жизненный цикл только своего продукта, именно они выбирают язык программирования, методологию внедрения.
Если ранее ваши разработчики работали только с монолитными системами, заложите ресурсы и время на их переобучение под началом опытных внешних специалистов по микросервисной архитектуре.
3) Создание инструмента для взаимодействия микросервисов
В проекте нужна среда для коммуникации, поэтому необходимо организовать клиент, оптимизированный для REST-вызовов, с возможностью применять все языки программирования. Дополнительно потребуется регулярно обновляемая конфигурация, которая локализована под каждое приложение, – с её помощью микросервисы будут «понимать», как передавать данные друг другу.
Разработка приложения (включая время на тестирование) занимает 2-3 недели, поэтому лучше отдать предпочтение Agile-модели, а не Waterwall.
4) Быстрый релиз с помощью DevOps
Микросервисный подход как нельзя лучше вписывается парадигму DevOps. Их общие принципы – налаженная коммуникация между смежными командами, быстрый выпуск релизов.
Микросервис следует воспринимать как минипродукт, который «помещается» в контейнер. Он проходит автоматизированное и нагрузочное тестирование, и, если критерии качества соблюдены, начинается интеграция приложений. При этом управление контейнерами происходит с помощью системы оркестрации.
Инструменты для создания микросервисов
Несмотря на то, что сервисы независимые и небольшие, их разработка отличается от традиционной. Существует большое количество инструментов для разработки микросервисов, которые выполняют определенные задачи.
-
Управление API и тестирование
Известный инструмент – набор средств разработки API, с помощью которого легко запускать тесты на базе пользовательского интерфейса, Postman. Также есть возможность комбинировать простые и сложные запросы HTTP. Это помогает сделать тестирование, разработку, документирование API быстрыми.
Для тестирования, проверки работоспособности API разработчики используют API Fortress, а для управления API с открытым исходным кодом – масштабируемую и быструю платформу Tyk.
-
Служба сообщений
Для архитектуры микросервисов важна очередь сообщений – она влияет на обработку связи между приложениями и внешними источниками (например, вызовы API).
Среди популярных инструментов – платформа Apache Kafka (помогает при распределенной потоковой обработке), решение RabbitMQ, используемое как коммуникационный мост между микросервисами, Amazon Simple Queue Service (SQS). Последний из перечисленных – это надёжный, мощный микросервисный механизм связи, который предоставляет хранилище для сообщений в ожидании.
-
Мониторинг
После разработки и внедрения приложений необходимо отслеживать их работу, учитывая ряд факторов. К примеру, насколько хорошо работают сервис, базы данных? Нужно ли их дополнительно настраивать?
Logstash с открытым кодом – инструмент ведения журналов, используется при хранении, сборе, преобразовании данных. Также это решение вместе с интерактивным интерфейсом Graylog может быть применим как централизованный сервер.
-
Оркестровка
Для автоматической координации и управления микросервисами и службами можно использовать системы оркестрации. Например, попробовать Apache Mesos, Nomad или Conductor. Последний из них – это часть экосистемы Netflix OSS. Дополнительно он может помочь при контроле и визуализации взаимодействия между элементами.
-
Инструментарий
Выбор технологий и инструментария может быть очень широким благодаря архитектуре микросервисов. К примеру, в качестве платформы с открытым кодом может быть полезна fabric8, которая позволяет управлять конфигурацией на базе git, обеспечивает для элементов высокую доступность, масштабируемость. Для создания хорошо структурированного кода и систематизации логики приложения можно использовать Seneca, набор микросервисов для Node.js. А с помощью безсерверной платформы Google Cloud Platform можно создавать управляемые события для сервисов с малой связью. Через Google Compute API доступно подключение облачные функции к другим продуктам.
-
Архитектурный каркас
С помощью фреймворка goa ИТ-специалисты могут разрабатывать API, генерировать контент, от текстовых форматов JSON до библиотек JavaScript. Или, к примеру, инструмент Kong использует множество модулей, которые помогают разработчикам при развертывании приложений, в том числе с помощью шаблонов.
-
Безсерверные инструменты
Их цель – упростить серверные функции, что положительно сказывается на качестве работы специалистов: они смогут не тратить много времени на структуру приложений, сосредоточиться на бизнес-задачах.
Например, Apache Openwhisk – легко расширяемая платформа, с помощью которой разработчики создают, тестируют, настраивают микросервисы. Открытая FaaS-платформа IronFunctions может поддерживать любые функции, вне зависимости от языка написания. OpenFaaS помогает «упаковать» любой процесс в безсерверную функцию Linux или Windows. А также Microsoft Azure Functions – инструмент, который расширяет функциональные возможности систем Azure.
-
Тимбилдинг
Ответственность и гибкий подход должны быть на протяжении всего жизненного цикла микросервисов. Для совместной работы специалистов существует несколько инструментов: чаты, видеоконференции, проектное управление, базы знаний. Наиболее известные помощники – Trello, Slack, Google Meet.
Несмотря на все преимущества микросервисной архитектуры, выбор модели разработки зависит от организационной структуры вашей компании. К примеру, если у вас лишь одна команда с пятью разработчиками, то монолитный способ может стать релевантным решением. А если у вас шесть команд, которые работают над одной платформой, то микросервисная архитектура станет идеальным выбором.
***
Нужна экспертная или технологическая помощь в разработке решения на микросервисах или трансформации текущего стека технологий? Оставьте свои контакты в форме ниже, мы свяжемся с вами в ближайщее время.
