ReportPortal. Технический взгляд на развитие проекта

January 15, 2017 - 4 minute read -
ru tech

ReportPortal

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

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

Highly-coupled microservices

Новый, недавно изобретенный паттерн проектирования :). Заключается в том, что при переносе монолитной архитектуры в микросервисную, огромная часть функционала так и остается сильно\жестко связанной. Мы пока тоже на этом пути - много общих зависимостей между сервисами, невозможность скейлить некоторые из них и т.д. Радует то, что эта проблема очевидна не только мне, но и менеджменту, а значит будет постепенно фикситься не только моими одинокими вечерами за лэптопом :)

Service Registry

Идея, сама по себе, православная. Подход Gateway/Registry/Services дал нам возможность добавлять функциональность как плагины, плюс является хорошим заделом для инсталляции на продакшне - такая схема позволяет легко и удобно скейлить приложение, не заморачиваясь сильно с DevOps задачами. Но, к сожалению, выбранный технологический стек разочаровал. Сейчас ReportPortal крутится на Netflix OSS стеке - Eureka (Service Registry), Zuul (Gateway), Ribbon (Load Balancing Client). В целом основные претензии как раз к Eureka - очень долгая регистрация сервисов бесит людей, умершие инстансы сервисов временами остаются в регистре (вроде как пофикшено, но все равно на 110% гарантировать сложно), какое-то время после старта инстанса Zuul роутит траффик и почему-то возвращает HTTP 200, хотя сам сервис еще не отвечает, либо не зарегистрировался полностью. Плюс, как дополнительный эффект - все это написано на Java, а значит забирает кучу оперативной памяти, делая приложение черезчур тяжелым. В общем, даже не смотря на то, что все это работает относительно стабильно на нашем продакшне, впечатление так себе и фиксить текущие проблемы не особо-то и тянет. У Eureka сейчас основной конкурент Consul - это в контексте интеграции со Spring Cloud, на котором построена все экосистема проекта. Переключив все на consul был крайне удивлен - аптайм уменьшился в разы, инстансы регистрируются и убиваются моментально и без всяческих проблем. Вероятнее всего, какие-то проблемы все-таки вылезут при дотошном тестировании, на поддержка Consul однозначно появится в ReportPortal 3.0 релизе, пусть даже и не в виде дефолтного параметра.

Потребление ресурсов

Java, чет ее побери! Слово Java нужно законодательно запретить ставить в одно предложение со словом microservices. Даже не смотря на то, что ReportPortal ни разу пока не является микросервисным приложением. Некоторое время назад поигрался с Golang и был в полном шоке от того, насколько меньше системных ресурсов потребляет этот язык. К слову, это легко можно проследить, если запустить Eureka(который написан на Java) и Consul (который написан на Go). Например, обычный REST сервис, который ничего не делает, кроме как возвращает health-чеки, скушал у меня около 5мб оперативки и это уже будучи запакованным в контейнер! Например, наш UI сервис потребляет не менее 256. Ок, грубо спишем половину на кэш статики, но разница все равно более чем в 20 раз! Давайте немного посчитаем. У нас есть как минимум три сервиса, которые можно легко перевести на Go: Registry (меняем Eureka на Consul), Gateway (меняем Zuul, например, на Traefik), UI Service (тупо переписываем, ибо все пару классов). В итоге с каждого приложения экономим как минимум 200мб и получаем неплохой профит - 600 мб просто переконфигурировав систему!

Синхронный репортинг

Это проблема скорее, на клиентской стороне. И Java клиент (или “агент”, кому как больше нравится), в скором времени станет асинхронным. Тем не менее, с точки зрения сервера тоже есть что улучшить. Например, пост логов – вам 100% не нужен будет айди лога в респонсе, а посему эту операцию легко можно сделать асинхронной. Пришел запрос, сервер ответил чем-то типа “Окей, брат, Accepted”, вернул ответ клиенту и начал процессить в отдельном потоке. Но такой подход создает одну небольшую проблему: если лог по какой-то причине не может быть сохранен, то клиент никогда об этом не узнает, ведь сервер всегда сперва отвечает OK, а только потом начинает работу работать. Можно было бы это решить добавлением какой-то дополнительной коллекции в которой бы хранились ошибки всех асинхронных операций. Тогда человек смог бы время от времени открывать страничку и смотреть, все ли у него нормально репортится. Но это уже работа для UI команды, а значит, нужно добавлять эту задачу в спринт команды, планировать время, объяснять менеджерам зачем это нужно и т.д. Тем не менее, к такому подходу ReportPortal все равно придет и, опять же, скорее всего в ближайших релизах.

Синхронное взаимодействие UI и back-end портала

Long-pooling, черт побери! Чтобы вы видели динамику на своей страничке, UI каждые пару секунд делает одинаковые запросы на бэкэнд, тем на самым нагружая его. Не то, чтобы выборки были очень тяжелыми, но тем не менее - это далеко не самый лучших подход. Давно уже есть идея заменить long pooling на Server-Sent-Events или Websockets, т.е. ввести эвенты, давая серверу возможность самому говорить UI что изменилось. Это же решило бы проблему нотификации пользователя о том, что асинхронная операция (например, автоанализ), завершена.

Автоанализ

Хотелось, бы, конечно, улучшить имплементацию. Пока я вижу два пути это сделать:

  • Быстрый - добавляем ElasticSearch и отдаем всю работу по поиску подходящих ошибок туда. Как это сделано сейчас даже рассказывать не буду - смотрите сами :) На самом деле, ES не идеально подходит для такого рода задач, но попробовать стоит.
  • Длинный - Machine Learning. Пожалуй, идеальное решение. Вопрос только в том, что написание и обучение модели займет достаточно много времени и заставит углубиться в математику, которая для меня умерла в районе второго курса университета. К счастью, эту задачу делегировали в один из профильных отделов EPAM - что у них там получится - посмотрим.

А что хотели бы изменить Вы? Пишите в комментарии, на почту, в социальные сети - мне, как разработчику, очень интересно узнать ваш взгляд на продукт именно с технической точки зрения