Микросервисы — ключевые шаблоны проектирования
(описание в следующем посте)

Микросервисы — ключевые шаблоны проектирования
(описание к предыдующему посту)

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

Netflix стал первопроходцем в применении архитектуры микросервисов, разбив своё монолитное приложение на сотни небольших сервисов.

Это позволило компании быстро масштабироваться и добиться высокой доступности.

Если вы переходите на архитектуру микросервисов, обратите внимание на следующие шаблоны:

[1.] Шаблон API‑шлюз (API Gateway)
◾️ единая точка входа для клиентов;
◾️ обработка маршрутизации;
◾️ аутентификация;
◾️ решение прочих сквозных задач.

[2.] Шаблон Прерыватель цепи (Circuit Breaker)
◾️ предотвращает каскадные сбои за счёт изоляции неисправных сервисов.

[3.] Шаблон Агрегатор (Aggregator)
◾️ объединяет данные из нескольких сервисов в единый ответ.

[4.] Шаблон Цепочка (цепочка ответственности) (Chained (Chain of Responsibility))
◾️ упорядочивает обработку запросов через последовательность сервисов.

[5.] База данных для каждого сервиса (Database per Service)
◾️ каждый сервис имеет собственную приватную базу данных для слабой связности.

[6.] Шаблон Saga
◾️ управляет распределёнными транзакциями между сервисами с помощью серии локальных транзакций.

[7.] Шаблон Сайдкар (Sidecar)
◾️ расширяет функциональность сервиса за счёт отдельного компонента, развёрнутого рядом.

[8.] Бэкенды для фронтендов (BFF / Backends for Frontends)
◾️ создаёт специализированные бэкенд‑сервисы для конкретных фронтендов.

[9.] CQRS (Command Query Responsibility Segregation - разделение ответственности за команды и запросы)
◾️ разделяет операции чтения и записи для улучшения масштабируемости и производительности.

[10.] Шаблон Event Sourcing
◾️ фиксирует все изменения состояния приложения в виде последовательности событий.

[11.] Асинхронный обмен сообщениями
◾️ обеспечивает слабую связность между сервисами с помощью очередей сообщений или брокеров.

[12.] Шаблон Strangler Fig
◾️ поэтапно переносит монолитное приложение на микросервисы.

[13.] Внешняя конфигурация
◾️ хранит настройки конфигурации вне кода приложения.

[14.] Централизованное логирование и мониторинг
◾️ агрегирует журналы и метрики из всех микросервисов для наблюдаемости.

[15.] Шаблон Обнаружение сервисов (Service Discovery)
◾️ позволяет сервисам динамически находить друг друга.

[16.] Шаблон Anti-Corruption Layer
◾️ создаёт слой изоляции, чтобы защитить ваше приложение от негативного влияния изменений во внешних системах.

[17.] Шаблоны декомпозиции
◾️ стратегии разбиения монолитного приложения на микросервисы:

1. Декомпозиция по бизнес‑возможностям → привязка сервисов к отдельным бизнес‑функциям (например, обработка заказов, управление запасами).
2. Декомпозиция по поддоменам → дальнейшее разделение возможностей на более мелкие и сфокусированные сервисы (например, управление клиентами в рамках заказов).

«Золотая середина» между монолитной и микросервисной архитектурами — модульный монолит.

Вышла новая версия среды разработки Qt Creator - Qt Creator 18. (Qt Creator предназначен для создания кроссплатформенных приложений с использованием библиотеки Qt и языков C++, Python и QML/JavaScript)

Резюме изменений в Qt Creator 18

1. Поддержка контейнеров разработки: Добавлена экспериментальная поддержка контейнеров разработки ("Development Containers") для автоматизации настройки среды проекта. Контейнеры создаются на основе файла "devcontainer.json" и позволяют автоматически настраивать наборы инструментов (kits).

2. Обзорная вкладка "Overview": Новый интерфейс включает вкладку "Overview" на экране приветствия, объединяя полезную информацию из других вкладок. Она рекомендует учебные пособия и примеры, основываясь на потребностях разработчика, и выделяет посты разработчиков из блога Qt.

3. Интерфейс редактирования: Реализована возможность выбора редактора с вкладками. Улучшена интеграция с инструментом Clangd версии 21.1, улучшен встроенный код-моделлер для поддержки новых функций C++, добавлены быстрые исправления кода, такие как удаление фигурных скобок и автоматическое создание определений статических членов класса.

4. Работа с проектами: Файлы настроек проектов (.user) теперь хранятся в подпапке .qtcreator/, что улучшает совместимость старых проектов. Появилась возможность фильтрации отображаемых конфигураций сборки и запуска, позволяя выбирать доступные комплекты или настроенные конфигурации. Настройки построения и запуска были перемещены из окна набора инструментов в отдельные вкладки.

5. Удалённые устройства: Усовершенствована настройка удалённых устройств, позволяющая автоматически обнаруживать инструменты вроде GDB-серверов, CMake, clangd и других. Поддерживаются инструменты на удаленных устройствах Linux. Возможность автоматического подключения к устройствам при запуске IDE и использование утилиты rsync для развертывания приложений на удалённом устройстве.

6. Тестирование: Для проектов на основе CMake появилась поддержка тестовых пресетов и фильтр "ct" для запуска тестов на основе CTest.

7. Интеграция с GitHub: Подключён GitHub Copilot для корпоративных сред GitHub Enterprise.

8. Другие улучшения: Обновлён редактор коммитов для Git, позволяющий быстрее управлять файлами перед отправкой. Были устранены многие мелкие проблемы и улучшены функциональные возможности интерфейса.

https://www.qt.io/blog/qt-creator-18-released

Событийно‑ориентированная архитектура (Event-Driven Architecture )
(описание к предыдущему посту)

Обзор

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

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

→ Генератор событий — создаёт и отправляет события при наступлении определённых ситуаций (например, «Заказ оформлен»).
→ Канал событий — передаёт события от генераторов к потребителям (например, через брокеры сообщений вроде Kafka, RabbitMQ).
→ Потребитель событий — отслеживает события и выполняет действия в ответ на них (например, обновляет запасы после оформления заказа).
→ Хранилище событий — опционально сохраняет прошедшие события для аудита или повторной обработки.

Поток обработки

→ Происходит событие → Генератор публикует его в канале событий → Потребители подписываются и реагируют → Действия обрабатываются независимо.

Преимущества

→ Высокая масштабируемость благодаря асинхронной обработке.
→ Слабая связанность компонентов позволяет независимо разрабатывать и развёртывать сервисы.
→ Реагирование на действия в системе в режиме реального времени.
→ Простая интеграция новых сервисов — достаточно подписаться на соответствующие события.

Недостатки

→ Сложность отладки и мониторинга из‑за асинхронного поведения.
→ Возможны дублирование событий или потеря сообщений при отсутствии должной обработки.
→ Требуется надёжная инфраструктура брокеров сообщений и согласованные схемы событий.

Рекомендации к применению

→ Чёткие правила именования событий («ЗаказСоздан», «ОплатаЗавершена»).
→ Идемпотентность потребителей, чтобы избежать повторной обработки событий.
→ Централизованный журнал событий для отслеживания.
→ Реализация обработки ошибок и повторные попытки при неудачном потреблении событий.

Когда применять

→ В системах, требующих обновлений в реальном времени (финансы, IoT, электронная коммерция).
→ В микросервисных архитектурах с минимальными зависимостями между сервисами.
→ В масштабируемых системах с высокой пропускной способностью по обработке событий.

Наглядно как работает LLM

Как работает Elasticsearch
(подробное описание в следующем посте)

Как работает Elasticsearch
(описание к предыдущему посту)

Elasticsearch использует инвертированный индекс, чтобы обеспечить быстрый полнотекстовый поиск и эффективный доступ к данным.

Принцип его работы аналогичен тому, как устроен указатель в книге.

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

Мощный язык запросов DSL и эффективный механизм индексирования позволяют решать широкий спектр поисковых задач — от простых до сложных.

Чтобы лучше понять, как это работает, рассмотрим рабочий процесс системы:

1. Приём данных
→ Elasticsearch начинает с импорта данных в формате JSON — как напрямую, так и через инструменты вроде Logstash и Beats.

2. Индексирование
→ Затем система индексирует данные, создавая инвертированный индекс. Это позволяет быстро находить текстовые фрагменты, связывая термины с их местоположением в документах.

3. Шардинг и репликация
→ Система распределяет данные по узлам посредством шардирования. Репликация повышает отказоустойчивость и доступность данных.

4. Поиск
→ Язык запросов DSL позволяет пользователям выполнять поиск: система обращается к инвертированному индексу и быстро находит нужные документы.

5. Анализ и агрегация
→ Elasticsearch также даёт возможность анализировать данные и составлять сводки, выявляя тенденции и закономерности.

6. Получение результатов
→ Система извлекает и возвращает результаты запроса практически в режиме реального времени.

Ключевые преимущества Elasticsearch:
* исключительная масштабируемость;
* возможность поиска в реальном времени;
* интуитивно понятный RESTful API, который позволяет эффективно анализировать большие объёмы данных.

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

Сферы применения Elasticsearch разнообразны:
* мгновенный поиск товаров на платформах электронной коммерции;
* анализ транзакций в финансовых системах в режиме реального времени;
* системы мониторинга и журналирования — здесь Elasticsearch агрегирует и анализирует логи, давая детальную картину состояния системы и потенциальных угроз безопасности.

Кто-то предпочитает один отступ в коде, кто-то 2 или 4 отступа или табуляцию, а кто-то отступы в соответствие с числами Фибоначчи

Стратегии версионирования API
(описание в следующем посте)

Стратегии версионирования API:
(описание к предыдущему посту)

1. URI Versioning (Версионирование через URI) — добавление номера версии в URL для ясности и простоты.
Пример: /api/v1/products.

2. Path Versioning (Версионирование через путь) — версия встраивается непосредственно в путь API для наглядности.
Пример: /api/v2/products.

3. Query Parameter Versioning (Версионирование через параметры запроса) — версия указывается как параметр запроса, сохраняя чистоту структуры URL.
Пример: /api/products?version=1.

4. Subdomain Versioning (Версионирование через поддомены) — для каждой версии используются отдельные поддомены, полностью разделяя их.
Пример: v2.api.example.com/products.

5. Header Versioning (Версионирование через заголовки) — версия передаётся в заголовках запроса, URL остаётся неизменным.
Пример: GET /products Header: Accept: application/vnd.example.v1+json.

6. Timestamp Versioning (Версионирование по временным меткам) — версии основаны на временных метках, что обеспечивает гибкость при релизах.
Пример: /api/products?version=2023-10-01.

7. Content Negotiation (Согласование содержимого) — использует заголовок Accept для запроса разных версий и форматов.
Пример: GET /products Header: Accept: application/json; version=1.

8. Semantic Versioning (Семантическое версионирование) — следует семантическому версионированию (например, v1.0.0) для обозначения основных, второстепенных и патчевых изменений.
Пример: /api/products/v1.0.0.

Многие используют СУБД Postgres, но не многие знают, что Postgres предоставляет специальную утилиту для проверки производительности - explain.
Для проверки производительности работы с базой данных регулярно запускайте команды explain и explain analyze и научитесь интерпретировать их выходные данные. Это может помочь найти узкие места при запросах к БД

#sql #postgresql #database

Архитектурные паттерны в проектировании систем
(описание предыдующего поста)

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

→ 1. МНОГОУРОВНЕВАЯ (N‑УРОВНЕВАЯ) АРХИТЕКТУРА

→ Система разделена на уровни, такие как:
→ Уровень представления → Уровень бизнес‑логики → Уровень доступа к данным → База данных
→ Каждый уровень взаимодействует только с уровнем, расположенным непосредственно под ним
→ Способствует разделению ответственности и упрощает сопровождение
→ Широко применяется в корпоративных и веб‑приложениях

→ 2. АРХИТЕКТУРА «КЛИЕНТ‑СЕРВЕР»

→ Клиент отправляет запросы → Сервер обрабатывает запросы и возвращает ответы
→ Позволяет создавать распределённые системы, в которых множество клиентов взаимодействуют с централизованными серверами
→ Используется в веб‑приложениях, API и мобильных бэкендах

→ 3. АРХИТЕКТУРА МИКРОСЕРВИСОВ

→ Приложение разбивается на независимые, слабо связанные сервисы
→ Каждый микросервис управляет собственной базой данных и взаимодействует через API
→ Обеспечивает горизонтальное масштабирование и независимое развёртывание
→ Оптимальна для крупных, сложных систем, требующих гибкости

→ 4. Событийно‑ориентированная АРХИТЕКТУРА

→ Компоненты взаимодействуют посредством событий
→ Производители генерируют события → Потребители отслеживают и реагируют на них
→ Улучшает асинхронную обработку и оперативность реагирования в реальном времени
→ Широко используется в системах потоковой передачи данных, аналитики и IoT

→ 5. СЕРВИСНО‑ОРИЕНТИРОВАННАЯ АРХИТЕКТУРА (SOA)

→ Система строится на основе взаимодействующих сервисов
→ Каждый сервис выполняет бизнес‑функцию и взаимодействует по сети (часто через SOAP или REST)
→ Способствует повторному использованию и интеграции между системами
→ Предшественница архитектуры микросервисов

→ 6. ШАБЛОН EVENT‑SOURCING

→ Система хранит события, а не только текущее состояние
→ Каждое изменение фиксируется как неизменяемое событие в журнале
→ Позволяет вести аудит, откат и воспроизведение состояния системы
→ Часто применяется в финансовых и транзакционных системах

→ 7. CQRS (РАЗДЕЛЕНИЕ ОТВЕТСТВЕННОСТЕЙ ЗА КОМАНДЫ И ЗАПРОСЫ)

→ Разделяет операции чтения и записи
→ Команды → изменяют данные
→ Запросы → считывают данные
→ Повышает масштабируемость и поддерживает событийно‑ориентированные системы

→ 8. АРХИТЕКТУРА КОНВЕЙЕРА (ПОТОКА ДАННЫХ)

→ Данные проходят через последовательность этапов обработки
→ Каждый этап выполняет преобразование перед передачей дальше
→ Применяется в процессах ETL, обработке данных и конвейерах машинного обучения

→ 9. ОДНОРАНГОВАЯ АРХИТЕКТУРА (P2P)

→ Все узлы выступают одновременно в роли клиентов и серверов
→ Отсутствует центральный управляющий элемент — данные передаются напрямую между узлами
→ Широко используется в блокчейне, торрент‑системах и распределённых хранилищах

→ 10. ПРОСТРАНСТВЕННАЯ АРХИТЕКТУРА (SPACE‑BASED)


→ Устраняет узкие места, связанные с базой данных, за счёт репликации данных в памяти (данные в гридах)
→ Подходит для систем с высокой нагрузкой и низкой задержкой, таких как платформы электронной коммерции или торговых систем

→ Краткий совет

→ Каждый архитектурный шаблон решает свои задачи:
→ Многоуровневая → простота и структурированность
→ Микросервисы → масштабируемость и независимость
→ Event-Sourcing → оперативность реагирования
→ CQRS/событийное источниковедение → согласованность и возможность аудита
→ Пространственная → производительность и отказоустойчивость

Странный способ для запоминания формул графиков, но тем не менее

Принципы SOLID
(описание в следующем посте)