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

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

→ 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 → вывод меток/коробок → постобработка результатов → классификация или локализация → обнаружение пространственных паттернов.

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

Как JVM в Java исполняет байт‑код
(продолжение предыдущего поста)

Вы пишете исходный код Java в файле с расширением .java.
Компилятор Java (javac) преобразует ваш код в платформонезависимый байт‑код, который сохраняется в файлах с расширением .class.
Затем виртуальная машина Java (JVM) загружает эти файлы с байт‑кодом в память для исполнения.

Во время выполнения программы:

→ Загрузчик классов (Class Loader) загружает байт‑код в JVM и обеспечивает доступность классов, когда они требуются.
→ Проверяющий байт‑код (Bytecode Verifier) анализирует код на соответствие требованиям безопасности и типовой корректности перед исполнением.
→ Интерпретатор начинает выполнять инструкции байт‑кода построчно.
→ Компилятор «точно в срок» (Just‑In‑Time, JIT) выявляет часто исполняемые участки кода (горячие точки) и компилирует их в оптимизированный машинный код для повышения производительности.
→ Сборщик мусора (Garbage Collector, GC) автоматически управляет памятью, удаляя из кучи неиспользуемые объекты.
→ Среда выполнения (Runtime Environment) предоставляет необходимые библиотеки, управление потоками и обработку исключений для бесперебойного исполнения программы.

Результат: ваша Java‑программа эффективно работает на всех платформах с использованием JVM, сочетая переносимость с оптимизацией во время выполнения и автоматическим управлением памятью.

Большая супершпаргалка по редактору Vim

Управление процессами в Linux
(продолжение в следующем посте)

Управление процессами в Linux
(продолжение предыдущего поста)

1. Введение

→ Процесс — это экземпляр запущенной программы в Linux.
→ Каждый процесс имеет собственное пространство памяти, контекст выполнения и системные ресурсы.
→ Управление процессами включает создание, планирование, мониторинг и завершение процессов.

2. Жизненный цикл процесса

→ Типичный жизненный цикл процесса включает:
 → Создание — инициируется другим процессом (обычно оболочкой).
 → Выполнение — процесс работает и выполняет задачи.
 → Ожидание — процесс может ожидать ресурсы или события.
 → Завершение — процесс завершается или принудительно останавливается.

→ Ядро управляет всеми переходами между этими состояниями.

3. Типы процессов

→ Процесс переднего плана:
 → Работает в интерактивном режиме и занимает терминал.
 → Пример: vim file.txt

→ Процесс фонового режима:
 → Работает без взаимодействия с терминалом.
 → Пример: ./noscript.sh &

→ Демон‑процесс:
 → Постоянно работает в фоновом режиме, предоставляя сервисы.
 → Примеры: sshd, cron, systemd.

4. Идентификация процессов

→ Каждый процесс идентифицируется PID (идентификатором процесса).
→ PPID (идентификатор родительского процесса) указывает на процесс, который его создал.
→ Процесс init/systemd — предок всех процессов, всегда имеет PID 1.

→ Для просмотра идентификаторов процессов:
 → ps
 → top
 → pgrep process_name

5. Создание процессов

→ В Linux для создания новых процессов используются системные вызовы fork() и exec().

→ fork()
 → Создаёт дубликат текущего процесса.
 → У дочернего процесса присваивается уникальный PID.

→ exec()
 → Заменяет память текущего процесса новой программой.
 → Используется для запуска новых исполняемых файлов.

→ Вместе fork() и exec() составляют основу создания процессов в Linux.

6. Состояния процессов

→ Процессы в Linux могут находиться в нескольких состояниях:
 → R (Running): Выполняется или готов к выполнению.
 → S (Sleeping): Ожидает события или ресурса.
 → D (Uninterruptible Sleep): Ожидает операций ввода‑вывода.
 → T (Stopped): Приостановлен сигналом.
 → Z (Zombie): Завершил выполнение, но ожидает подтверждения от родительского процесса.

→ Используйте ps -aux для просмотра состояний процессов.

7. Планирование процессов

→ Планировщик Linux решает, какой процесс будет выполняться следующим на CPU.
→ Используются алгоритмы планирования, такие как CFS (Completely Fair Scheduler).
→ Приоритеты определяются значениями nice в диапазоне от −20 (наивысший) до +19 (наинизший).

→ Команды:
 → nice -n 10 process_name — запустить процесс с пониженным приоритетом.
 → renice -n -5 PID — изменить приоритет запущенного процесса.

8. Мониторинг процессов

→ Команды для мониторинга активных процессов:
 → ps — снимок запущенных процессов.
 → top — отображение процессов в реальном времени.
 → htop — расширенная интерактивная версия top.
 → pidof — найти PID процесса.
 → pstree — просмотреть иерархию процессов.

9. Управление процессами

→ Управление запущенными процессами с помощью команд оболочки:
 → & — запустить процесс в фоновом режиме.
 → Ctrl + Z — приостановить процесс.
 → bg — возобновить процесс в фоновом режиме.
 → fg — вывести процесс на передний план.
 → kill PID — завершить процесс.
 → kill -9 PID — принудительно завершить процесс.

10. Зомби‑процессы и осиротевшие процессы

→ Зомби‑процесс:
 → Процесс завершил работу, но родительский процесс не прочитал его статус завершения.
 → Существует как запись в таблице процессов.

→ Осиротевший процесс:
 → Родительский процесс завершился до дочернего.
 → Автоматически принимается init/systemd.

→ Оба типа можно отслеживать и управлять ими с помощью ps или top.

11. Демоны и сервисы

→ Демоны — это специальные фоновые процессы, управляемые systemd.
→ Конфигурационные файлы хранятся в /etc/systemd/system/.
→ Команды:
 → systemctl start service_name
 → systemctl stop service_name
 → systemctl status service_name
 → systemctl enable service_name

12. Межпроцессное взаимодействие (IPC)

→ Процессы взаимодействуют с помощью механизмов IPC, таких как:
 → Каналы — для взаимодействия «родитель‑потомок».
 → Очереди сообщений — для обмена сообщениями.
 → Общая память — для совместного использования данных.
 → Семафоры — для синхронизации.
 → Сигналы — для уведомлений (например, SIGKILL, SIGTERM).

Краткая шпаргалка по матрицам и операциям с ними

Что происходит, когда вы добавляете строку в Postgres?
(продолжение в следующем посте)

Что происходит, когда вы добавляете строку в Postgres?
(продолжение предыдущего поста)

Postgres должен гарантировать сохранность данных, обеспечивая при этом высокую производительность записи и возможность восстановления после сбоев. Ключ к решению этой задачи — журнал упреждающей записи (Write‑Ahead Log, WAL).

(1) Postgres получает запрос и определяет, на какую страницу данных его разместить. Эта страница может уже находиться в памяти (в буферном пуле), либо её придётся загрузить с диска, либо даже создать новую.

(2) Новая запись помещается только в эту страницу в памяти. Страница помечается как «грязная» (*dirty*), что означает: её нужно будет в будущем записать на диск — но не немедленно.

(3) Новая запись добавляется в буфер памяти для WAL. Она содержит всю информацию, необходимую для восстановления операции вставки.

(4) WAL записывается на диск (с помощью fsync или аналогичного механизма), чтобы гарантировать сохранение данных в надёжном хранилище. После успешного выполнения этого шага Postgres возвращает клиенту подтверждение об успешном выполнении.

Когда клиент получает подтверждение об успехе, данные гарантированно записаны в последовательный WAL (что обеспечивает высокую производительность записи), но не обязательно — в файл данных таблицы (где шаблоны операций ввода‑вывода менее предсказуемы). Последнее происходит позже — посредством контрольных точек, фоновых заданий или принудительной записи из‑за вытеснения страниц памяти. Если сбой сервера произойдёт до того, как данные будут записаны на диск, журнал будет воспроизведён для восстановления подтверждённых данных.

WAL — это основа всего процесса! Он обеспечивает высокопроизводительный ввод‑вывод и возможность восстановления после сбоев.

#sql #database #postgresql

Диграмма микросервисной архитектуры и связанных с ней паттернов