⚡ Доступ к обучению по Архитектуре с 31 мая до 2 июня ⚡

Пытаетесь самостоятельно разобраться в архитектуре систем и расти в карьере, но не хватает практики и понятных примеров? Давайте сделаем это вместе — пошагово и на реальном кейсе!

Мы готовим открытый практикум для системных аналитиков, чтобы вы на практике поняли, как проектируется архитектура:


🚀 От монолита к микросервисам: пошаговый план с примером
🗓 Доступ с 31 мая до 2 июня [сб - пн]
🔗 ЗАРЕГИСТРИРОВАТЬСЯ

Занятие в записи. Вы сможете посмотреть его в удобное для вас время.


План:
✅ Плюсы и минусы монолита — на реальном проекте.
✅ Что такое SOA и MSA, чем отличаются и когда используются.
✅ Как делить монолит на микросервисы.
✅ Проработаете миграцию модуля в микросервис: БД, ER-диаграмма, вынос данных.
✅ Осознаете, почему делают модульный монолит перед переходом к микросервисам.
✅ Узнаете, как аналитик может расти в сторону архитектуры и какие навыки нужны для этого.


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

Успейте зарегистрироваться — доступ будет открыт только с 31 мая по 2 июня! 🙌

🔵 C4 / Container - пример микросервисной архитектуры #GreenChargeGA 🔵

Уровень C4 / Container показывает независимые по коду приложения в системе — так называемые контейнеры [к].

Что включает схема на этом уровне:
✔️ Пользователи
✔️ Внешние системы
✔️ Мобильные, веб- и десктоп приложения [к]
✔️ Микросервисы [к]
✔️ API Gateway (маршрутизатор API-запросов) [к]
✔️ БД и ФХ [к]
✔️ API для взаимодействия сервисов
✔️ Брокеры для асинхронного обмена [к]

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


📌 Ранее я показывала архитектуру GreenChargeGA в виде "квадратиков и стрелочек", теперь, в прикреплённой к посту схеме, используется нотация C4 > уровень Container.

Что добавила C4:
✅ Чёткие указания на используемые API и протоколы
✅ Указание языков программирования и фреймворков всех приложений
✅ Технологии БД и файловых хранилищ

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


Недостатки показанной архитектуры, которые будем дорабатывать:
❌ Нет связи от Firebase к фронтам, куда доставляются уведомления
❌ Синхронизация всего через один API Gateway? Плохо масштабируемая и уязвимая идея
❌ Всё синхронно внутри? Не надёжно 🥲 Надо ещё брокеров
❌ Не показаны WebHooks от платежных систем
Подумайте уже сейчас, как исправить эти недостатки на схеме 😉


💡Лайфхак
Для простоты восприятия можно объединить все микросервисы и инфраструктуру в один контейнер «Backend», а детали вынести на уровень C4/Component.
Но это будет противоречить нотации.

💡На практике
Команды часто адаптируют C4 под свои нужды. Я же рекомендую придерживаться здравого смысла, прозрачности и принципа "понятно с первого взгляда".

📚 Связанные материалы:
Нотация C4 и документация по ней
C4 / Context для проекта GreenChargeGA (предыдущий уровень)


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

#АрхитектураGA

📩 Всё про брокеры: как работают и зачем нужны 📩

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

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


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

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

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

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

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

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

По сути брокеры - это временные Базы Данных,

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

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


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

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

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


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

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

#АрхитектураGA

🔔 Уже завтра! Бесплатный практикум по Архитектуре для Системных Аналитиков 🔔

Хотите развиваться в теме проектирования архитектуры и работать в IT-продуктах с брокерами и микросервисами? Тогда вам сюда!


🚀 От монолита к микросервисам: пошаговый план с примером
🗓 Доступ с 31 мая до 2 июня [сб - пн]

👉 Узнать подробнее и зарегистрироваться

🎥 Урок в записи — смотрите в удобное время.


Что разберём:
1. Монолит: плюсы и минусы
2. SOA vs MSA: в чём разница и когда что выбрать
3. Пошаговый план деления монолита на микросервисы
4. Разбор кейса по вынесению модуля из монолита в деталях: архитектура, вынесение данных в отдельную БД, особенности
5. Почему молодым продуктам лучше делать модульный монолит
6. Как аналитику расти в сторону архитектура и что для этого нужно


Практика, реальные кейсы и ответы на вопросы.


Регистрируйтесь, получайте опыт и переходите на новый уровень в системном анализе! 🙌

🤔 Всё про Agile, Scrum, Kanban и «Документация не нужна» 🤔

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

Если вы начинающий системный аналитик или только делаете первые шаги в IT, этот эпизод поможет разобраться, что такое Agile (Scrum, Kanban).

👉 А если вас раздражает фраза “документация не нужна”, вы не понимаете, зачем столько созвонов и почему это всё в Agile — этот выпуск также для вас.


🔗 Сайт эпизода


Слушайте эпизод и расширяйте свою профессиональную экспертизу!


Эпизод доступен в:
⏯ Apple Podcast
⏯ Яндекс.Музыка
⏯ Telegram
⏯ Castbox
⏯ Звук
⏯ Spotify
⏯ RuTube
⏯ YouTube
⏯ VK Video


Участие в сообществе Системных Аналитиков GetAnalyst — это шаг к новому опыту и развитию в карьере каждый день! 💫

Есть такая фраза: "не усложняй".

Это работает и в разработке систем.

Лучшие решения - простые 🙌

И иногда джуны находят эти решения случайно, и лучше, чем опытные специалисты 😀

P.S. Не знаю кто в Hendai сделал эту прекрасную рекламу с котами, но она проста и прекрасна (Оригинал в запретграме) 🐈‍⬛


P.S.S. Доступ к бесплатному обучению по Архитектуре открыт 📚

Я способна отложить абсолютно всё: от похода к врачу до обучения в Гарварде 🙌

Вроде хочешь перемен, а вместо действий — бесконечное «сделаю завтра».

Поход к врачу откладывается до следующего месяца, пробежка вдоль океана — до «когда будет настроение», мечты о новом образовании — на неопределённое «потом» 🙌

А внутри — растущее разочарование и усталость от самой себя.

Так может продолжаться долго.


Мой актуальный рекорд прокрастинации: почти год откладывала обучение и сертификацию Гарварде 🎓

Казалось, ну куда мне — нет времени, а если я тупить буду на английском, бизнес пока маленький… синдром самозванца forever 💗

Но в итоге просто взяла и отправила заявку, пока в очередной раз изучала сайт и раздумывала.
И всё: я в деле, назад дороги нет 🤪🥲

Цель есть. Энергия появилась.
Сейчас готовлюсь, планирую как команды меня подстрахуют, чтобы я могла держать фокус на учёбе.

Получится? Не знаю.
Но я уже в деле и надо будет сдать кучу домашек с жесткими дедлайнами.
У меня появился чёткий план.
И поддерживающее сообщество студентов, кто будет со мной проходить этот путь.



Я уже убедилась: стоит сделать первый шаг — и появляется ощущение лёгкости и силы.

Едва сдвинешься с места — и мир как-будто сам начинает тебе помогать реализовать план 🪄


Так что если ты тоже постоянно откладываешь что-то важное, попробуй сделать маленький шаг уже сегодня.
Просто один шаг навстречу цели.
Ты удивишься, сколько энергии и перемен он может дать 🦄

🎱 8 шагов, чтобы разобраться с Kafka 🎱

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


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


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

#АрхитектураGA

⭐️ Kafka - что надо знать для работы Системному аналитику ⭐️

Apache Kafka — это распределённая платформа потоковой обработки данных.

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


Основные компоненты:

✔️ Продюсеры (Producers)

1) Генерируют сообщения/события к обработке и отправляют в топики (темы).

2) Определяют, в какую партицию топика записывать данные: автоматически или по заданным правилам.

3) Могут быть чем угодно: микросервисы, устройства IoT и другие приложения.

4) Поддерживают режимы отправки:
+ Синхронный — ждёт подтверждения от Kafka перед отправкой следующего сообщения.
+ Асинхронный — отправляет сообщения без ожидания ответа.

5) Могут гарантировать доставку с разными уровнями подтверждения (acks):
+ acks=0 — без ожидания подтверждения (возможна потеря данных, высокая скорость).
+ acks=1 — подтверждение только от лидера партиции (среднее).
+ acks=all — подтверждение от всех реплик (максимальная надёжность).


✔️ Потребители (Consumers)

1) Подписываются на один или несколько топиков и получают сообщения/события.

2) Могут работать как отдельные клиенты или объединяться в группы (Consumer Groups) для параллельной обработки сообщений.

3) В группе консьюмеров каждый участник обрабатывает свою часть партиций.

4) Kafka гарантирует, что каждое сообщение будет обработано хотя бы одним потребителем в группе.

5) Модели доставки сообщений:
+ at-least-once — как минимум 1 раз, возможны дубликаты.
+ exactly-once — ровно один раз.


✔️ Топики (Topics) — логическая тема, куда продюсеры отправляют сообщения, а потребители их читают


✔️ Партиции (Partitions) — подмножество данных внутри топика, которое позволяет распределять нагрузку и масштабировать обработку сообщений. Каждый топик состоит из одной или нескольких партиций


✔️ Брокер (Broker) — сервер Kafka, который отвечает за хранение, управление и передачу данных внутри кластера


✔️ Кластер — это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных


#АрхитектураGA

⭐️ Устройство Kafka: топики, партиции, брокеры, кластеры ⭐️


✔️ Топики (Topics)

1) Логическая категория или тема, куда Продюсеры отправляют сообщения, а Потребители их читают.

2) Представляют собой поток сообщений, где каждое имеет: ключ, значение, метаданные.

3) Не удаляют сообщения сразу после обработки — данные хранятся в топике в течение заданного времени.

4) Могут быть разделены на партиции, что позволяет распределять нагрузку между Продюсерами и Консьюмерами.


✔️ Партиции (Partitions)

1) Каждый топик состоит из одной или нескольких партиций (разделов).

2) Сообщения внутри партиции хранятся в строгом порядке (FIFO — "первым пришёл, первым обработался").

3) Разные партиции могут обрабатываться параллельно, что увеличивает производительность Kafka.

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

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

6) Один потребитель из Группы Консьюмеров читает данные только из своей партиции, что позволяет распределять нагрузку.

7) Повышение надежности обеспечивается через репликацию: выделяют Leader Replica (основная копия данных партиции) и Follower Replica (копирует данные лидера в синхронном или асинхронном режиме).


✔️ Брокеры (Brokers)

1) Хранят топики и их партиции.

2) Обрабатывают запросы Продюсеров на запись и Консьюмеров на чтение данных.

3) Управляют репликацией партиций для отказоустойчивости.

4) Автоматически перераспределяют нагрузку при добавлении новых брокеров в кластер.



✔️ Кластер (Cluster)

1) Это группа брокеров, работающих вместе для масштабирования и распределённой обработки данных.

2) Использует ZooKeeper или KRaft для координации (назначает лидеров партиций, отслеживает состояние брокеров).

3) Позволяет добавлять новые брокеры без остановки системы.

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


#АрхитектураGA