Почему мы перешли на микросервисы
Мы начинали работу с построения типового интернет-магазина на 1С-Битрикс. Модель данных там сильно универсализирована и довольно сложно «растачивается» и масштабируется. В CMS 1С-Битрикс есть подходящие решения, но качество технической реализации нас не устраивало. Кроме того, нужно было купить дорогие лицензии, которые нельзя дорабатывать самим.
Вопросы оптимизации и решения большого количества служебных задач возникли достаточно быстро, но решались они в рамках монолитной архитектуры. У нас возникли сложности со скоростью работы подсистем, выдерживанием нагрузок, изоляцией данных и логики, когда одно чинишь, а другое ломается. Трафик стабильно рос в 3–4 раза каждый год. В пиковый сезон случались одновременные наплывы покупателей на акции и рассылки, нагрузка подскакивала в 5–10 раз, система не выдерживала и ложилась.
Переход на микросервисы назрел спустя три года, когда монолит даже с повышением мощностей перестал приемлемо справляться с задачами. Он был связан с необходимостью распределенных вычислений, балансировкой нагрузки, обслуживанием все большего трафика, изоляцией систем и процессов друг от друга, распараллеливанием разработки, деплоя и технических работ на разных участках проекта, повышением устойчивости систем к ошибкам, увеличением скорости работы проекта, сокращением таймингов служебных процессов.
Микросервисная архитектура позволила проходить пики нагрузки и падения производительности. Скорость загрузки страниц каталога уменьшилась с 3–4 секунд до 0,5 секунды. Скорость актуализации наличия товаров в зависимости от количества событий увеличилась с нескольких часов до нескольких минут.
Остальные проблемы были связаны с масштабированием команды разработки, с размером бэкапа, скоростью его развертывания, контролем над событиями в системе. Также из-за ускорения разработки появилась очередь из релизов.
За четыре года практически полностью перешли на распределенную информационную систему, где исходная CMS выполняет лишь небольшую роль на одном из десятков серверов и в перспективе полностью уйдет в прошлое.
Из чего состоит наша микросервисная архитектура
Создать идеально сбалансированную и выверенную архитектуру заранее невозможно, это всегда эволюционный процесс. Поэтому у нас строго поэтапное внедрение. Мы стараемся унифицировать инструменты и процессы, чтобы не раздувать энтропию проекта. При разработке мы учитываем изоляцию, расширяемость, масштабируемость, безопасность, быстродействие.
Основной язык, на котором написана наша архитектура, — Go. Классических БД в микросервисах практически нет. Там, где без них не обойтись, используем PostgreSQL в качестве холодного хранилища, а для горячего кеша — Redis. Также есть связка Go + Tarantool, которая прекрасно себя показала в качестве альтернативы классической БД.
В стеке также Linux, GitLab CI/CD, RabbitMQ, ElasticSearch. Выбор определялся доступностью технологий, документаций, активного развития и накопленной базы знаний, а также богатых возможностей конфигурации и автоматизации.
При разработке мы использовали виртуализацию, контейнеризацию, CI/CD, автотесты, линтеры, брокеры сообщений, REST API, репликацию и шардинг БД, NoSQL и In-Memory БД.
В нашей микросервисной архитектуре нет модулей как таковых. Мы используем сегменты. В рамках каждого из них действует сеть изолированных систем, которые выполняют одну задачу — например, отслеживают наличие товара. Сейчас таких систем десятки, а в скором времени счет пойдет на сотни. Сегменты изолированы и ничего «не знают» друг о друге.
С какими трудностями сталкиваемся
Переход к микросервисам чаще всего удается сделать плавным, но иногда в монолитах накапливаются большие связные участки, которые сложно разрывать небольшими частями. Одно тянет другое, и тогда количество сервисов, одновременно готовящихся к запуску, накапливается, что сильно усложняет запуск и отладку.
Например, выделяя каталог продукции в отдельный сервис, вместе с ним мы захватываем цены, остатки, резервы, действующие скидки и акции, рекомендации и поиск, рейтинги и оценки, отзывы и подборки, интеграции с маркетплейсами, аналитику. Все это — отдельные участки, за которые отвечают разные команды.
В каждом кусочке системы есть свое управление, обмены, импорты, отчеты, служебные процедуры контроля. Одновременно их выделить в сервисы невозможно, но и без них запускаться нельзя. Так формируется длинный релизный цикл из множества итераций с необходимостью обеспечивать одновременную работу как нового функционала, так и прежнего — для тех систем, которые еще не получили обновления.
Среди других трудностей, с которыми мы сталкиваемся, — несогласованность действий команд, рассинхронизация данных, контроль их целостности, внешние атаки на инфраструктуру, сохранение прозрачности архитектуры проекта при росте его сложности. Кроме прозрачности архитектуры проекта, заказчику важны показатели скорости работы, выдерживаемой проектом нагрузки и отсутствие сбоев. Решения по технической части полностью делегированы нам.
Обслуживанием серверов, мониторингом и сбором метрик занимается отдельная DevOps-команда в режиме 24/7. Они же настраивают автоматические уведомления об угрозах и возникших проблемах, которые приходят на почту и в телеграм дежурным. По каждой проблеме автоматически создается задача и назначаются ответственные, каждый кейс разбирается, и устраняются последствия.
Заключение
Микросервисы — это дороже, дольше и сложнее, чем монолит. Затраты значительно вырастают, но зато удается достичь нужных показателей, бизнес масштабируется, результаты быстро становятся осязаемыми. Благодаря миграции мы ускорили интернет-магазин, автоматизировали процессы, реализовали новые сложные сценарии учета продукции, резервов, интеграций с поставщиками, партнерами и внешними системами. Кроме того, повысили устойчивость системы к внешним и внутренним проблемам, ускорили разработку и техническую поддержку.
Проект непрерывно развивается, добавляется функционал, появляются новые виды данных, новые объемы информации, растет нагрузка. Большую часть работ по переходу на микросервисы мы запланировали на ближайший год, но, скорее всего, момент, когда можно будет «закончить переход», не наступит, пока проект живет и развивается.
