Хэндлим тему | Дерепко

💬 #Пост №3. Трассировка межсервисного общения

Трассировка запросов – это способ отслеживания запросов между сервисами.
Часто такая надобность появляется, когда система состоит из двух и более сервисов, которые взаимодействуют друг с другом.
Давайте представим, что мы имеем следующую конфигурацию нашей инфраструктуры:
- Продуктовое приложение с бекендом и фронтендом (Application)
- Сервис авторизации (Auth)

Помимо сервисов с бизнес логикой инфраструктура также имеет сборщик различных метрик и логов. Например, Sentry, Newrelic или любой другой сервис.

👤 Юзкейс

- Пользователь выполняет авторизацию в приложении.
- Продуктовое приложение в процессе обработки запроса собирает какие-то логи и отправляет их в систему логов (сборщик).
- Продуктовое приложение делает запрос в сервис авторизации.
- Сервис авторизации выполняет свою часть и так же отправляет собранные логи в сборщик.

🕵️‍♂️ Трассировка

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

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

В случае юзкейса выше можно на бекенде сгенерировать уникальный ID и передать его в запрос сервиса авторизации. Если используется HTTP, то отлично подойдет секция заголовков (Headers). Наиболее популярное имя такого хедера X-Request-Id.

В этом случае логер должен уметь захватывать этот ID из заголовков и отправлять его контекстом в сборщик логов, а http client отправлять этот ID в Headers других запросов.

Схематично это будет выглядеть так:
1. Запрос Frontend → Application
2. Application Boot. Парсинг или создание нового Request ID в какое-то локальное хранилище, которое в дальнейшем будет использоваться в Logger, HttpClient и других классах для обогащения контекста
3. Запрос Application → Auth
4. Такой же Application Boot, как в пункте №2

Теперь, когда пользователь сделает запрос в продуктовое приложение, мы сможем найти по ID все логи текущего приложения, http запросы в другие сервисы, их логи и дальнейшие запросы. Цепочка может не заканчиваться только на одном сервисе.

Например, цепочка может быть такой:

App -> Write logs; Call ID, Auth, Billing
  ID -> Write logs
  Auth -> Write logs; Call ID
    ID -> Write logs
  Billing -> Write logs, Call Auth
    Auth -> Write logs; Call ID
      ID -> Write logs

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

Помимо HTTP запросов можно так же маркировать сообщения в очередях, если они поддерживают подобие Headers.
Если нет, то можно в тело сообщения добавлять Request ID и уже после распаковки сообщения устанавливать глобальный Request ID для всего приложения.

ℹ️Для консольных команд, а также cron задач, тоже стоит сделать такой механизм.
Инициировать создание Request ID может не только продуктовое приложение, а любой из имеющихся сервисов: биллинг по вебхуку от внешних провайдеров, сервис коммуникаций по крону и так далее.

🏁Итоги

Таким образом, чтобы добавить трассировку межсервисной коммуникации, стоит добавить:
- Механизм генерации ID или получения его от внешних систем при начале работы приложения: http headers, queue headers, queue payload
- Обогатить контекст для подсистем, которые хочется мониторить или которые инициируют запросы в другие системы: http client, queue.

——

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

#Пост №2. Рекрутмент и накрутка опыта

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

——

Оставлю здесь выжимку своих мыслей по поводу “неточностей” в резюме 🙂

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

Телеграф: https://telegra.ph/Post-2-Rekrutment-i-nakrutka-opyta-11-15

#Пост №1. Introduction.

Приветы.

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

Меня зовут Дмитрий Дерепко. Живу в солнечном Тайланде, работаю разработчиком. В свободное время пытаюсь развиваться, ржу с мемов, из книг предпочитаю профессиональные, между роллами и пиццей – пицца.

Впервые прикоснулся к программированию лет в ~14, когда пытался настроить сервер в контре и поднять бот для аськи. Сейчас мне 26. Не скажу, что всё время осознанно писал код и развивался как программист, но много лет было посвящено веб разработке и около неё.

Еще немного фактов большими мазками:

- В 11 классе сделай школьный сайт, который еще работал пару месяцев назад, а сейчас всё 🙁
- Веб-мастерил на фрилансе, пока был в школе и универе
- Преподавал для детишек HTML, CSS и JS
- Законченный бакалавриат физфака со смесью IT, из магистратуры ушел
- Разработчик, который стал тимлидом и тимлид, который ушел в разработку
- Кодил на PHP, JS, Python, Go, Dart, C++, C# и всякое разное. Где-то больше и осознанно, где-то наоборот
- Написал три статьи в серии Yii Overview (раз, два, три)
- Уже месяц прокрастинирую и пытаюсь записать ролик на ютуб по старту вместе Yii 3 🙂
- Комичу в Open source, состою в тиме Yii 3

——

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

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

——

Кстати, в коментах можете написать написать о себе, чтобы я вас тоже знал.

Channel created