Comments 14
Трассировка — то, без чего микросервисы нормально не живут. Но, честно говоря, даже в монолите это невероятно полезно.
Очередная микросервесная чушь, погуглите понятие точка остановы. Учите мат часть, потом учите других.
Мде, руководители нынче один лучше другого))
Пользователь, на проде, говорит - у меня не работает личный кабинет, ошибка 404 после перехода ( ну или просто говорит не работает). У всех остальных при этом работает.
Вы пойдете на прод, запустите в режиме отладки и попросите пользователя попробовать еще раз? Или снимите дамп и будете его разматывать?
Это в целом к любой архитектуре относится. А теперь берем микросервисную или сервисную и у вас цепочка вызовов между сервиса, их например три. В одновременно откроете три IDEA и тоже самое будете делать ручками?
Причём тут вообще что монолиту это ТОЖЕ будет полезно? Это используется уже сто лет до ваших микроштучек. Все пытаетесь микросервисам приписать несуществующие плюсы своими микрорешениям
Причём тут вообще что монолиту это ТОЖЕ будет полезно?
Потому что трассировка как универсальный инструмент полезна независимо от места использования.
Вот у вас есть условный ID запроса. С продуктива.
Вам надо пройти пошагово и понять, к примеру почему он выполнялся 100мс а не 50мс. Вот Вам и трассировка в помощь, если в коде все правильно по данным в Jaeger (к примеру) все будет видно, куда, что, сколько.
Годно. Только непонятна связь с PHP и Ruby
Вопрос, а что если поднять тестовый контур, с базой, кафкой прям весь? И всё тестировать через него? Всегда.
Сильно зависит от размера команды и проекта. Потому что кажется что самый простой путь, но он приводит к тому что окружение постоянно надо чинить и приводить в порядок. Если проект не большой, то это не сложно делать (иногда даже может быть полезно, если у вас там данные боевые).
По моему опыту - после появляется одного теста, появляется еще несколько тестовых площадок. Потом еще и еще, а потом ты даже не можешь нормально ручками что-то протестить, не то что автотест прогнать - тут один функционал, не трогай, тут другой ждет фиксов и следующего релиза. И в итоге команда скидывает большое количество времени на поддержание окружений. Это я еще кстати не говорю о том что часто бывает для како-то тестирования специально подготовить площадку, а после тестов удалить.
Может быть еще компромисс, когда мы на ветку автоматически поднимаем площадку только с нашим сервисом (в Gitlab есть такая штука, называется Environments) и тестируем его изолированно, после тестов удаляем. Зависимости не поднимаем (имею ввиду зависимые сервисы). Но это все равно будет дольше чем прогнать 100 тестов в testcontainers.
Если же у нас просто проект, зависимостей практически нет, работает микро-команда, то вполне себе быстрое решение.
По-моему очень полезно, без лишнего "мыслией по дереву"
Толковая публикация, коротко и по делу - спасибо !
Очень хорошо. У нас в компании core team написала стандартные решения для логирования, метрик, трейсинга и т.д. Утилиту которая создаёт проект с предустановленными настройками и ещё много всяких полезностей. Реализовано "из коробки" почти все что изложено в этой статье
Генератор проекта или просто репозиторий, который клонируют? Я поке репу внутреннюю сделал, но хочу сделать генератор. Пока думаю как сделать, как упаковать динамические части что бы было удобно.
Интересно еще как обновление реализовано (если в генераторе например вносятся изменения в пакет с трейсингом).
Генератор проекта. По шагам
Что-то типа:
Введите название
Выберите язык программирования
Введите ответственного
Используете ли redis
Используете ли postgres
И т.д.
Далее создаётся базовый шаблон, в который уже включены внутренние библиотеки (обертки над стандартными типа slog) метрик, логирования, трейсинга и т.д.
Настроено таким образом что даже не надо например прописывать эндпоинты для прода, так как они подхватываются из констант которые уже прописаны в конфигах CI/CD
А шаблоне main уже есть graceful shutdown, можно даже автоматом подтянуть контакты других сервисов, которые указаны как зависимости на этапе инициализации.
Есть Makefile с базовыми командами и можно даже сразу же сгенерить sdk и запустить grpc сервер с тестовым hello world контактом.
В общем бери и работай )) разберётся даже джун
Минимальный набор практик для микросервиса