Говорят, идеальных мужчин не существует 👀
Это не так. Просто они бывают очень разными, и каждый по-своему сильный и прекрасный.
Кто-то сидит за ноутбуком и решает то, что для других выглядит как «что вообще происходит?» 😏
Кто-то держит на себе семью, работу, ответственность и слово.
👉 Мужчины — это про опору.
Про силу, интеллект, юмор, собранность и поступки.
Про умение защитить, поддержать, решить проблему и не потеряться в сложный момент.
И да, отдельно хочется выделить мужчин из IT ❤️🔥
👉 с вами всегда есть о чем поговорить - от жизни до технологий,
👉 и вам правда всегда хочется принести что-нибудь вкусное к компьютеру, пока вы заняты своими важными делами 🍪🍕🥗
Спасибо вам, мужчины, что вы есть.
За заботу, надежность, характер и то самое ощущение: «рядом — настоящий мужчина»!
Вы такие везде, как в работе, так и в жизни!
С 23 Февраля! Очень вами гордимся! 💙
👉 Девушки, давайте поздравим наших коллег-мужчин ❤️🔥❤️🔥❤️🔥 под этим постом + в комментариях 😊
С добром и теплом,
Екатерина Ананьева,
и команда GetAnalyst
Это не так. Просто они бывают очень разными, и каждый по-своему сильный и прекрасный.
Кто-то сидит за ноутбуком и решает то, что для других выглядит как «что вообще происходит?» 😏
Кто-то держит на себе семью, работу, ответственность и слово.
👉 Мужчины — это про опору.
Про силу, интеллект, юмор, собранность и поступки.
Про умение защитить, поддержать, решить проблему и не потеряться в сложный момент.
И да, отдельно хочется выделить мужчин из IT ❤️🔥
👉 с вами всегда есть о чем поговорить - от жизни до технологий,
👉 и вам правда всегда хочется принести что-нибудь вкусное к компьютеру, пока вы заняты своими важными делами 🍪🍕🥗
Спасибо вам, мужчины, что вы есть.
За заботу, надежность, характер и то самое ощущение: «рядом — настоящий мужчина»!
Вы такие везде, как в работе, так и в жизни!
С 23 Февраля! Очень вами гордимся! 💙
👉 Девушки, давайте поздравим наших коллег-мужчин ❤️🔥❤️🔥❤️🔥 под этим постом + в комментариях 😊
С добром и теплом,
Екатерина Ананьева,
и команда GetAnalyst
❤🔥53❤24🔥8😁1
This media is not supported in your browser
VIEW IN TELEGRAM
API Gateway (API-шлюз) — это единая точка входа для всех клиентских запросов к Backend.
Обычно используется в микросервисной архитектуре.
👉 Его главная функция — маршрутизация запросов.
Но, помимо этого, API Gateway предоставляет и другие важные функции.
Давайте последовательно разберём как он работает:
1️⃣ Первичная обработка запроса
Клиент отправляет запрос в API Gateway, а не напрямую к сервисам. Это обеспечивает централизованную точку входа в систему, а также упрощает интеграцию для клиента.
2️⃣ Валидация запроса
API Gateway проверяет корректность запроса.
Если формат нарушен — запрос отклоняется.
3️⃣ Проверка безопасности
Выполняется проверка по спискам разрешённых (allow-list) и запрещённых (deny-list) источников. Небезопасные запросы блокируются.
4️⃣ Аутентификация и авторизация
Проверяет токены и другие учетные данные. Гарантирует, что у клиента есть необходимые разрешения для доступа к запрашиваемым ресурсам.
5️⃣ Ограничение частоты запросов (Rate Limiting)
Если клиент превышает лимит запросов — они отклоняются с соответствующим ответом.
6️⃣ Маршрутизация к нужному сервису
На основе пути или других признаков API-шлюз определяет, какому микросервису должен быть направлен запрос.
7️⃣ Преобразование протоколов
При необходимости, преобразует запрос в нужный формат.
Например, если API Gateway принимает запрос в HTTP (REST API), то он может преобразовать его в gRPC для внутреннего микросервиса.
8️⃣ Агрегация ответов
Если ответ зависит от нескольких микросервисов, API Gateway собирает данные с каждого и формирует единый ответ.
9️⃣ Возврат ответа клиенту
Сформированный ответ возвращается клиенту в нужном формате и в установленный тайм-ауты.
🔟 Логирование, мониторинг, обработка ошибок и кэширование
На протяжении всего процесса обработки запроса.
❗️ Это такой же микросервис, как и сервис авторизации, сервис платежей и другие сервисы системы. На картинке к посту его можно также показывать синим прямоугольником.
API Gateway упрощает взаимодействие клиентов с распределённой системой и обеспечивает её безопасную и управляемую работу, выступая в роли централизованной точки входа.
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥32❤9👍2🤔1
🗂 Практикум по БД и SQL - новый проект [2 марта, 19:00 Мск] 🚀
Весна — время вдохновения, роста и энергии. А ещё — отличное время для новых проектов! 🌸
👉 У нас стартует новая серия продвинутых практикумов по БД и SQL на 8 занятий, с новым проектом.
Первое занятие пройдёт уже в следующий понедельник:
📚 Проектирование БД с нуля: создание ER-диаграммы
🗓 2 марта (пн), 19:00 Мск
🔗 Подробности и запись
Для тех, кто подключается сейчас:
✅ доступна запись занятия по продвинутым запросам в SQL
✅ в чт откроем подготовительные материалы к занятию
🎁 Скидка -15% по промокоду ВЕСНА2026 в честь нового проекта 🙌
Можно подключаться как на одно занятие, так и на всю серию из 8 занятий.
Будем рады видеть вас на новом проекте, чтобы строить БД с нуля, проектировать миграции, делать SQL-запросы, работать с AI и не только! 😊
До встречи онлайн!
——-
Вопросы?
Пишите @getanalyst или info@getanalyst.ru.
Весна — время вдохновения, роста и энергии. А ещё — отличное время для новых проектов! 🌸
👉 У нас стартует новая серия продвинутых практикумов по БД и SQL на 8 занятий, с новым проектом.
Первое занятие пройдёт уже в следующий понедельник:
📚 Проектирование БД с нуля: создание ER-диаграммы
Для тех, кто подключается сейчас:
✅ доступна запись занятия по продвинутым запросам в SQL
✅ в чт откроем подготовительные материалы к занятию
🎁 Скидка -15% по промокоду ВЕСНА2026 в честь нового проекта 🙌
Можно подключаться как на одно занятие, так и на всю серию из 8 занятий.
Будем рады видеть вас на новом проекте, чтобы строить БД с нуля, проектировать миграции, делать SQL-запросы, работать с AI и не только! 😊
До встречи онлайн!
——-
Вопросы?
Пишите @getanalyst или info@getanalyst.ru.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤10
Архитектура_AdFlowGA_рекламная_платформа_GetAnalyst.png
849.8 KB
🔴 Архитектура на 17 микросервисов + 9 интеграций: схема для рекламной платформы #AdFlowGA 🔖
С чего начинается проектирование архитектуры?
▫️ Выделяем сервисы и их зону ответственности
▫️ Определяем, где будут интеграции
▫️ Уточняем их БД и ФХ
▫️ Фиксируем всё на схеме архитектуры.
А далее надо определяться с их внутренним взаимодействием: хореография, оркестрация, прямые вызовы по API...
Поэтому сделаем первые шаги в построении архитектуры платформы AdFlowGA, чтобы на её примере далее разбираться с хореографией и оркестрацией.
👉 Что важно на схеме архитектуры:
1) Выделенный сервис Авторизации.
За пределами API Gateway.
2) Для всех сервисов подобраны API
REST, HTTP, gRPC, GraphQL — выбор зависит от нагрузки, сценария и требований к задержкам.
3) У каждого МС (микросервиса) своя БД
В реальных системах часто одна физическая БД, но разные схемы и строгая изоляция на уровне доступа.
4) У каждого МС своё ФХ
В данном случае это уместно, но часто делают общие ФХ на несколько МС.
❗️ Пока не показаны внутренние взаимодействия между МС, но они есть.
👉 Описание микросервисов
1️⃣ МС Авторизации и Аутентификации
Обеспечивает вход пользователей в систему (логин/пароль, OAuth через Google и Яндекс), управление сессиями и токенами.
2️⃣ МС Аккаунты пользователей
Хранит профили пользователей, их роли, принадлежность к организациям и настройки доступа.
3️⃣ МС Креативы / Объявления
Управляет созданием, редактированием и хранением рекламных креативов и их версий.
4️⃣ МС Рекламные кампании
Отвечает за управление кампаниями (периоды, бюджеты, статусы, связи с объявлениями).
5️⃣ МС Валидатор рекламных креативов / объявлений
Проверяет креативы на соответствие форматам, правилам и ограничениям (в том числе через LLM — YandexGPT). Проверяет URL - ссылки на объявления.
6️⃣ МС Модерации
Организует процесс ручной проверки объявлений, управление статусами и историей решений.
7️⃣ МС Маркировки
Интегрируется с ОРД для регистрации рекламы и получения ERID.
8️⃣ МС Отчёты по маркировке
Формирует и отправляет обязательные отчёты по рекламе в ОРД/ЕРИР.
9️⃣ МС Реестр контрагентов (рекламодателей)
Хранит данные рекламодателей и договоров, необходимые для корректной передачи информации в ОРД.
🔟 МС Коннектор к рекламным площадкам
Обеспечивает интеграцию с внешними рекламными платформами (VK Ads, Telegram Ads, Yandex Direct).
1️⃣1️⃣ МС Биллинг
Отвечает за резервирование бюджета, списания и расчёт расходов рекламных кампаний. Пополнение баланса рекламного аккаунта через Т-Банк.
1️⃣2️⃣ МС Отчёты
Формирует пользовательские отчёты по кампаниям и размещениям.
1️⃣3️⃣ МС Статистика
Собирает и хранит статистику показов, кликов и других метрик с рекламных площадок.
1️⃣4️⃣ МС Уведомления
Отправляет системные уведомления пользователям (статусы, ошибки, события).
1️⃣5️⃣ МС Тех поддержки
Обрабатывает обращения пользователей и хранит историю тикетов.
1️⃣6️⃣ МС Аудита
Фиксирует действия пользователей и системные события для контроля и расследований.
1️⃣7️⃣ API Gateway
Маршрутизация запросов от клиентов Backend на микросервисы.
👉 Нотация моделирования: CR (упрощение от C4)
А теперь главный вопрос:
В следующих постах будем переводить схему в нотацию C4, добавлять брокеров и определяться с внутренними взаимодействиями 🙌
#АрхитектураGA
С чего начинается проектирование архитектуры?
▫️ Выделяем сервисы и их зону ответственности
▫️ Определяем, где будут интеграции
▫️ Уточняем их БД и ФХ
▫️ Фиксируем всё на схеме архитектуры.
А далее надо определяться с их внутренним взаимодействием: хореография, оркестрация, прямые вызовы по API...
Поэтому сделаем первые шаги в построении архитектуры платформы AdFlowGA, чтобы на её примере далее разбираться с хореографией и оркестрацией.
👉 Что важно на схеме архитектуры:
1) Выделенный сервис Авторизации.
За пределами API Gateway.
2) Для всех сервисов подобраны API
REST, HTTP, gRPC, GraphQL — выбор зависит от нагрузки, сценария и требований к задержкам.
3) У каждого МС (микросервиса) своя БД
В реальных системах часто одна физическая БД, но разные схемы и строгая изоляция на уровне доступа.
4) У каждого МС своё ФХ
В данном случае это уместно, но часто делают общие ФХ на несколько МС.
❗️ Пока не показаны внутренние взаимодействия между МС, но они есть.
👉 Описание микросервисов
1️⃣ МС Авторизации и Аутентификации
Обеспечивает вход пользователей в систему (логин/пароль, OAuth через Google и Яндекс), управление сессиями и токенами.
2️⃣ МС Аккаунты пользователей
Хранит профили пользователей, их роли, принадлежность к организациям и настройки доступа.
3️⃣ МС Креативы / Объявления
Управляет созданием, редактированием и хранением рекламных креативов и их версий.
4️⃣ МС Рекламные кампании
Отвечает за управление кампаниями (периоды, бюджеты, статусы, связи с объявлениями).
5️⃣ МС Валидатор рекламных креативов / объявлений
Проверяет креативы на соответствие форматам, правилам и ограничениям (в том числе через LLM — YandexGPT). Проверяет URL - ссылки на объявления.
6️⃣ МС Модерации
Организует процесс ручной проверки объявлений, управление статусами и историей решений.
7️⃣ МС Маркировки
Интегрируется с ОРД для регистрации рекламы и получения ERID.
8️⃣ МС Отчёты по маркировке
Формирует и отправляет обязательные отчёты по рекламе в ОРД/ЕРИР.
9️⃣ МС Реестр контрагентов (рекламодателей)
Хранит данные рекламодателей и договоров, необходимые для корректной передачи информации в ОРД.
🔟 МС Коннектор к рекламным площадкам
Обеспечивает интеграцию с внешними рекламными платформами (VK Ads, Telegram Ads, Yandex Direct).
1️⃣1️⃣ МС Биллинг
Отвечает за резервирование бюджета, списания и расчёт расходов рекламных кампаний. Пополнение баланса рекламного аккаунта через Т-Банк.
1️⃣2️⃣ МС Отчёты
Формирует пользовательские отчёты по кампаниям и размещениям.
1️⃣3️⃣ МС Статистика
Собирает и хранит статистику показов, кликов и других метрик с рекламных площадок.
1️⃣4️⃣ МС Уведомления
Отправляет системные уведомления пользователям (статусы, ошибки, события).
1️⃣5️⃣ МС Тех поддержки
Обрабатывает обращения пользователей и хранит историю тикетов.
1️⃣6️⃣ МС Аудита
Фиксирует действия пользователей и системные события для контроля и расследований.
1️⃣7️⃣ API Gateway
Маршрутизация запросов от клиентов Backend на микросервисы.
👉 Нотация моделирования: CR (упрощение от C4)
А теперь главный вопрос:
где здесь будет уместна хореография, а где без оркестрации не обойтись?
В следующих постах будем переводить схему в нотацию C4, добавлять брокеров и определяться с внутренними взаимодействиями 🙌
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥21❤5👍4
💥 Виды API: когда и какой выбрать 💥
API (Application Programming Interface) — это набор правил и методов, позволяющих разным программам взаимодействовать друг с другом.
Он позволяет одной программе общаться с другой, отправляя запросы и получая ответы, даже если они написаны на разных языках программирования или работают на разных устройствах / серверах.
Основные виды API:
⚡ HTTP
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket
⚡ SSE
В деталях 👇
⚡ HTTP API
Использует HTTP-протокол.
Часто это более “простые” API без строгого следования REST-подходу.
Во многих таких API чаще встречаются только методы GET / POST, но могут использоваться и другие.
Пример: Unisender
⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепции ресурсов и стандартных HTTP-методов (GET, POST, PUT, PATCH, DELETE и др.).
Это архитектурный стиль проектирования API поверх HTTP.
Широко используется для веб- и мобильных приложений, а также в микросервисной архитектуре.
Пример: Wildberries
⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает стандартизированные подходы к безопасности и описанию операций.
Часто применяется в корпоративных системах (enterprise), где важны строгие контракты, формализация и совместимость, а также повышенная безопасность.
Сегодня для новых проектов SOAP выбирают реже, так как REST/gRPC часто проще и легче в реализации и сопровождении.
Пример: PayPal
⚡ GraphQL
Позволяет клиенту запрашивать только те данные, которые ему необходимы, с помощью декларативного языка запросов.
Удобен для сложных приложений с изменяемыми потребностями в данных, для мобильных приложений и микросервисов с целью оптимизации трафика между клиентом и сервером, который реализует API.
Пример документации:
Яндекс.Погода
⚡ gRPC
Использует Protocol Buffers (protobuf) для сериализации данных и обычно работает поверх HTTP/2.
Поддерживает разные типы взаимодействия, включая стриминг (в т.ч. двусторонний).
Эффективен для микросервисной архитектуры с высокими требованиями к производительности и нагрузкам.
Пример: Dropbox от Google
⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.
Используется там, где нужен быстрый обмен событиями: чаты, уведомления, биржевые данные, игровые сценарии и т.д.
Пример: Binance Биржа
⚡ SSE (Server-Sent Events)
Механизм, при котором сервер может в реальном времени отправлять обновления клиенту по одному HTTP-соединению.
В отличие от WebSocket, SSE обычно используется для односторонней передачи данных (от сервера к клиенту).
Подходит для сценариев, где нужно показывать обновления без постоянного опроса сервера:
+ уведомления
+ статусы задач
+ обновление ленты событий
+ прогресс обработки
+ live-обновления на дашбордах
Обычно проще в реализации, чем WebSocket, если не нужна двусторонняя связь.
Для системного аналитика важно понимать, в каких сценариях используют тот или иной подход, чтобы:
✅ корректно описывать требования к интеграциям,
✅ учитывать ограничения по производительности, безопасности и формату данных,
✅ и выбирать реалистичный вариант взаимодействия между системами, сервисами и микросервисами.
#АрхитектураGA
API (Application Programming Interface) — это набор правил и методов, позволяющих разным программам взаимодействовать друг с другом.
Он позволяет одной программе общаться с другой, отправляя запросы и получая ответы, даже если они написаны на разных языках программирования или работают на разных устройствах / серверах.
Основные виды API:
⚡ HTTP
⚡ REST
⚡ SOAP
⚡ GraphQL
⚡ gRPC
⚡ WebSocket
⚡ SSE
В деталях 👇
⚡ HTTP API
Использует HTTP-протокол.
Часто это более “простые” API без строгого следования REST-подходу.
Во многих таких API чаще встречаются только методы GET / POST, но могут использоваться и другие.
Пример: Unisender
⚡ REST API (Representational State Transfer)
Использует HTTP-протокол и основывается на концепции ресурсов и стандартных HTTP-методов (GET, POST, PUT, PATCH, DELETE и др.).
Это архитектурный стиль проектирования API поверх HTTP.
Широко используется для веб- и мобильных приложений, а также в микросервисной архитектуре.
Пример: Wildberries
⚡ SOAP API (Simple Object Access Protocol)
Использует XML для обмена сообщениями и поддерживает стандартизированные подходы к безопасности и описанию операций.
Часто применяется в корпоративных системах (enterprise), где важны строгие контракты, формализация и совместимость, а также повышенная безопасность.
Сегодня для новых проектов SOAP выбирают реже, так как REST/gRPC часто проще и легче в реализации и сопровождении.
Пример: PayPal
⚡ GraphQL
Позволяет клиенту запрашивать только те данные, которые ему необходимы, с помощью декларативного языка запросов.
Удобен для сложных приложений с изменяемыми потребностями в данных, для мобильных приложений и микросервисов с целью оптимизации трафика между клиентом и сервером, который реализует API.
Пример документации:
Яндекс.Погода
⚡ gRPC
Использует Protocol Buffers (protobuf) для сериализации данных и обычно работает поверх HTTP/2.
Поддерживает разные типы взаимодействия, включая стриминг (в т.ч. двусторонний).
Эффективен для микросервисной архитектуры с высокими требованиями к производительности и нагрузкам.
Пример: Dropbox от Google
⚡ WebSocket
Обеспечивает двухстороннюю связь между клиентом и сервером в режиме реального времени.
Используется там, где нужен быстрый обмен событиями: чаты, уведомления, биржевые данные, игровые сценарии и т.д.
Пример: Binance Биржа
⚡ SSE (Server-Sent Events)
Механизм, при котором сервер может в реальном времени отправлять обновления клиенту по одному HTTP-соединению.
В отличие от WebSocket, SSE обычно используется для односторонней передачи данных (от сервера к клиенту).
Подходит для сценариев, где нужно показывать обновления без постоянного опроса сервера:
+ уведомления
+ статусы задач
+ обновление ленты событий
+ прогресс обработки
+ live-обновления на дашбордах
Обычно проще в реализации, чем WebSocket, если не нужна двусторонняя связь.
Для системного аналитика важно понимать, в каких сценариях используют тот или иной подход, чтобы:
✅ корректно описывать требования к интеграциям,
✅ учитывать ограничения по производительности, безопасности и формату данных,
✅ и выбирать реалистичный вариант взаимодействия между системами, сервисами и микросервисами.
#АрхитектураGA
🔥27❤14
🌐 Load Balancer | Reverse Proxy | Forward Proxy | Service Mesh | Gateway 🌐
Когда системы обрабатывают миллиарды запросов в день, они не "падают" благодаря правильным сетевым компонентам.
Давайте разберёмся в 5 ключевых компонентах высоконагруженных систем:
🔹 Load Balancer (балансировщик нагрузки)
Равномерно распределяет нагрузку между серверами, чтобы не было перегрузки и падений.
+ Принимает все входящие запросы.
+ Равномерно распределяет их по нескольким серверам.
+ Автоматически исключает из работы «упавшие» узлы.
👉 Благодаря этому система выдерживает пиковые нагрузки и остаётся доступной.
🔹 Reverse Proxy
Работает от имени сервера.
+ Принимает запросы от клиента и передаёт их в backend.
+ Скрывает внутреннюю инфраструктуру (клиент не знает адресов сервисов).
+ Может кэшировать ответы, чтобы уменьшить нагрузку.
👉 Часто используется вместе с балансировкой и как дополнительный уровень защиты.
🔹 Forward Proxy
Работает от имени клиента.
+ Прячет реальный адрес пользователя.
+ Может фильтровать запросы и блокировать нежелательные сайты.
+ Используется в компаниях для контроля доступа сотрудников в интернет.
👉 Ближе к «интернет-фильтру» или «корпоративному шлюзу». Защищает и контролирует клиента.
🔹 Service Mesh
Внутренняя «сеть» для общения микросервисов между собой.
+ Настраивает коммуникацию сервис-сервис без изменения кода.
+ Делает автоматическую балансировку и маршрутизацию внутри кластера.
+ Добавляет шифрование трафика, retries, circuit breaker, метрики.
👉 Полезен в Kubernetes, где много сервисов и вручную управлять связями уже невозможно.
🔹 API Gateway
Единая точка входа для всех клиентских запросов.
+ Проверяет авторизацию и токены.
+ Маршрутизирует запросы к нужным сервисам.
+ Ограничивает частоту запросов.
+ Может объединять ответы от разных микросервисов в один.
👉 Используется для централизованного приема API-запросов.
📌 Запоминайте эти сетевые+архитектурные термины и применяйте правильно в общении с разработчиками и архитекторами.
#АрхитектураGA
Когда системы обрабатывают миллиарды запросов в день, они не "падают" благодаря правильным сетевым компонентам.
Давайте разберёмся в 5 ключевых компонентах высоконагруженных систем:
🔹 Load Balancer (балансировщик нагрузки)
Равномерно распределяет нагрузку между серверами, чтобы не было перегрузки и падений.
+ Принимает все входящие запросы.
+ Равномерно распределяет их по нескольким серверам.
+ Автоматически исключает из работы «упавшие» узлы.
👉 Благодаря этому система выдерживает пиковые нагрузки и остаётся доступной.
🔹 Reverse Proxy
Работает от имени сервера.
+ Принимает запросы от клиента и передаёт их в backend.
+ Скрывает внутреннюю инфраструктуру (клиент не знает адресов сервисов).
+ Может кэшировать ответы, чтобы уменьшить нагрузку.
👉 Часто используется вместе с балансировкой и как дополнительный уровень защиты.
🔹 Forward Proxy
Работает от имени клиента.
+ Прячет реальный адрес пользователя.
+ Может фильтровать запросы и блокировать нежелательные сайты.
+ Используется в компаниях для контроля доступа сотрудников в интернет.
👉 Ближе к «интернет-фильтру» или «корпоративному шлюзу». Защищает и контролирует клиента.
🔹 Service Mesh
Внутренняя «сеть» для общения микросервисов между собой.
+ Настраивает коммуникацию сервис-сервис без изменения кода.
+ Делает автоматическую балансировку и маршрутизацию внутри кластера.
+ Добавляет шифрование трафика, retries, circuit breaker, метрики.
👉 Полезен в Kubernetes, где много сервисов и вручную управлять связями уже невозможно.
🔹 API Gateway
Единая точка входа для всех клиентских запросов.
+ Проверяет авторизацию и токены.
+ Маршрутизирует запросы к нужным сервисам.
+ Ограничивает частоту запросов.
+ Может объединять ответы от разных микросервисов в один.
👉 Используется для централизованного приема API-запросов.
📌 Запоминайте эти сетевые+архитектурные термины и применяйте правильно в общении с разработчиками и архитекторами.
#АрхитектураGA
🔥18❤5👍4💯2
Раньше аналитикам достаточно было “хорошо собирать требования и писать понятные спецификации”.
А теперь всё чаще спрашивают понимание архитектуры.
Не “что такое Kafka”, а:
• где нужен брокер, а где синхронный API;
• что будет при таймауте и дублях сообщений;
• как обеспечиваем целостность и согласованность данных между сервисами;
• в каком случае выбрать gRPC, а где лучше подойдёт REST API.
На программе «Проектирование архитектуры» в GetAnalyst мы уже помогли 250+ аналитикам получить практический опыт работы со сложными сервисными и микросервисными системами.
Благодаря этому они выросли внутри своих компаний, сменили работу и даже перешли в карьерный трек Solutions Architect 😍
Приглашаем и вас получить самые актуальные навыки по архитектуре для СА в новом потоке:
📌 Проектирование архитектуры
📅 Старт 17 марта 2026
🎁 По заявкам до 10 марта
лучшие цены и доступ к пакету практикумов по REST API в подарок.
👉 Кому актуально
Опытным системным аналитикам (Middle и выше), кто уже работал с интеграциями и хочет:
+ вырасти в Senior внутри компании,
+ перейти в более сложные продуктовые/платформенные проекты.
👉 По итогам
✅ Освоите монолит, SOA, микросервисы - MSA, EDA
✅ Получите опыт в проектировании архитектуры с нуля
✅ Познакомитесь с GraphQL, gRPC, WebSocket, SSE
✅ Научитесь работать с брокерами RabbitMQ / Kafka
✅ Получите опыт в нотации C4 для архитектуры
✅ Сможете уверенно обсуждать архитектурные решения на интервью и в проектах
Вопросы? Пишите @getanalyst или info@getanalyst.ru. Поможем оценить текущий уровень и дадим рекомендации по дальнейшим шагам в карьерном развитии 🙌
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
📌 8 Шаблонов Микросервисной архитектуры, о которых спрашивают 📌
1️⃣ API Gateway
Единая точка входа для всех внешних запросов.
Отвечает за маршрутизацию, кэширование, аутентификацию.
2️⃣ Service Registry and Discovery
Динамическое обнаружение и регистрация сервисов.
Это механизм? по которому сервисы сами находят адреса друг друга. Он помогает им корректно взаимодействовать без жёстко прописанных адресов.
3️⃣ Backends for Frontends (BFF)
Отдельные адаптивные бэкенды под каждый вид клиентов. Например: Web и Mobile.
Каждый клиент получает ровно те данные и в том виде, который ему нужен.
4️⃣ Event Driven
Микросервисы обмениваются информацией не напрямую, а через публикацию и подписку на «события» в общем брокере: один сервис публикует сообщение о случившемся изменении, а все заинтересованные сервисы, подписанные на эти события, асинхронно получают и обрабатывают их.
5️⃣ CQRS (Command Query Responsibility Segregation)
Шаблон, в котором операции изменения состояния системы (Commands) отделяются от операций чтения данных (Queries).
• Commands реализуют запись данных, с их валидацией.
• Queries оптимизированы под быстрое получение и агрегации, отчёты.
6️⃣ Database-per-Service
Изоляция данных каждого сервиса в своей БД.
Минимизирует зависимость между микросервисами.
Главная проблема - сложность синхронизации данных.
7️⃣ Оркестрация
Центральный сервис управляет порядком вызовов.
Обеспечивает:
• последовательность выполнения алгоритмов, которые используют разные микросервисы,
• целостность и контроль транзакций.
Пример сервиса-оркерстратора: Camunda.
8️⃣ Хореография
Сервисы обмениваются событиями напрямую через брокер, которые управляет порядком выполнения алгоримов, в которых задействованы разные микросервисы.
⚙️ Как применяют?
• В зависимости НФТ (нефункциональных требований).
• Часто комбинируют несколько подходов.
Сохраните себе шпаргалку и используйте при проектировании архитектуры микросервисов, анализе своих проектов и подготовке к собеседованиям 🙌
Исходник: png | noscript (анимация)
#АрхитектураGA
1️⃣ API Gateway
Единая точка входа для всех внешних запросов.
Отвечает за маршрутизацию, кэширование, аутентификацию.
2️⃣ Service Registry and Discovery
Динамическое обнаружение и регистрация сервисов.
Это механизм? по которому сервисы сами находят адреса друг друга. Он помогает им корректно взаимодействовать без жёстко прописанных адресов.
3️⃣ Backends for Frontends (BFF)
Отдельные адаптивные бэкенды под каждый вид клиентов. Например: Web и Mobile.
Каждый клиент получает ровно те данные и в том виде, который ему нужен.
4️⃣ Event Driven
Микросервисы обмениваются информацией не напрямую, а через публикацию и подписку на «события» в общем брокере: один сервис публикует сообщение о случившемся изменении, а все заинтересованные сервисы, подписанные на эти события, асинхронно получают и обрабатывают их.
5️⃣ CQRS (Command Query Responsibility Segregation)
Шаблон, в котором операции изменения состояния системы (Commands) отделяются от операций чтения данных (Queries).
• Commands реализуют запись данных, с их валидацией.
• Queries оптимизированы под быстрое получение и агрегации, отчёты.
6️⃣ Database-per-Service
Изоляция данных каждого сервиса в своей БД.
Минимизирует зависимость между микросервисами.
Главная проблема - сложность синхронизации данных.
7️⃣ Оркестрация
Центральный сервис управляет порядком вызовов.
Обеспечивает:
• последовательность выполнения алгоритмов, которые используют разные микросервисы,
• целостность и контроль транзакций.
Пример сервиса-оркерстратора: Camunda.
8️⃣ Хореография
Сервисы обмениваются событиями напрямую через брокер, которые управляет порядком выполнения алгоримов, в которых задействованы разные микросервисы.
⚙️ Как применяют?
• В зависимости НФТ (нефункциональных требований).
• Часто комбинируют несколько подходов.
Сохраните себе шпаргалку и используйте при проектировании архитектуры микросервисов, анализе своих проектов и подготовке к собеседованиям 🙌
Исходник: png | noscript (анимация)
#АрхитектураGA
🔥27❤7
🚀 Планирую открытый онлайн-практикум по Архитектуре. Какая тема больше всего актуальна?
Anonymous Poll
36%
API Gateway - всё в деталях
33%
C4 - разработка с нуля
37%
Хореогрфия микросервисов + Брокеры
27%
Оркестрация микросервисов
17%
Монолит vs Микросервисы
39%
Архитектура приложений с AI - построение с нуля
❤19
Тем временем у меня пошёл 6-й месяц учёбы в Университете Джонса Хопкинса по AI 🤩
И это вообще не история “вот ChatGPT, сюда вставь готовый промпт”.
Нам показывают искусственный интеллект (AI) "под капотом", чтобы мы понимали, что именно происходит, когда модель “умно отвечает”.
За последние полгода я, кажется, написала больше кода, чем за 6 лет обучения в МИФИ 😅
Потому что работа с AI в роли разработчика реально “сдвигает” сознание: ты начинаешь видеть не только результат, но и механику.
И это не про “вайб-кодинг”.
Это формат:
+ делаем блок кода на Python под конкретную задачу - c AI или без,
+ разбираемся что сделали построчно,
+ делаем следующую задачу.
Делаем мини-проекты под разные домены: медицина, IT-компании, онлайн-торговля, финтех и другие.
Что было последние пару месяцев:
👉 Безопасная разработка приложений с AI
От защиты промптов и архитектуры до соблюдения законодательства.
👉 AI-агенты
Их можно делать без программирования. Но нам "магию" использовать не разрешили.
Всё запрограммировала, побесилась, но это было полезно для понимания как работает "магия", и как улучшить мою работу.
👉 MCP (Model Context Protocol)
Стандарт для интеграций LLM с системами и данными: как подключать инструменты и источники системно, и в каких случаях MCP уместен, а где проще и надёжнее традиционная интеграция.
👉 Fine-Tuning и RAG
Адаптируем нейросети под задачи бизнеса. Мне безумно понравились несколько практических задач, которые мы делали на Python!
В итоге одну из них решила добавить в финальный модуль по программированию для наших студентов на ИИ-Акселераторе 😍
В общем, учёба в Хопкинсе открыла для меня AI с той глубокой технической стороны, которая раньше вызывала вопросы.
До сих пор не знаю как я успеваю учиться.
Полноценных выходных не было давно 🙈
Но я точно знаю, что этот огромный вклад времени в обучение уже повлиял на мою работу и развитие 🙌
И это вообще не история “вот ChatGPT, сюда вставь готовый промпт”.
Нам показывают искусственный интеллект (AI) "под капотом", чтобы мы понимали, что именно происходит, когда модель “умно отвечает”.
За последние полгода я, кажется, написала больше кода, чем за 6 лет обучения в МИФИ 😅
Потому что работа с AI в роли разработчика реально “сдвигает” сознание: ты начинаешь видеть не только результат, но и механику.
И это не про “вайб-кодинг”.
Это формат:
+ делаем блок кода на Python под конкретную задачу - c AI или без,
+ разбираемся что сделали построчно,
+ делаем следующую задачу.
Делаем мини-проекты под разные домены: медицина, IT-компании, онлайн-торговля, финтех и другие.
Что было последние пару месяцев:
👉 Безопасная разработка приложений с AI
От защиты промптов и архитектуры до соблюдения законодательства.
👉 AI-агенты
Их можно делать без программирования. Но нам "магию" использовать не разрешили.
Всё запрограммировала, побесилась, но это было полезно для понимания как работает "магия", и как улучшить мою работу.
👉 MCP (Model Context Protocol)
Стандарт для интеграций LLM с системами и данными: как подключать инструменты и источники системно, и в каких случаях MCP уместен, а где проще и надёжнее традиционная интеграция.
👉 Fine-Tuning и RAG
Адаптируем нейросети под задачи бизнеса. Мне безумно понравились несколько практических задач, которые мы делали на Python!
В итоге одну из них решила добавить в финальный модуль по программированию для наших студентов на ИИ-Акселераторе 😍
В общем, учёба в Хопкинсе открыла для меня AI с той глубокой технической стороны, которая раньше вызывала вопросы.
До сих пор не знаю как я успеваю учиться.
Полноценных выходных не было давно 🙈
Но я точно знаю, что этот огромный вклад времени в обучение уже повлиял на мою работу и развитие 🙌
🔥89❤32👍8🦄3❤🔥1😁1💯1
🟢 БД и SQL - новый проект по ИИ-платформе | сегодня, в 19:00 Мск 🤖🎁
Если вам хочется иметь ясность и уверенность в проектировании БД, то как раз сегодня стартует серия практикумов по БД и SQL с новым проектом!
Будем строить БД с нуля, проектировать миграции, делать SQL-запросы, работать с ИИ и не только! 😊
Сегодня собираем ER-диаграмму физ. модели для ИИ-платформы и раскладываем по полочкам, как хранить в БД чаты и сообщения.
Подключайтесь на первое занятие:
🟢 Проектирование БД с нуля: создание ER-диаграммы
🤖 Проект: ИИ-платформа
🗓 2 марта (пн), 19:00 Мск
🔗 Подробности и запись
🎁 Скидка -15% по промокоду «ВЕСНА2026»
только до конца дня, в честь старта проекта.
✔️ Сразу после подключения вам доступна запись занятия по продвинутым SQL-запросам.
✔️ Запись сегодняшнего практикума появится на следующий день после занятия.
Вопросы? Пишите @getanalyst или info@getanalyst.ru.
До встречи онлайн! 😊
И с весной вас! Скорейшего перехода в 🌸🌿🌱
Если вам хочется иметь ясность и уверенность в проектировании БД, то как раз сегодня стартует серия практикумов по БД и SQL с новым проектом!
Будем строить БД с нуля, проектировать миграции, делать SQL-запросы, работать с ИИ и не только! 😊
Сегодня собираем ER-диаграмму физ. модели для ИИ-платформы и раскладываем по полочкам, как хранить в БД чаты и сообщения.
Подключайтесь на первое занятие:
🟢 Проектирование БД с нуля: создание ER-диаграммы
🤖 Проект: ИИ-платформа
🎁 Скидка -15% по промокоду «ВЕСНА2026»
только до конца дня, в честь старта проекта.
✔️ Сразу после подключения вам доступна запись занятия по продвинутым SQL-запросам.
✔️ Запись сегодняшнего практикума появится на следующий день после занятия.
Вопросы? Пишите @getanalyst или info@getanalyst.ru.
До встречи онлайн! 😊
И с весной вас! Скорейшего перехода в 🌸🌿🌱
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8
🚦 Всё про брокеры: как работают и зачем нужны 🚥
Брокеры — это посредники в передаче сообщений между системами или сервисами.
Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений.
👉 Принцип работы:
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
Брокеры — это посредники в передаче сообщений между системами или сервисами.
Они позволяют асинхронно обмениваться данными и обеспечивают гарантию доставки сообщений.
👉 Принцип работы:
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
3🔥22❤8👎1👌1
💃 Хореография vs Оркестрация в микросервисной архитектуре 🎻
В микросервисной архитектуре (МСА) есть два основных подхода к управлению процессами между сервисами:
💃 хореография,
🎻 оркестрация.
Суть — несколько микросервисов должны отработать один сквозной сценарий, в правильном порядке и без “потерянных” шагов.
Пример из #AdFlowGA
Разрешение на публикацию объявления — это не просто “всё, публикуемся”.
Это триггер для цепочки действий:
1️⃣ запросить токен ERID для маркировки рекламы,
2️⃣ после этого отправить объявление на публикацию (ВК Реклама / Яндекс.Директ и др.)
3️⃣ запустить учёт бюджета рекламной кампании
С точки зрения архитектуры, этот процесс может быть реализован по-разному:
📌 Хореография
Каждый сервис сам реагирует на события и выполняет свою часть процесса.
Взаимодействие между сервисами происходит через брокер сообщений (обычно Kafka), без централизованного управляющего компонента.
Как это выглядит в AdFlowGA (примеры событий):
+ Срабатывает событие → publication.allowed
+ publication.allowed → МС Маркировки запрашивает ERID и публикует событие → erid.received
+ erid.received → МС Коннектор публикует объявление на площадке → ad.published
+ ad.published → МС Рекламные кампании запускает учёт бюджета
👉 Главное здесь — думать не “кто кого вызывает”, а какие события должны появляться в системе и что должен сделать каждый сервис, когда событие произошло.
📌 Оркестрация
Здесь управление процессом сосредоточено в отдельном компоненте — оркестраторе.
Пример оркестратора “из коробки”: Camunda.
Оркестратор вызывает нужные микросервисы по порядку:
▫️ получить ERID →
▫️ опубликовать на площадку →
▫️ начать отсчет бюджета кампании
и отслеживает их выполнение.
Вся логика сценария сосредоточена в одном месте, что упрощает контроль и трассировку бизнес-процесса.
👉 Что выбрать?
Оба подхода имеют свои преимущества и применяются в зависимости от целей:
💃 Хореография подходит для гибких, масштабируемых систем с высокой степенью независимости компонентов;
🎻 Оркестрация — для сценариев, требующих строгой последовательности, централизованного контроля и отслеживания хода выполнения.
Сводится к простому: где важна строгая последовательность, а где процесс можно построить как связку независимых шагов, выполняемых асинхронно.
#АрхитектураGA #AdFlowGA
В микросервисной архитектуре (МСА) есть два основных подхода к управлению процессами между сервисами:
💃 хореография,
🎻 оркестрация.
Суть — несколько микросервисов должны отработать один сквозной сценарий, в правильном порядке и без “потерянных” шагов.
Пример из #AdFlowGA
Разрешение на публикацию объявления — это не просто “всё, публикуемся”.
Это триггер для цепочки действий:
1️⃣ запросить токен ERID для маркировки рекламы,
2️⃣ после этого отправить объявление на публикацию (ВК Реклама / Яндекс.Директ и др.)
3️⃣ запустить учёт бюджета рекламной кампании
С точки зрения архитектуры, этот процесс может быть реализован по-разному:
📌 Хореография
Каждый сервис сам реагирует на события и выполняет свою часть процесса.
Взаимодействие между сервисами происходит через брокер сообщений (обычно Kafka), без централизованного управляющего компонента.
Как это выглядит в AdFlowGA (примеры событий):
+ Срабатывает событие → publication.allowed
+ publication.allowed → МС Маркировки запрашивает ERID и публикует событие → erid.received
+ erid.received → МС Коннектор публикует объявление на площадке → ad.published
+ ad.published → МС Рекламные кампании запускает учёт бюджета
👉 Главное здесь — думать не “кто кого вызывает”, а какие события должны появляться в системе и что должен сделать каждый сервис, когда событие произошло.
📌 Оркестрация
Здесь управление процессом сосредоточено в отдельном компоненте — оркестраторе.
Пример оркестратора “из коробки”: Camunda.
Оркестратор вызывает нужные микросервисы по порядку:
▫️ получить ERID →
▫️ опубликовать на площадку →
▫️ начать отсчет бюджета кампании
и отслеживает их выполнение.
Вся логика сценария сосредоточена в одном месте, что упрощает контроль и трассировку бизнес-процесса.
👉 Что выбрать?
Оба подхода имеют свои преимущества и применяются в зависимости от целей:
💃 Хореография подходит для гибких, масштабируемых систем с высокой степенью независимости компонентов;
🎻 Оркестрация — для сценариев, требующих строгой последовательности, централизованного контроля и отслеживания хода выполнения.
Сводится к простому: где важна строгая последовательность, а где процесс можно построить как связку независимых шагов, выполняемых асинхронно.
#АрхитектураGA #AdFlowGA
❤24🔥4👍1🤔1
🔴 Задача по архитектуре, которой проверяют опыт Senior СА 🔴
Перед вами описание бизнес-процесса в рекламной платформе #AdFlowGA.
Есть схема со всеми компонентами архитектуры, которые нужны для реализации процесса — но на ней нет стрелок.
👉 Бизнес-процесс:
➡️ Старт:
В админке модератор нажимает одну кнопку: «Опубликовать креатив (объявление)».
➡️ Система должна:
1) Зафиксировать прохождение модерации в истории
2) Получить токен маркировки (ERID)
3) Опубликовать объявление на площадке VK / Telegram / Yandex
4) Зафиксировать старт рекламной кампании
5) Зафиксировать успешную публикацию в истории объявления
6) Отправить уведомления рекламодателю
7) Записать событие о завершении модерации в аудит
👉 Схема:
прикреплена к посту.
+ описание архитектуры и первичное решение есть тут.
👉 Задание:
Показать на схеме архитектуры, как будет выполняться процесс от начала до конца.
Добавить стрелки и подписать номера шагов.
Условия:
+ Всё запускается одной кнопкой.
+ В системе много микросервисов и внешних интеграций.
+ Нужно, чтобы процесс был надёжным.
❌ На чём ошибаются системные аналитики, решая эту задачу в реальном времени:
1. Делают всё синхронно
2. Не видят точек оптимизации
3. Не могут правильно принять решение между хореографией и оркестрацией
4. Не думают про повторы и дубли (идемпотентность)
5. Не поднимают вопрос “что, если процесс упал на середине”
6. Полагаются на то, что внешние системы всегда доступны
7. Путают ответственность сервисов
8. Не задумываются о результатах для модератора
Я обязательно опубликую несколько вариантов решения задачи в рамках нашего проекта.
А пока — забирайте исходник, решайте сами и можете поделитесь схемами в комментариях:
🔗 [ссылка на исходник draw io / png]
Это ваша возможность попрактиковаться в решении сложных задач с собеседований на Senior! 💪
#АрхитектураGA
Перед вами описание бизнес-процесса в рекламной платформе #AdFlowGA.
Есть схема со всеми компонентами архитектуры, которые нужны для реализации процесса — но на ней нет стрелок.
👉 Бизнес-процесс:
➡️ Старт:
В админке модератор нажимает одну кнопку: «Опубликовать креатив (объявление)».
➡️ Система должна:
1) Зафиксировать прохождение модерации в истории
2) Получить токен маркировки (ERID)
3) Опубликовать объявление на площадке VK / Telegram / Yandex
4) Зафиксировать старт рекламной кампании
5) Зафиксировать успешную публикацию в истории объявления
6) Отправить уведомления рекламодателю
7) Записать событие о завершении модерации в аудит
👉 Схема:
прикреплена к посту.
+ описание архитектуры и первичное решение есть тут.
👉 Задание:
Показать на схеме архитектуры, как будет выполняться процесс от начала до конца.
Добавить стрелки и подписать номера шагов.
Условия:
+ Всё запускается одной кнопкой.
+ В системе много микросервисов и внешних интеграций.
+ Нужно, чтобы процесс был надёжным.
❌ На чём ошибаются системные аналитики, решая эту задачу в реальном времени:
1. Делают всё синхронно
2. Не видят точек оптимизации
3. Не могут правильно принять решение между хореографией и оркестрацией
4. Не думают про повторы и дубли (идемпотентность)
5. Не поднимают вопрос “что, если процесс упал на середине”
6. Полагаются на то, что внешние системы всегда доступны
7. Путают ответственность сервисов
8. Не задумываются о результатах для модератора
Я обязательно опубликую несколько вариантов решения задачи в рамках нашего проекта.
А пока — забирайте исходник, решайте сами и можете поделитесь схемами в комментариях:
Это ваша возможность попрактиковаться в решении сложных задач с собеседований на Senior! 💪
#АрхитектураGA
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥32❤13👎1🤩1💯1
🎻 Оркестрация микросервисов: полный практический гайд + материалы 📚
Оркестрация – это подход, при котором специальный сервис-оркестратор управляет группой микросервисов (МС).
👉 Оркестратор:
1. знает какие сервисы вызвать по API (обычно REST / gRPC)
2. в каком порядке
3. работает с условиями, сложными алгоритмами
4. если что-то пойдёт не так, то он "откатит" операцию на всех МС, которые уже были вызваны
Так сложный процесс превращается в цепочку задач. А Оркестратор следит за их выполнением.
👉 Как работает оркестратор
на примере Интернет-магазина:
1. Покупатель оформляет заказ через Web-приложение
2. Web-приложение отправляет запрос в API Gateway
POST .../orders
3. API Gateway маршрутизирует запрос на Оркестратор
4. Оркестратор присваивает id новой операции и вызывает API сервиса заказов
5. Сервис Заказов создает новый заказ в БД.
Результат - в Оркестратор
6. Оркестратор вызывает сервис Склада, чтобы зарезервировать товар
7. Склад подтверждает резерв или сообщает об отсутствии товара.
Результат - в Оркестратор
8. Оркестратор вызывает сервис Доставка для оформления отправления
9. Сервис доставки рассчитывает маршрут и время доставки, оформляет доставку.
Результат - в Оркестратор
10. Оркестратор вызывает сервис Уведомлений для отправки email/SMS о подтверждении заказа и доставке
11. Сервис Уведомлений выполняет отправку.
Результат - в Оркестратор
12. Оркестратор отправляет итоговый ответ в API Gateway, откуда он возвращается в Web-приложение
🔹Оркестратор вызывает API сервисов и ждёт ответ.
🔹Он может сохранять состояние процесса, чтобы возобновить его при сбое.
🔹 Если что-то идёт не так, оркестратор выполнит компенсации - откатит выполненные шаги.
📦 Готовые решения для оркестрации:
▫️ Camunda – BPM-движок с поддержкой диаграмм процессов (BPMN)
▫️ OpenBPM - аналог Camunda в России
📚 Подборка материалов:
🎧 Camunda и BPMN в микросервисах для процессов техподдержки
📝 Оркестрация и API Gateway – разбор реального примера
🎧 Внедряем Camunda: обзор и моделирование BPMN
#АрхитектураGA
Оркестрация – это подход, при котором специальный сервис-оркестратор управляет группой микросервисов (МС).
👉 Оркестратор:
1. знает какие сервисы вызвать по API (обычно REST / gRPC)
2. в каком порядке
3. работает с условиями, сложными алгоритмами
4. если что-то пойдёт не так, то он "откатит" операцию на всех МС, которые уже были вызваны
Так сложный процесс превращается в цепочку задач. А Оркестратор следит за их выполнением.
👉 Как работает оркестратор
на примере Интернет-магазина:
1. Покупатель оформляет заказ через Web-приложение
2. Web-приложение отправляет запрос в API Gateway
POST .../orders
3. API Gateway маршрутизирует запрос на Оркестратор
4. Оркестратор присваивает id новой операции и вызывает API сервиса заказов
5. Сервис Заказов создает новый заказ в БД.
Результат - в Оркестратор
6. Оркестратор вызывает сервис Склада, чтобы зарезервировать товар
7. Склад подтверждает резерв или сообщает об отсутствии товара.
Результат - в Оркестратор
8. Оркестратор вызывает сервис Доставка для оформления отправления
9. Сервис доставки рассчитывает маршрут и время доставки, оформляет доставку.
Результат - в Оркестратор
10. Оркестратор вызывает сервис Уведомлений для отправки email/SMS о подтверждении заказа и доставке
11. Сервис Уведомлений выполняет отправку.
Результат - в Оркестратор
12. Оркестратор отправляет итоговый ответ в API Gateway, откуда он возвращается в Web-приложение
🔹Оркестратор вызывает API сервисов и ждёт ответ.
🔹Он может сохранять состояние процесса, чтобы возобновить его при сбое.
🔹 Если что-то идёт не так, оркестратор выполнит компенсации - откатит выполненные шаги.
📦 Готовые решения для оркестрации:
▫️ Camunda – BPM-движок с поддержкой диаграмм процессов (BPMN)
▫️ OpenBPM - аналог Camunda в России
📚 Подборка материалов:
🎧 Camunda и BPMN в микросервисах для процессов техподдержки
📝 Оркестрация и API Gateway – разбор реального примера
🎧 Внедряем Camunda: обзор и моделирование BPMN
#АрхитектураGA
🔥20❤8👍2
В микросервисах важны не только сервисы, но и связи между ними. Если интеграции не продуманы — данные расходятся, появляются дубли, а разбор инцидентов превращается в хаос.
Чтобы вы на практике научились проектировать такие процессы, мы готовим новый открытый онлайн-практикум:
🟢 Онлайн
План практикума:
1. Как и зачем проектировать микросервисы
2. API Gateway: роль в архитектуре и границы ответственности
3. Введение в брокеры сообщений: Kafka
4. Хореография микросервисов: практика описания процессов через события
Урок будет полезен, если вы:
• готовитесь к интервью на Middle+ / Senior СА,
• хотите расширить техническую базу и работать с архитектурными задачами,
• или стремитесь работать в команде, где микросервисы — это реальность, а не теория.
Нужен реальный опыт в архитектуре?
Регистрируйтесь и присоединяйтесь к эфиру 12 марта в 19:00 Мск! 🔥
———
Онлайн-практикум является вводным уроком к программе Проектирование архитектуры для системных аналитиков, которая стартует 17 марта.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥17❤6
Forwarded from 👩🏻💻 Подкаст Системных Аналитиков | GetAnalyst
Разобрали, как low-code внедряют в крупные корпоративные системы: с полноценной разработкой и реальными нагрузками — и как системный аналитик с его помощью двигает продукт наравне с разработчиками.
Обсудили классный проект с голосовым роботом-помощником 🤖
Если вы хотите больше работать с техническими задачами, говорить с разработчиками на одном языке и приносить результат для продукта не только “в требованиях”, а в работающих решениях — этот выпуск для вас!
Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video
🌐 GetAnalyst — профессиональная среда для тех, кто хочет уверенно расти в системном анализе и архитектуре
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥12❤8❤🔥1😢1💯1
This media is not supported in your browser
VIEW IN TELEGRAM
❤6😱1🤣1
А так…. все ссылки собрала для вас тут 🙃
Разрешено в РФ
✅ VK
✅ Мессенджер Max
✅ RuTube
✅ Сайт GetAnalyst.ru
В нестабильной зоне - Telegram:
⚠️ GetAnalyst Навыки - продвинутый уровень
⚠️ Для начинающих в СА и БА
⚠️ Чат сообщества
⚠️ Подкаст (здесь ссылки на все аудио-площадки)
Доступно под VPN:
🔺 Instagram
🔺 LinkedIn
🔺 YouTube
👉 Подписывайтесь сейчас, чтобы не терять доступ к базе знаний GetAnalyst и продолжать ежедневное обучение 🚀
С добром и заботой,
Екатерина Ананьева,
и команда GetAnalyst 🤍
Разрешено в РФ
✅ VK
✅ Мессенджер Max
✅ RuTube
✅ Сайт GetAnalyst.ru
В нестабильной зоне - Telegram:
⚠️ GetAnalyst Навыки - продвинутый уровень
⚠️ Для начинающих в СА и БА
⚠️ Чат сообщества
⚠️ Подкаст (здесь ссылки на все аудио-площадки)
Доступно под VPN:
🔺 YouTube
👉 Подписывайтесь сейчас, чтобы не терять доступ к базе знаний GetAnalyst и продолжать ежедневное обучение 🚀
С добром и заботой,
Екатерина Ананьева,
и команда GetAnalyst 🤍
1❤25👌5🤔1🤣1
Мы умеем быть разными: мягкими, сильными, умными, красивыми — и гораздо глубже, чем просто внешность.
Мы держим в голове десятки задач, замечаем детали, собираем хаос в логику. И часто держим на себе больше, чем о нас принято думать. Не только в работе, но и в жизни.
С 8 марта, дорогие девушки!
Пусть весна и любовь согревают вас, а ваше сияние — всё вокруг 🌸💐🩷☀️
Пусть вас ценят по-настоящему — и в работе, и в жизни! 💙
Мы держим в голове десятки задач, замечаем детали, собираем хаос в логику. И часто держим на себе больше, чем о нас принято думать. Не только в работе, но и в жизни.
С 8 марта, дорогие девушки!
Пусть весна и любовь согревают вас, а ваше сияние — всё вокруг 🌸💐🩷☀️
Пусть вас ценят по-настоящему — и в работе, и в жизни! 💙
1❤23❤🔥7🎉4🍾2