В нашей компании мы активно используем микросервисы.
В этой статье опишу проблемы, с которыми мы столкнулись при настройке CI для микросервисов, и пути их решения. Для начала рассмотрим несколько ограничений:
Мы имеем 2 инстанса GitLab-а:
один для разработки продуктов нашей команды (соответствует закону Конвея). второй общий для всех команд. Репозитории микросервисов делятся на 2 типа:
с одним микросервисом, расположенным в корне. с несколькими микросервисами, в таком случае для каждого из них мы создаем директорию соответствующую названию сервиса в корне репозитория.
Была зима 2015 год, наша команда разработки переписывала монолит на микросервисы. В результате бурного обсуждения будущего развития архитектуры мы сделали вывод: мы не знали как был устроен монолит раньше, но в ходе reverse engineering-а выяснили и смогли научиться с ним жить и даже переписали часть на микросервисы. Мы знаем как новые сервисы связаны между собой, спасибо документации, но столкнулись с тем, что не знаем в каких конкретно случаях они вызываются и в какой последовательности, ведь на один запрос от пользователя внутри мы могли совершить несколько вызовов к другим микросервисам, а те к следующим.
Основная цель данной статьи познакомить вас с особенностями работы как серверной, так и клиентской части Sentry.
Sentry является Open source проектом мониторинга ошибок, можно использовать как SaaS, так и self-hosted. Основное его преимущество в том, что он группирует множество одинаковых ошибок, в терминологии sentry - событий, в один агрегат. Рассмотрим как устроен данный инструмент:
Сам Sentry написан на Django, для работы с очередями использутся Celery (Redis или RabbitMQ), планируется переход на Kafka, в качестве хранилища - Postgres.
Многие начинающие тимлиды замыкают рабочий процесс на себе. Причин может быть масса. Например, мне казалось, что команда может сделать что-то не так, или кто-нибудь плохо проверил задачу, или реализовал фичу без возможности расширения. Помимо замыкания новых обязанностей на себе, может оказаться, что некоторые участники команды начинают пренебрежительно относиться к своим должностным обязанностям, проявляется это чаще всего в низкой вовлеченности и безответственности.
Незаметно для себя тимлид становится узким горлышком. Спустя какое-то время приходит осознание, что нужно изменить подход к работе, т.