GetAnalyst - Навыки • Системный анализ • Бизнес-анализ – Telegram
GetAnalyst - Навыки • Системный анализ • Бизнес-анализ
19.5K subscribers
2.09K photos
74 videos
203 files
1.19K links
Разбор задач на проектирование систем 🚀 Канал для системных аналитиков, бизнес-аналитиков, тестировщиков и менеджеров проектов

Админ @getanalyst
Сайт https://getanalyst.ru
Чат t.me/getanalystchat
Начинающим в IT @getanalyststart

РКН №5013005196
Download Telegram
🔵 С4 - нотация моделирования для схем архитектуры 🔵

Можешь показать схему архитектуры системы в виде прямоугольников и стрелочек? Отлично!

Но если в отрасли есть стандарты, лучше использовать их.

Предлагаю познакомиться с нотацией моделирования архитектуры C4 👇


C4 помогает представлять архитектуру системы в виде 4-х уровней:

👉 Контекст (C4/Context)
Система, её интеграции и пользователи.
✔️ Главный прямоугольник - наша система
✔️ Серые прямоугольники - внешние
✔️ Пользователи

👩‍💻 Полезна бизнес- и техническим специалистам


👉 Контейнер (C4/Container)
Независимые по коду приложения в системе, детализация главного прямоугольника c C4 / Context.
✔️ Пользователи и внешние системы с уровня C4 / Context
✔️ Мобильные, веб- и десктоп приложения
✔️ Сервер-приложения: монолит, сервисы, микросервисы, API Gateway
✔️ Базы данных и файловые хранилища
✔️ Виды API
✔️ Технологии (языки программирования, СУБД, протоколы для API и др)
✔️ Базы данных и файловые хранилища
✔️ Очереди и брокеры
Схему удобнее использовать в адаптированном виде, когда на этом уровне не показывают сервисы и микросервисы, а переносят их на уровень глубже - C4 / Component. Иначе она очень перегружена.

👩‍💻 Полезна архитекторам, разработчикам и системным аналитикам.


👉 Компонент (C4/Component)
Модули кода и зависимости между ними.
Детализирует один из контейнеров с C4 / Container.
На каждый контейнер своя схема.
Отлично подходит для детализации модульного монолита.


👉 Код (C4/Code)
На этом уровне детализируют каждый компонент c C4/ Component, показывая его реализацию в коде. Обычно это UML-диаграмма классов или другая визуализация.


Материалы:
🔗 Официальный сайт C4
🔗 Пример архитектуры C4 в Miro
🔗 Нотация С4 — примеры диаграмм и инструменты

Основные инструменты:
🔗 Draw.io
🔗 Structurizr

Примеры схем:

🔗 RideFlow - заказ такси
🔗 TelMed - телемедицина
🔗 BookingGA - аренда недвижимости (МСА с брокерами)
🔗 GreenChargeGA - зарядки для электроавто (МСА с брокерами)


Элементы нотации с пояснениями в картинках к посту 🙌

#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥246👍5
Очередь vs Брокер: вопросы к собеседованиям с подвохом

Очередь сообщений — это структура данных,

которая хранит сообщения до тех пор, пока их не заберёт получатель.

Брокер сообщений — это программное обеспечение,
которое управляет обменом сообщений между приложениями.
Он может включать в себя множество очередей сообщений и дополнительно поддерживать топики, маршрутизацию, обработку и механизмы гарантии доставки.


Вопросы с подвохом, которые вы можете встретить на собеседованиях для Middle+ Системного аналитика:

👉 1. Если у нас есть очередь сообщений, зачем нужен брокер?

👉 2. Может ли очередь работать без брокера?

👉 3. Могу ли я использовать брокер без очередей сообщений?

👉 4. Если я использую очередь сообщений, могу ли я гарантировать доставку сообщения?

👉 5. Очередь всегда работает по принципу FIFO (первое пришло - первое вышло из очереди)?

👉 6. Может ли очередь работать с несколькими производителями и потребителями?


Подробная статья:
🔗 Брокер и очередь сообщений: что это и в чем отличия?


#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
20👍7❤‍🔥1
💬 Всё про брокеры: как работают и зачем нужны 💬

Брокеры
— это посредники в передаче сообщений между системами или сервисами.

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


👉 Принцип работы:

1. Сервис 1 (Producer/ Производитель) хочет отправить данные в Сервис 2 (Consumer/ Потребитель).

2. Сервис 2 в это время может быть перегружен или занят.

3. Чтобы Сервис 1 не ждал, пока Сервис 2 станет доступен, он кладет сообщение в Брокер и продолжает свою работу.

4. Брокер сохраняет сообщение и ставит его в очередь к обработке.

5. Как только Сервис 2 становится доступен, то он забирает сообщение из Брокера и обрабатывает его.


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



👉 Брокеры могут использоваться:
+ в сервисной и микросервисной архитектуре (хореография),
+ в событийно-ориентированной архитектуре (EDA),
+ когда нужна фоновая обработка событий в монолите,
+ для асинхронных интеграций.


👉 Брокеры сообщений предлагают два основных шаблона обмена данными:

1. Точка-точка (Point-to-Point Messaging)
Это паттерн, используемый в очередях сообщений, где существует один отправитель и один получатель. Каждое сообщение в очереди отправляется только одному получателю и может быть обработано только один раз.

2. Публикация-подписка (Publish/Subscribe)
В этом паттерне отправитель (producer) публикует сообщения в определённую тему (topic), а подписчики (consumers) подписываются на темы, чтобы получать сообщения.
Все сообщения, опубликованные в теме, доставляются всем приложениям, подписанным на неё.
Применяется в случаях, где несколько систем должны получить одну и ту же информацию.


Возможности и логика работы брокеров отличаются в зависимости от конкретного решения.

Основные решения по брокерам на рынке:
Apache Kafka
RabbitMQ
ActiveMQ
Amazon MQ, Amazon SQS
Яндекс Message Queue (YMQ) - аналог Amazon
и другие.

#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
18👍9🔥6❤‍🔥1👌1
🕺Хореография микросервисов - детальный разбор с примером 💃

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


Каждый сервис знает только:
▫️ какие события он слушает,
▫️ что делает при их получении,
▫️ какие события публикует дальше.


👉 Интеграция сервисов в таком подходе в основном асинхронная, через брокер сообщений (Kafka, RabbitMQ) / event bus.


👉 Пример хореографии
Оформления заказа с привязанной карты в сервисе доставки еды


🟡 Запуск хореографии:
Пользователь нажимает "Оформить заказ" в web-приложении:

1. Приложение отправляет запрос на API Gateway

2. API Gateway проверяет авторизацию и маршрутизирует заказ в Сервис Заказов

3. Сервис Заказов:
+ обновляет статус заказа в БД на "Ожидает оплаты"
+ публикует событие в Брокер Kafka - "Заказ подтверждён"
❗️ Деньги с пользователя не списаны

4. Сервис Заказов возвращает ответ на API Gateway.

5. API Gateway возвращает ответ с инфо о заказе на web-приложение, где показываем пользователю сообщение "Заказ принят"


🟡 Асинхронная работа - хореография:
Запускается параллельный поток событий. Frontend и пользователь могут идти по своим делам.

1. Сервис Платежи (далее - С) читает событие "Ожидает оплаты" из Kafka и запускает логику списания денег с карты пользователя.

2. Платежи публикует событие "Платеж упешен" в Kafka.


Параллельно:
----
3А. С Уведомлений читает событие "Платеж упешен" из Kafka и отправляет push+sms пользователю

3C. С Заказов читает событие "Платеж упешен" из Kafka и меняет его статус в своей БД на "Оплачен"

3B. Рестораны читает событие "Платеж упешен" и проверяет:
+ кухня не перегружена?
+ доступность блюд?
+ время работы и т.п.

4. Если ок, то С Рестораны публикует событие "Заказ подтверждён".
----

Параллельно:
4А. С Уведомлений читает "Заказ подтверждён"..
4C. С Заказы читает "Заказ подтверждён"..
4B. С Курьеры читает "Заказ подтверждён"..


Далее на картинке к посту 🖼

- конец процесса


#АрхитектураGA #FoodDeliveryGA
20❤‍🔥7🔥3
🔥 7 вопросов с подвохом по Архитектуре: хореография микросервисов + понимание брокеров в EDA 🔥


1️⃣ Когда хореография микросервисов хуже оркестрации?

✔️ Сложные линейные бизнес-процессы с кучей условий (сложный онбординг, платежные цепочки, обращения тех поддержки и др)

✔️ Надо явно видеть шаги процесса и управлять им

✔️ Когда важны SLA и время на выполнение шагов

В таких случаях удобнее, когда:
+ есть компонент, который явно хранит состояние процесса
+ видно “шаги” и переходы по ним
С этим помогает оркестрация.




2️⃣ Сервис записал данные в свою БД, но упал до публикации события. Что произойдёт в хореографии и как это чинить?

Многие говорят «ретраи к брокеру» (повторные запросы) и всё. Но это лишь часть ответа.

Ситуация:
Обработка данных на микросервисе прошла, но событие в брокер не опубликовано → остальные сервисы никогда не узнают об изменении.


Решение:
Transactional Outbox / Outbox pattern:
В одной транзакции к БД с бизнес-данными пишем запись в специальную outbox-таблицу.

Отдельный воркер (фоновый процесс) читает из outbox и публикует событие в брокер, с ретраями.

Также иногда используют Change Data Capture (CDC) по БД - отслеживание изменений.




3️⃣ Как в хореографии реализовать шаг, который зависит сразу от двух событий из разных сервисов?
Например: бонус начисляем только если есть "пользователь зарегистрирован" и "оплачен первый заказ"?

Нужен агрегатор/process manager (отдельный сервис/Kafka Streams и др), который:
+ хранит состояние двух параметров: userId - , orderId
+ пришло первое событие — пометили “жду второе”
+ пришло второе — выполняем действие (начисляем бонус)

Это уже кусочек оркестрации, спрятанный внутри одного сервиса.

Также нужно учесть что делать, если второе событие не пришло.




4️⃣ Как в хореографии реализовать таймаут шага?
Например, оплата должна пройти за 15 минут, иначе заказ отменяем.

Используется process manager / timeout-сервис / scheduler:

1. При старте процесса публикуется событие "оплата началась"

2. Параллельно где-то создаётся “таймер” на 15 минут (например, Cron)

3. Если за 15 минут не пришло событие "Платеж успешен" / "Ошибка оплаты":
+ таймер генерирует событие "Ошибка таймаута по платежу",
+ другие сервисы реагируют: отменяют заказ, снимают резерв и т.п.

Важно понять: управление интервалами времени в работе процесса не решается «само по себе» брокером — нужен компонент, который хранит состояние ожидания.



5️⃣ Биллинг слушает событие "Заказ оплачен" и должен списать деньги ровно один раз. Любое сообщение может прийти дважды. Как вы гарантируете отсутствие двойного списания?

Ошибочный ответ:
«брокер гарантирует доставку ровно один раз»

Реализуем проверки на уровне потребителя события:
+ идемпотентность операций: бизнес-ключ (orderId + paymentId)
+ уникальность в БД на этот ключ
+ таблица processed_messages с messageId и состоянием.



6️⃣ Можно ли построить систему только на хореографии, без оркестрации?

В теории — можно, но:
+ всё равно появятся сервисы-агрегаторы / процесс-менеджеры / scheduler’ы, которые управляют процессами
+ как только один сервис начинает хранить состояние процесса и ждать другие события, он выполняет роль локального оркестратора.

Более правильный ответ: в реальных системах почти всегда смесь подходов хореографии и оркестрации.



7️⃣ Вы добавляете новый микросервис в существующую хореографию процессов. Как сделать так, чтобы он не поломал остальных, когда начнёт слушать существующие события?

Новый сервис должен быть пассивным наблюдателем:
+ слушает существующие события без изменения процесса их работы
+ никакие его действия не должны влиять на текущие цепочки по процессам

Важно:
+ не добавлять обязательные поля в существующие события (сообщения), которые отправляем в брокер
+ не менять JSON (формат сообщений) уже используемых событий
+ если нужно другое поведение — вводить новые типы событий, а не менять старые.



А какие ещё вопросы по брокерам и хореографии вы встречали на собеседованиях на СА? Делитесь в комментариях ✍️


#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥316❤‍🔥2👍2🤩1
GetAnalyst_Kafka_8_шагов_чтобы_разобраться.png
522.6 KB
🚀 8 шагов, чтобы разобраться с брокером Kafka 🚀

1️⃣ Что такое Kafka?
2️⃣ Сообщения в Kafka
3️⃣ Topics & Partitions
4️⃣ Kafka Producer
5️⃣ Kafka Consumer
6️⃣ Kafka Cluster
7️⃣ Сценарии использования Kafka


🎱 Подробнее про Kafka в подкасте GetAnalyst
🔗 Kafka: что нужно знать Системному аналитику


Сохраняйте схему в личный архив.
Это идеальный чек-лист для подготовки к собеседованиям

#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23❤‍🔥7👍43👎1
📚👩‍💻 Доступ к бесплатному обучению по Архитектуре открыт 👩‍💻📚

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

💎 Хореография и оркестрация микросервисов: практика проектирования процессов

🗓 Доступ до 2 декабря [вт]
🕘 ~4 часа, смотрете в удобное время

🔗 Зарегистрироваться


👉 План:
1. Основы архитектуры: монолит и микросервисы
2. Разработка схемы архитектуры
3. Оркестрация процессов: практика
4. Введение в брокеры сообщений (RabbitMQ, Kafka)
5. Хореография процессов: практика


👉 Это не типичный демо-урок, а полноформатное практическое обучение, после которого вы получите реальные инструменты и знания для работы.

Планируйте слот в календаре и смотрите его, пока доступ открыт 🙌

-----
Этот открытый урок - вводное занятие к практической программе Проектирование архитектуры для системных аналитиков
-----

Вопрос? Пишите @getanalyst или info@getanalyst.ru 🤝
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥167
Последние месяцы я минимум по 10 часов в неделю учусь - лучший технический университет США прокачивает меня в Generative AI. На прошлой неделе, например, разбиралась с библиотеками в Python для обучения LLM-моделей и работы с NLP.

А параллельно с этим я работаю над AI-Акселератором для аналитиков.

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


Программа по AI для аналитиков — это не база про ChatGPT.
Я собираю весь тот опыт, который получила за последние 3 года учёбы и работы:
+ принципы работы нейросетей,
+ что надо знать, прежде чем их использовать,
+ как безопасно встроить AI в свою работу,
+ инструменты,
+ развертывание локальных LLM,
+ интеграции по API,
+ автоматизация процессов через low code,
+ где AI реально экономит время, а где только создаёт иллюзию продуктивности.

Мой перфекционист в восторге от содержания 🫠


Для меня это особенно вдохновляющий период в GetAnalyst:

🔹 Мне удалось привлечь экспертов из США, которые делают ревью материалов по отдельным урокам и помогают докрутить контент

🔹 В курсе будут занятия, записанные специально для GetAnalyst экспертом по AI из Стэнфорда

🔹 Много практики, разбор ошибок и лайфхаки


Этот год я сознательно посвятила обучению, чтобы сместить фокус на AI-проекты и работать с новыми клиентами на разработку.
И сейчас искренне рада, что могу делиться своим опытом с вами.

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


Так что да, я сейчас тону в презентациях, схемах, записях…

Но именно это зажигает искру и даёт ощущение сильной мотивации и радости 💙
🔥7221❤‍🔥4🤔3😍2
🐇 Брокер RabbitMQ - полный гайд с разбором примера использования в микросервисной архитектуре 🐇

1. Что такое RabbitMQ и зачем он нужен
2. Как работает RabbitMQ
3. Очереди, обменники (exchange), routing и binding key - ключевая терминология и внутреннее устройство брокера
4. Типы обменников: direct, fanout, topic, headers
5. Пошаговый разбор примера использования RabbitMQ в микросервисной архитектуре

Подробно разбирали брокер в подкасте:
🎧 RabbitMQ и его отличия от Kafka: что важно знать системным аналитикам

Сохраняйте в закладки и делитесь с коллегами 🔖

#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
27🔥16❤‍🔥15😍2👍1