Переход на микросервисную архитектуру: перейти нельзя остаться

9 августа 2022

Мария Простова

Время чтения: 5 мин

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

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

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

Плюсы и минусы монолитной архитектуры

Монолитная архитектура вполне может подойти вашему бизнесу в начале развития проекта.

Плюсы монолитной архитектуры:

  • Быстрый старт разработки и выпуск первых версий продукта (быстрее микросервисов) благодаря наличию решений “из коробки”

вам нужно только адаптировать их под свой бизнес и настроить, при этом вам не потребуется большой объем доработок

  • Одна кодовая база

а значит, легче разрабатывать и проще делать отладку всей системы

  • Тестирование системы

сквозное тестирование проводится быстрее, чем в случае с микросервисами

  • Развертывание системы

развернуть один сервис всегда проще и дешевле, нежели несколько

  • Проще поддерживать

может спокойно справляться текущая команда

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

Основные минусы:

  • Сложность при масштабировании

при такой архитектуре рано или поздно система перестанет справляться с увеличивающимися нагрузками

  • Надежность

ошибка в одном компоненте может привести к отказу всей системы низкая производительность одного компонента влияет на производительность всей системы

  • Стек технологий на проекте

расширение стека может вызывать конфликты на уровне инфраструктуры проекта

Плюсы и минусы микросервисной архитектуры

Основные плюсы:

  • Масштабируемость

у вас не будет “потолка”, система может органично расти вместе с вашим бизнесом и справляться с любыми требуемыми нагрузками

  • Гибкость

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

  • Повышение отказоустойчивости

если один микросервис по каким-то причинам даст сбой, то другие продолжат свою работу, а значит, ваш сайт не “ляжет” целиком

  • Возможность поэтапного внедрения

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

поэтапное внедрение позволит управлять как продуктом, так и бюджетом на разработку

Минусы, которые следует учитывать:

  • Скорость разработки первой версии продукта

разработка микросервиса однозначно дольше, чем монолита, где решение есть из “коробки”

  • Возможное расширение стека технологий на проекте

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

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

  • Сообщения между сервисами

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

Когда нужно переходить на микросервисы

Точного ответа на вопрос “когда” и “нужно ли?” нет: все зависит от целей и ресурсов бизнеса. Как правило, переход позволяет бизнесу масштабироваться, упрощать внедрение нового функционала.

Основные признаки, что вам нужно переходить на микросервисную архитектуру

Рост нагрузки

Например, у нашего клиента – маркетплейса электротоваров – изначально была монолитная CMS Bitrix, товарная база насчитывала 7-9 тыс. товаров, но сейчас они активно развиваются и в скором времени товарная база пополнится еще на 1 млн. товаров.

Такое резкое расширение товаров существенно увеличит нагрузку на:

  1. поиск со стороны пользователя (приведет к замедлению работы каталога)
  2. фильтрацию со стороны контент-менеджера, пользователя (тоже замедление работы)
  3. сайт в целом

Поэтому было принято решение выделить каталог в отдельный микросервис.

Рост системы, разработка нового функционала

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

Проблемы со скоростью доставки каждого нового релиза

Когда новая фича требует полной проверки и пересборки всего монолита, и все больше времени занимает и и сама разработка, и тестирование функционала.

Можно ли оставить монолитную архитектуру?

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

Да, остаться на монолите тоже можно, но стоит взвешивать все риски и перспективы дальнейшего развития и масштабирования. Вернемся к примеру нашего клиента с ростом товарной базы с 7-9 тыс. товаров до 1 млн.товаров. Основные риски, которые нас ждали при увеличении каталога в монолитной архитектуре:

  1. товарную базу можно будет нарастить только до определенного количества
  2. возникнут большие потери производительности по поиску и фильтрации товаров в каталоге
  3. увеличение времени индексации
  4. рост кеша
  5. увеличение затрат на дальнейшую разработку

В качестве одной из альтернатив выделению каталога в микросервис мы рассматривали подключение Sphinx для полнотекстового поиска и коробочного решения Bitrix для фасетного поиска. Но и тут были недостатки

Для полнотекстового поиска (поиск по словам или фразе) можно было бы использовать Sphinx, но:

  1. Bitrix поддерживает версию Sphinx только до 2.2.11, версия старая, является архивной
  2. Плохая индексация товаров. Bitrix рекомендует производить индексацию каждый раз путем удаления и установки модуля Поиск, а такие манипуляции в боевой среде недопустимы

Для фасетного поиска (поиск по характеристикам товара: цвет, цена, размер и т.д.) – могло быть использовано решение из коробки, но:

  1. Существуют перебои в работе, может просто не работать
  2. Медленный поиск, за счет того что он работает в связке PHP + MySQL

MySQL – надежное хранилище данных, но лишен быстрого поиска. Для скорости нужно постоянно индексировать данные. Излишняя индексация приводит к большой задержке при записи и обновлении данных в БД, требует много места на диске.

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

Какой стек выбрать для микросервиса

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

На примере нашего клиента – подбор технологий был под проект.

Для начала мы выделили задачи, которые должен решить сервис:

  1. Обеспечить хранение неограниченного количества товаров с различными свойствами
  2. Индексировать товары для поиска
  3. Обеспечить получение полной информации по товарам (полнотекстовый и фасетный поиск)
  4. Добиться повышения производительности

Основываясь на всех задачах мы решили:

  1. организовать хранилище на модели NoSQL
  2. выделить полноценный поисковой движок с помощью ElasticSearch
  3. настроить обновление каталога по шине Kafka
  4. реализовать микросервис на PHP

Хранилище по модели NoSQL

Этот вариант мы выбрали из-за ряда преимуществ:

  1. Гибкость – NoSQL позволяет создавать неограниченное кол-во свойств, без ущерба производительности
  2. Высокая производительность при выполнении простых запросов

Данный подход решает проблему больших каталогов, позволяет наращивать объем каталогов без ущерба системе и упрощает разработку новых импортов из других систем.

Полнотекстовый и фасетный поиск на ElasticSearch

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

Обновление каталога по шине Kafka

Импорт каталога происходит непрерывно, 24/7: товары попадают в шину на данный момент из двух микросервисов из различных источников. Индексация товаров для полнотекстового и фасетного поиска происходит по мере получения и обновления товаров микросервисом “каталог”. Нет нагрузки на стороне интернет-магазина. Не требует переиндексации полного товарного каталога. Кеш не играет большой роли в данной схеме.

Вместо заключения

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

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

  1. Решили проблему с ростом товарной базы
  2. Настроили быстрый полнотекстовый и фасетный поиск
  3. Снизили нагрузку на интернет-магазин
  4. Обеспечили непрерывное, плавное обновление каталога

И самое главное: получили возможность масштабировать как элементы системы, так и интернет-магазин.

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

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

В этой статье: Переход на микросервисную архитектуру: перейти нельзя остаться