🚩Кейс: поиск проблемного участка в распределенной системе.

Вспомните, как иногда тяжело найти тот самый микросервис, который вернул вам неверный результат.
Долгие выяснения "кто виноват" между командами разработки и часы поиска нужного сообщения в логах. 🤬

На выходных заканчивал подготовку модулей для тарифа "Senior" по системным интеграциям и решил поделиться с вами фрагментом из модуля по observability.

❗️В нем рассказываю, как повысить observability системы и упростить поиск багов в больших распределенных системах с помощью трассировки между сервисами.

Системный анализ | Дмитрий Помаскин

‼️ Курс "Системные интеграции" полностью открыт‼️

Немного позже, чем я планировал, но курс по интеграциям, наконец-то, готов полностью.

Напомню, что на нём вместо классических тарифов я предлагаю три гибких варианта, которые открывают доступ к модулям поэтапно.

Junior (12 890 ₽)
✅ Введение в системные интеграции;
✅ Форматы данных в интеграциях;
✅ REST / SOAP / GraphQL;
✅ Интеграционные шины.

Middle (22 480 ₽)
✅ Все модули из тарифа Junior;
✅ Брокеры сообщений;
✅ RPC (Remote Procedure Call);
✅ Real-time взаимодействие (WS, Long Polling, SSE).

Senior (38 790 ₽)
✅ Все модули из тарифов Junior и Middle;
✅ Интеграция на уровне БД;
✅ Безопасность в интеграциях;
✅ Паттерн Circuit Breaker;
✅ Observability (Наблюдаемость) интеграций;
✅ API-first подход, Swagger и AsyncApi.

❗️Скидка 15% по промокоду SYSTEMINT на все тарифы действует последние 24 часа.

Записаться можно тут :)

Системный анализ | Дмитрий Помаскин

❗️Освободился один слот на интенсив в группу 20.07 12:00, запись тут❗️
UPD: слот заняли.

❓ Stateless vs Statefull (Не спешите пролистывать, проверьте знания)

ℹ️ Состояние (state) — это любые данные, которые компонент должен запомнить между запросами или операциями, чтобы обеспечить корректную работу системы.

✅ Stateless — любой компонент системы, который не сохраняет состояние.
Пример: сервис подготовки печатных форм, который формирует документ по полученным на вход параметрам и шаблону.

✅ Statefull — любой компонент системы, который сохраняет состояние.
Пример: база данных.

Всё кажется очень просто, но давайте проверим, правильно ли вы понимаете разницу на примере.

Опрос ниже👇

P.S. Гуглить или пользоваться нейросетями — мышиный поступок :)

Системный анализ | Дмитрий Помаскин

❗️Правильный ответ на вчерашний вопрос❗️

Сервис будет stateless, так как он сам не хранит никакого состояния, при этом база данных под ним будет statefull.

Усложним задачу:
Теперь сервис помимо REST API имеет web-socket соединение со всеми клиентами для отправки им уведомлений. Соединение устанавливается один раз и держится, пока клиент находится в системе.

Останется ли такой сервис stateless или он станет statefull?

Опрос ниже👇

Системный анализ | Дмитрий Помаскин

❗️Ответ про сервис с web-socket❗️

Сервис станет statefull. Для того, чтобы отправлять уведомления пользователям, ему необходимо хранить состояния открытых web-socket соединений.

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

P.S. Дальше усложнять не будем, потому что пятница. Всем хороших выходных :)

Системный анализ | Дмитрий Помаскин

❗️Новый цикл видео, который будет посвящен микросервисам❗️

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

❓В чем отличие сервиса от микросервиса?

1️⃣ Сервис решает несколько связанных задач в одной бизнес-области, а микросервис выполняет только одну бизнес-задачу.

2️⃣ В service-oriented подходе часто встречается использование общей базы данных на несколько сервисов. В микросервисах принято придерживаться подхода database-per-service, то есть у каждого микросервиса своя база данных.

⚠️ Также вы, возможно, слышали, что сервисы взаимодействуют через интеграционную шину, а микросервисы через REST API и брокеры.

Действительно, в service-oriented часто использовались шины данных, но если вы своему сервису сделаете REST API и начнёте взаимодействовать с ним через него вместо шины данных, то он не станет микросервисом. Поэтому это отличие достаточно спорное.

Системный анализ | Дмитрий Помаскин

Провели первую волну практических интенсивов. 😎

В основном всё прошло по плану😃

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

Все большие молодцы!💪

Под этим постом можете поделиться своим впечатлением :)

P.S. Уже завтра в 18:00 по МСК будет доступна запись на все интенсивы августа, об открытии сообщу отдельным постом.

Системный анализ | Дмитрий Помаскин

‼️Открыта запись на практический интенсив по БД‼️

Тема: Базы данных.
Уровень: С нуля.
Кол-во участников: до 5.
Длительность: ~4 часа.
Программа:
✅ Типы баз данных;
✅ Проектирование БД;
✅ Описание БД с помощью ER-диаграммы;
✅ Нормализация;
✅ Базовый SQL для аналитиков.

Практика:
✅ Самостоятельное проектирование БД для сервиса;
✅ Описание этой БД с помощью ER-диаграммы;
✅ Написание SQL-запросов.

👉 Для записи переходите по ссылке.

Системный анализ | Дмитрий Помаскин

‼️Открыта запись на практический интенсив по REST API‼️

Тема: Проектирование REST API.
Уровень: junior.
Требуемые навыки: Умение читать ER-диаграмму.
Кол-во участников: до 4.
Длительность: ~3.5 часа.
Программа:
✅ Форматы данных;
✅ HTTP-методы и их свойства;
✅ REST и RESTfull;
✅ Обработка ошибок в синхронных интеграциях.

Практика:
✅ Проектирование REST API для нового сервиса;
✅ Внедрение пагинации и фильтрации;
✅ Swagger;
✅ Postman.

👉 Для записи переходите по ссылке.

Системный анализ | Дмитрий Помаскин

‼️Открыта запись на практический интенсив по брокерам сообщений‼️

Тема: Брокеры сообщений.
Уровень: Middle.
Требуемые навыки: Понимание принципов работы распределённых систем.
Кол-во участников: до 4.
Длительность: ~3.5 часа.
Программа:
✅ Типы брокеров (модель обмена, гарантия доставки, умные/глупые брокеры);
✅ RabbitMQ;
✅ ApacheKafka;
✅ Transaсtional outbox;
✅ Обработка ошибок в асинхронных интеграциях.

Практика:
✅ Внедрение брокеров в распределенную систему;
✅ Описание формата взаимодействия.

👉 Для записи переходите по ссылке.

Системный анализ | Дмитрий Помаскин

🗓 Расписание всех интенсивов на август 🗓

🔸03.08 12:00 МСК (Воскресенье) — Проектирование REST API;
🔸04.08 19:00 МСК (Понедельник) — Базы данных;
🔸11.08 19:00 МСК (Понедельник) — Проектирование REST API;
🔸24.08 12:00 МСК (Воскресенье) — Брокеры сообщений;
🔸25.08 19:00 МСК (Понедельник) — Брокеры сообщений.

Подробная информация о программах в постах выше ☝️

Для тех, кто не понимает, о каких интенсивах речь, подробности тут.

Системный анализ | Дмитрий Помаскин

❓До какого уровня стоит декомпозировать систему на микросервисы?

❌ Не стоит делать этого интуитивно, привязываясь к технологиям или бизнес-процессам.

✅ Моя концепция — декомпозировать систему до уровня одной транзакции. Как только вы понимаете, что дальнейшая декомпозиция приведёт к распределенным транзакциям в вашей системе, то стоит остановиться. Таким образом, вы сможете избежать проблем согласованности данных и внедрения сложных механизмов для работы с распределенными транзакциями, такими как SAGA.

P.S. Это, конечно, не серебряная пуля, но большинство кейсов однозначно покрывает.

Системный анализ | Дмитрий Помаскин

🚩Ошибка проектирования: нарушение принципа независимости микросервисов.

❌ Если для обработки запроса вашему сервису необходимо обратиться в другие сервисы, то это может привести к каскадным сбоям системы. Плюс, такая модель создает жёсткую связность.

✅ Агрегация данных, полученных из нескольких сервисов на клиенте.
Такой подход можно использовать, когда нет необходимости в серверной фильтрации или пагинации.

✅ Реализация промежуточного сервиса для предварительной агрегации данных.
При таком подходе запрос на получение данных приходит только в один сервис, на котором вы сможете реализовать серверную фильтрацию и пагинацию при больших объемах данных.

👇Ниже приложу схемы для наглядности👇

Системный анализ | Дмитрий Помаскин