Как распилить монолит: о микросервисной архитектуре веб-приложений

Илья Малиновский

Тимлид компании Hawking Bros

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

Что такое микросервисная архитектура

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

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

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

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

Проектирование микросервисов

При проектировании микросервисов необходимо отталкиваться от их основных характеристик. Каждый микросервис должен быть небольшим, сфокусированным, и независимым настолько, насколько это возможно. Разберём подробнее.

В фокусе одного микросервиса должна быть одна задача. Это не только позволит сделать его максимально компактным, но и обеспечит «самостоятельность» микросервиса, исключив лишние связи.

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

Также стоит определиться с тем в каком формате будут взаимодействовать ваши микросервисы (JSON, XML, GraphQL, gRPC). Данный шаг очень важен, так как впоследствии с ростом микросервисов будет сложно перестроиться на новый формат

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

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

Инструменты для работы с МС: создание, логирование, мониторинг

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

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

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

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

Как можно догадаться, объём логов может выходить за границы чувственного восприятия человека. На помощь приходит ELK-схема — набор из трёх инструментов для генерации, обработки и индексации лога. Микросервис генерирует файлы лога, которые в дальнейшем проходят три этапа обработки. Logstash собирает логи приложений по заданным правилам и направляет их в ElasticSearch, который хранит и индексирует все логи. Затем информация визуализируется в Kibana, где мы можем с ней работать.

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

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

Для мониторинга можно использовать популярные Zabbix или Prometheus. Выбор зависит от ваших потребностей.

Напоследок упомянем CI/CD — практику continuous integration и continuous delivery. Так как микросервисов достаточно много, процесс интеграции вручную не представляется возможным. CI/CD позволяет автоматизировать выкладку на разные ландшафты и обладает следующими преимуществами: автоматизация сборки проекта, автоматическое тестирование, экономия времени при доставке фич на разные ландшафты. Для реализации CI/CD используют: Gitlab CI, Bitbucket Pipelines, Jenkins, Gitlab Actions.

Работа в команде

Чтобы микросервисы не превратились в распределённый монолит, команде также нужно придерживаться некоторых правил работы.

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

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

И добавляем самое важное правило: разработал блок — написал документацию.

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

Но если без документации по проекту разобраться ещё получится, хоть и с большим трудом, то без документации API работать невозможно. Фиксировать необходимо публичный API, который вы даете фронтендерам для взаимодействия и микросервисный API. Для этого предлагаем воспользоваться Postman или Swagger.

Стоит ли вам перейти на микросервисы?

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

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

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

Вы также можете посмотреть выступление тимлида Hawking Bros, Ильи Малиновского, о микросервисной архитектуре веб-приложений на конференции Mind Bros Conf