Событийно‑ориентированная архитектура (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
(описание в следующем посте)

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

Принципы SOLID** — краеугольный камень объектно‑ориентированного программирования. Они помогают разработчикам создавать поддерживаемые, масштабируемые и надёжные архитектуры программного обеспечения.

Эти принципы были предложены Робертом С. Мартином (Дядей Бобом), хотя на их формирование повлияли и более ранние работы.

Вот список принципов:

**1. Принцип единственной ответственности (SRP)

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

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

Например, можно создать класс UserManager для обработки операций, связанных с пользователями: аутентификации, взаимодействия с базой данных и отправки email‑уведомлений. Если мы изменим, скажем, логику отправки email‑уведомлений, это может повлиять на другие области — например, на аутентификацию пользователей. Такие классы иногда называют «божественными классами» (*God classes*).

2. Принцип открытости/закрытости (OCP)

Программные сущности (классы, методы и т. д.) должны быть открыты для расширения, но закрыты для модификации. Это способствует стабильности и расширяемости. Иными словами, вы можете добавить новую функциональность в класс, не изменяя его существующий код.

3. Принцип подстановки Барбары Лисков (LSP)

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

4. Принцип разделения интерфейса (ISP)

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

5. Принцип инверсии зависимостей (DIP)

Модули высокого уровня не должны зависеть от модулей низкого уровня; и те, и другие должны зависеть от абстракций. Это поощряет слабосвязанную архитектуру. Кроме того, абстракции не должны опираться на детали — детали должны зависеть от абстракций.

После сокрашения штата ради ИИ компании стали возвращать сотрудников

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

Visier проанализировала данные о занятости 2,4 млн сотрудников из 142 компаний по всему миру. Около 5,3% уволенных заявляли, что они вернулись к предыдущему работодателю. Этот показатель оставался стабильным в течение нескольких лет, но недавно начал расти.

Директор Visier Андреа Дерлер отметила, что, согласно данным, многие организации теперь сталкиваются с плюсами и минусами внедрения ИИ. Она назвала искусственный интеллект удобным, но пока не полностью обоснованным объяснением увольнений.

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

Дерлер уверена, что многие руководители высшего звена просто не успели оценить фактические затраты на крупномасштабное внедрение ИИ или определить, какие роли можно автоматизировать. Внедрение инфраструктуры ИИ — оборудования, систем данных и фреймворков безопасности — требует значительных капитальных затрат. Эти затраты часто превышают первоначальные прогнозы, вынуждая руководство пересматривать фактическую окупаемость инвестиций по сравнению с удержанием квалифицированных сотрудников.
https://www.axios.com/2025/11/04/ai-jobs-layoffs-amazon

Шпаргалка по фильтрам для анализатора пакетов Wireshark

Топ-6 типов моделей ИИ
(подробное описание в следующем посте)

Топ-6 типов моделей ИИ
(описание к предыдущему посту)

1. Machine Learning Models (Модели машинного обучения)
- Описание: учатся на размеченных или неразмеченных данных для выявления закономерностей, классификации или прогнозирования результатов. Включают подходы с учителем, без учителя и с частичным обучением.
- Примеры: деревья решений, Random Forest, SVM, XGBoost (с учителем); K-Means, DBSCAN, PCA (без учителя); Label Propagation, Semi-Supervised SVM (с частичным обучением).
- Рабочий процесс: сбор размеченных данных → очистка и предобработка → выбор алгоритма ML → обучение модели → мониторинг и обновление → прогнозирование на новых данных → настройка гиперпараметров → проверка производительности.

2. Deep Learning Models (Модели глубокого обучения)
- Описание: используют многослойные нейронные сети для изучения сложных иерархических паттернов, особенно эффективны для неструктурированных данных (изображения, аудио, текст).
- Примеры: CNN (для изображений), RNN, LSTM (для последовательностей), трансформеры, автоэнкодеры.
- Рабочий процесс: сбор больших объёмов данных → нормализация входных данных → построение нейронной сети → передача входных данных → вычисление ошибки предсказания → повторение циклов обучения → обновление весов → обратное распространение градиентов.

3. Generative Models (Генеративные модели)
- Описание: изучают распределение данных и генерируют новые данные, имитирующие исходные. Применяются для создания контента, синтеза изображений и генерации текста.
- Примеры: GPT-4 (текст), DALL·E, MidJourney (изображения), MusicLM (аудио), StyleGAN (лица), AlphaCode (код).
- Рабочий процесс: обучение на датасете → изучение паттернов данных → получение пользовательского ввода → обработка через модель → вывод сгенерированного медиа → уточнение с помощью обратной связи → генерация нового контента → выборка из выходных данных.

4. Hybrid Models (Гибридные модели)
- Описание: комбинируют несколько техник ИИ (например, правила + нейронные сети) для использования преимуществ каждой. Применяются там, где важны точность и контроль.
- Примеры: RAG (LLM + поиск), ML + боты на основе правил, AutoGPT с инструментами, чат-боты с API.
- Рабочий процесс: объединение типов моделей → обучение компонентов отдельно → построение логической связи → ввод через конвейер → получение конечного результата → разрешение конфликтов → агрегация выходных данных → маршрутизация на основе логики.

5. NLP Models (Модели обработки естественного языка)
- Описание: обрабатывают и понимают человеческий язык. Используются в чат-ботах, переводчиках, сумматорах и виртуальных ассистентах.
- Примеры: BERT, GPT-3.5 / GPT-4, T5, RoBERTa, Claude.
- Рабочий процесс: очистка необработанного текста → токенизация предложений → встраивание слов → применение слоёв внимания → генерация финального текста → постобработка результата → декодирование или классификация → передача в модель.

6. Computer Vision Models (Модели компьютерного зрения)
- Описание: интерпретируют визуальное содержимое, выявляя паттерны и особенности в изображениях или видео. Применяются в распознавании лиц, медицинской визуализации и др.
- Примеры: ResNet, YOLO, VGGNet, EfficientNet, Mask R-CNN.
- Рабочий процесс: загрузка данных изображений → изменение размера и нормализация → извлечение пиксельных признаков → применение слоёв CNN → вывод меток/коробок → постобработка результатов → классификация или локализация → обнаружение пространственных паттернов.

Все, что человеку нужно, - это не любовь, а математика