Если бы майские выходные были фичей, это был бы самый долгожданный релиз года 🥳

Release notes:
«Добавлена долгожданная функция безопасного отключения от рабочих чатов, алерты мониторинга пересылаются в никуда, а уровень кофеина падает до безопасного для сна».

Всем классных выходных!
Ваша команда GetAnalyst ☀️

👉📚 7 шаблонов архитектуры, которые важно знать СА 📚

Системный аналитик описывает внутреннюю логику приложений:
+ связи между UI (экранами), БД и API
+ интеграции с внешними системами
+ алгоритмы обработки данных
+ и другие технические детали

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

А вот в сложных продуктовых компаниях, таких как банки, маркетплейсы и страховые компании, базовых знаний недостаточно. Здесь чаще встречается сложная сервисная (SOA) или микросервисная (MSA) архитектура.

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


👉 Собрала для вас 7 основных шаблонов проектирования архитектуры, которые важно знать и понимать СА:

1. Монолит
2. Слоистая архитектура
3. Модульная архитектура
4. Клиент-Серверная архитектура
5. Сервис-ориентированная Архитектура (SOA)
6. Микросервисная архитектура (MSA)
7. Событийно-ориентированная архитектура (EDA)


Все подробности, примеры и иллюстрации — в мини-книге, прикреплённой к посту 🙌📚

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

✅ Все компоненты архитектуры: шпаргалка для системных аналитиков и архитекторов ✅

Компонент — логически и технологически изолированный модуль архитектуры, реализующий строго определённые функции.

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

При построении архитектурной схемы системный аналитик / архитектор должен зафиксировать все компоненты, их зоны ответственности и показать способы взаимодействия — используемые протоколы, API или SDK.

Frontend-компоненты:

🖥 Сайты — информационные веб-страницы, без функций управления данными, только чтение. Дополнительно могут работать с заявками, управлением контентом (CMS), минималистичными ЛК пользователей и приемом платежей.

📱 Мобильные приложения — нативные (iOS, Android) или кросс‑платформенные (Flutter/React Native) клиенты с доступом к датчикам и оборудованию устройства, офлайн‑кэшем и пуш‑уведомлениями.

🖥 Веб-приложения — одно‑ или многостраничные приложения, работающие в браузере. Могут устанавливаться на сервера как независимо от Backend, так и включать в себя Backend (монолиты).

💻 Десктоп-приложения — устанавливаемые на компьютер программы, которые получают доступ к файловой системе, драйверам, оборудованию, и могут работать оффлайн. Например, редакторы фотографий, приложения банкоматов, кассы.

🔗 Виджеты — встраиваемые мини‑приложения (JS/iframe‑компоненты), добавляющие отдельную функцию в чужой интерфейс, без изменения кода и полного перезапуска той системы, куда они встраиваются.

Backend-компоненты:

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

🔹 Сервисы — логически выделенный компонент системы, отдельное backend-приложение средних размеров с ограниченным набором бизнес-логики. Деплоится и масштабируется независимо от остальных сервисов. Может иметь свою БД или использовать общую с другими сервисами.

🔹 Микросервисы — небольшой автономный сервис, владеющий узким бизнес‑контекстом, меньшим, чем у обычных сервисов, и (часто) со своей БД. Деплоится и масштабируется независимо от остальных сервисов.

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

🔹 Базы данных (БД) — отвечают за хранение текстовых данных в определенной структуре: реляционные (PostgreSQL, Oracle и другие), NoSQL, time‑series.

🔹 Файловое хранилище (ФХ) — компонент, отвечающий за долговременное хранение документов, фото, медиа и других файлов системы.

🔹 Брокеры сообщений — асинхронный обмен сообщениями (Kafka, RabbitMQ и другие).

🔹 Шина данных, ESB (Enterprise Service Bus) — интеграционная шина уровня предприятия, которая объединяет разнородные приложения через единый коммуникационный слой и «умную» посредническую логику. Типична для SOA архитектуры.

🩶 Внешние системы — платёжные системы, CRM, ЭДО и другие системы, с которыми нужна интеграция.

Hardware-компоненты:

🎥 Камеры
🖨 Принтеры, чековые терминалы
💳 Считыватели банковских карт
🎙 Микрофоны
📦 RFID/Barcode‑сканеры
🌡 IoT‑датчики (температура, влажность, движение).
и другие.



Используйте этот перечень как чек‑лист.

Он гарантирует, что в архитектурном описании не останется «слепых зон».
Каждый компонент должен быть явно показан на схеме — например, в нотации C4.

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

✍️ Сравнение Монолита, Сервисной и Микросервисной архитектур ✍️

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

В этом посте знакомимся с наиболее распространенными видами архитектуры:


🔸 Монолит
Все компоненты приложения находятся в одной кодовой базе и работают как единое целое.

БД:
Обычно одна, но допустимо и несколько.

Внутренние интеграции:
Компоненты взаимодействуют только на уровне кода, интеграции компонентов внутри Backend по API и другими способами НЕ нужны.


🔸 Сервис-ориентированная архитектура, SOA
Разделяет функциональность на отдельные сервисы.
Подходит для средних и крупных проектов, где важно обеспечивать высокий уровень производительности для отдельных частей системы.

БД:
Каждый сервис может использовать свою собственную БД.
Также несколько сервисов могут использовать одну общую БД - это отличает SOA от MSA.

Внутренние интеграции:
Сервисы взаимодействуют между собой через сетевые вызовы - по API, через шину данных (ESB) или другими способами.


🔸 Микросервисная архитектура, MSA
Состоит из множества маленьких, независимо разрабатываемых и развертываемых сервисов, каждый из которых выполняет определенную бизнес-логику.

Микросервисы меньше по функциональности, чем сервисы.

Подход эффективен для больших и быстро развивающихся приложений.

БД:
Каждый микросервис управляет своей собственной БД.

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



👉 Выбор архитектуры проекта зависит от специфики и НФТ к системе.

На практике часто используют либо смесь подходов SOA и MSA, либо начинают проекты с монолита и через 3-5 лет задумываются о переезде на SOA в качестве первого этапа деления монолита на микросервисы.

Ключевые подходы к проектированию архитектуры фиксируют в документации. И это не только схемы архитетуры, но и правила, по которым продолжать развивать проект ✅

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

🔮 Микросервисная архитектура (МСА) — современный подход к разработке высоконагруженных приложений.


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

✅ Клиенты — это Frontend-приложения или другие системы, которые взаимодействуют с Backend (сервер-приложениями).


✅ CDN (Content Delivery Network) — сеть серверов, стратегически распределенных по всему миру. Они кэшируют и доставляют статические ресурсы (изображения, скрипты и т. д.) пользователям с ближайшего сервера, оптимизируя время загрузки.


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

Он также может управлять аутентификацией, ограничением количества запросов (rate limiting) и другими доп. функциями.


✅ Микросервисы — это независимые компоненты, каждый из которых выполняет свою конкретную бизнес-логику.

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


✅ Брокер сообщений — обеспечивает асинхронное взаимодействие между микросервисами.

Развязка сервисов через брокер (например, Kafka, RabbitMQ) делает систему более гибкой и отказоустойчивой, позволяя микросервисам работать независимо.


✅ Базы данных — в МСА действует принцип "база данных на сервис". Этот принцип предотвращает жёсткие связи между сервисами и позволяет использовать разные технологии хранения данных (polyglot persistence), выбирая оптимальные решения под конкретные задачи.


✅ Identity Provider — отвечает за аутентификацию (проверку личности пользователя) и авторизацию (определение прав доступа).


✅ Service Registry and Discovery — динамический каталог, в котором микросервисы регистрируются и находят друг друга.


✅ Service Coordination — инструменты, которые помогают управлять координацией и синхронизацией распределенных сервисов, обеспечивая их бесперебойную работу и согласованность данных.


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

🧐 Зачем нужен API Gateway? 10 главных функций 👇

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

🪄 В потоке рабочих задач и домашних дел можно забивать заниматься саморазвитием.

То, что считалось новым и актуальным 5 лет назад, сегодня уже база, которую ты должен знать.

Знания устаревают быстрее, чем мы успеваем их освоить 🥲

А хочется всегда быть "в тренде" и лучшей версией себя.

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


👉 Учёба и саморазвитие – это топливо, которое двигает меня вперёд. В карьере, в жизни, в эмоциональном плане.
Поэтому каждый день я ищу возможность посвятить время обучению. Хотя бы 30-60 минут.

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


👉 Даже когда устаю — именно учёба возвращает мне силы, фокус и ощущение движения вперёд.

Особенно заряжают на учёбу встречи с разработчиками, с CEO и CTO компаний, у которых за плечами 20+ лет опыта и несколько стартапов в США.
После разговоров с ними будто включается внутренний мотор: хочется не просто знать больше, а сразу пробовать, применять, развиваться 🤩


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

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

И пусть этот рост приносит в нашу жизнь важные, настоящие и радостные перемены ❤️‍🔥📈🌱