Как работают логирование и мониторинг (стек ELK, Prometheus, Grafana)
(описание в следующем посте)

### Логирование и мониторинг (стек ELK, Prometheus, Grafana)
(продолжение предыдущего поста)

Что такое логирование и мониторинг?

* Логирование фиксирует, что происходило в вашей системе (ошибки, запросы, события).
* Мониторинг отслеживает состояние системы в режиме реального времени (CPU, память, трафик, время безотказной работы).
* Вместе они помогают выявлять проблемы, улучшать производительность и обеспечивать надёжность.

### стек ELK (Elasticsearch, Logstash, Kibana)

* Elasticsearch — эффективное хранение и поиск логов.
* Logstash — сбор, обработка и отправка логов.
* Kibana — визуализация логов на информационных панелях и графиках.
* Пример использования — централизованное управление логами и устранение неполадок.

### Prometheus (Сбор метрик)

* Собирает системные метрики и метрики приложений (использование CPU, память, задержка запросов).
* Хранит данные временных рядов для анализа.
* Отправляет оповещения, когда метрики превышают заданные пороги.

### Grafana (Визуализация и информационные панели)

* Взаимодействует с Prometheus и другими источниками данных.
* Создаёт интерактивные информационные панели для отслеживания производительности системы и тенденций.
* Помогает командам отслеживать время безотказной работы, сбои и использование ресурсов.

### Push- и Pull-мониторинг

Push-мониторинг

* Системы отправляют (push) свои метрики на сервер мониторинга.
* Хорошо подходит для динамичных сред (например, IoT-устройства, мобильные приложения).
* Риск: сервер мониторинга может быть перегружен входящими данными.

Pull-мониторинг

* Сервер мониторинга запрашивает (pull) метрики у систем через определённые интервалы.
* Prometheus следует этой модели — извлекает метрики из конечных точек.
* Преимущества: более простой контроль, предотвращение перегрузки, обеспечение согласованности.
* Ограничение: не идеален для систем, которые не всегда доступны.

### Аналогия

* Логирование — камеры видеонаблюдения, записывающие события в здании.
* Мониторинг — охранники, наблюдающие за экранами в режиме реального времени.
* Push-подход — охранники получают телефонные звонки из каждой комнаты о происходящем.
* Pull-подход — охранники сами обходят каждую комнату для проверки.

Фрилансеры и даже целые компании начали зарабатывать на исправлении ошибок в программном обеспечении, созданном вайб-кодерами. Так, в 404Media обратили внимание на то, что в LinkedIn появились профили «специалистов по очистке вайб-кода».

«Я предлагаю услуги по исправлению вайб-кода уже около двух лет, начиная с конца 2023 года. Сейчас я регулярно работаю примерно с 15-20 клиентами, а также выполняю разовые проекты в течение года», — написал один из таких разработчиков по имени Хамид Сиддики. По его словам, «всё больше разработчиков и небольших команд испытывают трудности с улучшением кода, сгенерированного ИИ, который был функциональным, но не обладал необходимой “отшлифованностью” или “атмосферой”, чтобы соответствовать их видению».
Он рассказал, что распространённые проблемы, которые он исправляет в проектах, включают несогласованный UI/UX-дизайн в интерфейсах, сгенерированных ИИ, плохо оптимизированный код, влияющий на производительность, неровно расположенные элементы брендинга и функции, которые работают, но кажутся неуклюжими или неинтуитивными. Он также поделился, что часто дорабатывает цветовые схемы, анимацию и макеты.

Кроме того, компании по разработке программного обеспечения, например, Ulam Labs. Как говорится на сайте этой компании:
«Создали что-то быстро? Теперь пора сделать это надёжным. Мы знаем, как это бывает. Нужно было действовать быстро, выпустить MVP [минимально жизнеспособный продукт] и проверить идею. Но теперь технический долг сдерживает: отсутствие тестов, шаткая архитектура, CI/CD [непрерывная интеграция и непрерывная поставка/развёртывание] — это просто мечта, а каждое изменение ощущается как обезвреживание бомбы. Вот тут-то и появляемся мы»

Сватантра Сохни, создатель сайта для авторов проектов вайб-кодинга, которым нужна помощь опытных разработчиков, говорит, что почти 300 профессионалов уже разместили свои профили на площадке.
По его мнению, большинство этих вайб-кодеров — либо менеджеры по продукту, либо продавцы, либо владельцы малого бизнеса, и они думают, что могут что-то создать. Однако они могут создать лишь прототипы, а для доведения до ума нужны опытные разработчики
Ещё одна серьёзная проблема, которую обозначил разработчик — это «прожигание кредитов», то есть деньги, которые вайб-кодеры тратят на оплату использования ИИ при добавлении новых функций, нарушающих работу существующих.

https://www.404media.co/the-software-engineers-paid-to-fix-vibe-coded-messes/

Различные архитектурные паттерны:
(описание к предыдущему посту)

1. Client-Server Architecture (Клиент-серверная архитектура)
Эта архитектура основана на взаимодействии между клиентом и сервером. Клиент отправляет запросы, а сервер обрабатывает их и возвращает результаты. Включает компоненты, такие как балансировщик нагрузки, CDN и серверы.

2. Layered Architecture (Многоуровневая архитектура)
Система разделена на уровни:
- Presentation Layer (Уровень представления) — отвечает за взаимодействие с пользователем.
- Business Logic Layer (Уровень бизнес-логики) — обрабатывает логику приложения.
- Data Access Layer (Уровень доступа к данным) — взаимодействует с базами данных.

3. Pipes and Filter (Трубы и фильтры)
Данные проходят через серию фильтров, каждый из которых выполняет определенную операцию. Это позволяет обрабатывать данные поэтапно.

4. Domain Driven Design (Проектирование, управляемое доменом)
Подход, при котором архитектура строится вокруг бизнес-домена. Включает контексты, такие как Catalog Context, Order Context, Fulfillment Context и Billing Context.

5. Monolithic Architecture (Монолитная архитектура)
Все компоненты приложения объединены в единое целое. Это упрощает разработку, но усложняет масштабирование.

6. Microservices Architecture (Микросервисная архитектура)
Приложение разбивается на независимые сервисы, которые взаимодействуют друг с другом. Это повышает гибкость и масштабируемость.

7. Event-Driven Architecture (Архитектура, управляемая событиями)
Компоненты взаимодействуют через события. Производитель создает события, а потребители реагируют на них.

8. Serverless Architecture (Бессерверная архитектура)
Приложения работают на серверах, предоставляемых облачными провайдерами. Разработчики не управляют инфраструктурой.

9. Stream Processing (Обработка потоков)
Потоки данных обрабатываются в реальном времени с использованием таких инструментов, как Lambda и Stream Processing Engine.

Шпаргалка по использованию очередей
(продолжение в следующем посте)

Шпаргалка по использованию очередей
(описание к предыдущему посту)

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

Очереди встречаются повсюду: фоновые задачи, потоки событий, брокеры сообщений. Они являются основой масштабируемых систем, но также являются частой причиной сбоев.

Основные определения:
1. Очередь — структура данных или система для хранения задач/сообщений в порядке FIFO (First-In-First-Out — «первым пришёл — первым ушёл»).
2. Производитель — компонент, отправляющий сообщения в очередь.
3. Потребитель — компонент, считывающий и обрабатывающий сообщения из очереди.
4. Брокер — промежуточное ПО, управляющее очередями (например, RabbitMQ, Kafka, SQS).
5. Подтверждение (ACK) — сигнал об успешной обработке сообщения.
6. Очередь недоставленных сообщений (Dead Letter Queue / DLQ) — очередь для неудачных/необрабатываемых сообщений.
7. Идемпотентность — гарантия того, что повторная обработка сообщения не создаст дублирующихся побочных эффектов.
8. Тайм-аут видимости — время, в течение которого сообщение невидимо для других во время обработки.

Лучшие практики и подводные камни:

* Используйте идемпотентных потребителей → предотвращает двойную обработку.
* Определите политики повторных попыток (экспоненциальное отступление, максимальное количество попыток).
* Отслеживайте длину очереди и отставание в обработке как индикаторы работоспособности.
* Используйте очереди недоставленных сообщений для неудачных сообщений.
* Обеспечьте упорядоченность сообщений только в случае бизнес-критичности (упорядочивание увеличивает затраты/сложность).
* Делайте сообщения небольшими и самодостаточными.
* Всегда включайте идентификаторы корреляции для отслеживания.

Рекомендации по производительности:

* Для пропускной способности → параллельные потребители или разделы
* Для надёжности → сохраняйте, если критично (компромисс: скорость)
* Для масштабируемости → автоматическое масштабирование потребителей

Паттерны:

* Рабочая очередь (Work Queue) → распределение задач между работниками
* Pub/Sub → трансляция для множества подписчиков
* Отложенная очередь (Delayed Queue) → повторная попытка позже или планирование задач
* Очередь приоритетов (Priority Queue) → обработка срочных задач в первую очередь

Карта памяти программы в Windows #windows

Развертывание (Docker, Kubernetes, CI/CD)
(продолжение в следующем посте)

Развертывание (Docker, Kubernetes, CI/CD)
(продолжение предыдущего поста)

Что такое развертывание?

→ Развертывание — это процесс, который делает ваше приложение доступным для пользователей.
→ Современное развертывание использует инструменты и конвейеры для обеспечения согласованности, скорости и надежности.

### Docker (Контейнеризация)

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

### Kubernetes (Оркестрация)

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

### CI/CD (Непрерывная интеграция и непрерывное развертывание)

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

### Аналогия

→ Docker → Герметичный ящик, содержащий ваши товары.
→ Kubernetes → Логистическая компания, организующая и маршрутизирующая все ящики.
→ CI/CD → Конвейер, который непрерывно отправляет ящики без задержек.

Фактически смерть еще одного отечественного проекта

Юрлицо российского игрового движка Nau Engine, в который VK планировал инвестировать 1 млрд руб., находится в стадии ликвидации. Участники рынка называют шаг логичным, команда проекта уже перешла в контур университета ИТМО, а ответственная за разработку ассоциация говорит, что технология будет развиваться силами профильного сообщества. Но пока движок не нашел его поддержки, говорят разработчики, и рынок использует зарубежные решения Unity и Unreal Engine.

Как заявляется, развитие движка продолжится сообществом при поддержке АПРИОРИ и техническом сопровождении ИТМО.

Финансирование проекта, согласно плану, должно было происходить за счет продаж лицензий на его коммерческую версию, в том числе по подписке. Официально VK сообщил о начале работы над игровым движком только в 2023 году, в его разработку планировалось вложить1 млрд руб. и сформировать профильную команду.

https://www.kommersant.ru/doc/8039708

API Rate Limiting & Throttling (Ограничение и регулирование частоты запросов API)
(продолжение в следующем посте)

API Rate Limiting & Throttling (Ограничение и регулирование частоты запросов API)
(продолжение предыдущего поста)

### Что такое API Rate Limiting?

API Rate Limiting — это процесс контроля количества запросов, которые клиент может отправить к API в течение определённого промежутка времени. Это помогает защитить API от злоупотреблений, обеспечивает справедливое использование и предотвращает перегрузку сервера.

→ Пример: разрешение только 100 запросов на пользователя в минуту.

### Почему важно ограничение частоты запросов

→ Предотвращает атаки типа «отказ в обслуживании» (DoS-атаки).
→ Защищает ресурсы сервера.
→ Обеспечивает справедливый доступ для всех пользователей.
→ Улучшает стабильность и производительность API.

### Что такое API Throttling?

API Throttling (Регулирование частоты) — это процесс контроля потока запросов путём их замедления или постановки в очередь, когда частота превышает допустимый предел. В отличие от строгого ограничения частоты, регулирование допускает дополнительные запросы, но обрабатывает их более плавно.

→ Пример: после достижения 100 запросов в минуту дополнительные запросы задерживаются, а не блокируются полностью.

### Почему важно регулирование частоты

→ Предотвращает резкие скачки трафика.
→ Обеспечивает стабильную работу системы.
→ Помогает сбалансировать нагрузку между серверами.

### Rate Limiting vs Throttling

→ Rate Limiting: устанавливает максимальное количество запросов; запросы сверх лимита отклоняются.
→ Throttling: контролирует скорость запросов; избыточные запросы могут быть задержаны или поставлены в очередь.

### Распространённые методы

→ Token Bucket: запросы разрешаются, если доступны токены; токены восполняются с течением времени.
→ Leaky Bucket: запросы обрабатываются с фиксированной скоростью, избыточные запросы отбрасываются или ставятся в очередь.
→ Fixed Window (Фиксированное окно): ограничивает запросы в фиксированный промежуток времени (например, 1 минута).
→ Sliding Window (Скользящее окно): ограничивает запросы в подвижном временном интервале для более плавного контроля.

Load Balancing и Reverse Proxy (Балансировка нагрузки и обратный прокси-сервер)
(продолжение в следующем посте)

Load Balancing и Reverse Proxy (Балансировка нагрузки и обратный прокси-сервер)
(продолжение предыдущего поста)

→ Что такое Load Balancing (балансировка нагрузки)?
Представьте загруженный ресторан с несколькими поварами на кухне. Вместо того чтобы перегружать одного повара всеми заказами, менеджер ресторана (балансировщик нагрузки) равномерно распределяет заказы между всеми поварами. Это гарантирует, что ни один повар не будет перегружен, а клиенты получат свои блюда быстрее.

→ Зачем нужна балансировка нагрузки?

✓ Предотвращает перегрузку любого отдельного сервера
✓ Улучшает производительность приложений
✓ Повышает надёжность и время бесперебойной работы
✓ Обеспечивает масштабируемость при росте трафика

→ Типы балансировки нагрузки

✓ Круговая система (Round Robin) → Каждый сервер получает запросы по очереди, как при раздаче карт за покерным столом.

✓ Наименьшее количество соединений (Least Connections) → Новые запросы направляются на сервер с наименьшим количеством активных запросов, подобно выбору самой короткой очереди в супермаркете.

✓ IP-хеш (IP Hash) → IP-адрес клиента определяет, к какому серверу он подключается, как если бы клиентов распределяли по постоянным столикам.

Что такое обратный прокси-сервер?

→ Обратный прокси-сервер располагается перед серверами и направляет клиентские запросы к ним. Представьте администратора в офисе, который направляет посетителей к нужному сотруднику, не позволяя им свободно перемещаться.

→ Преимущества обратного прокси-сервера

* Безопасность → Скрывает внутренние серверы от прямого доступа
* Терминация SSL → Обрабатывает шифрование и дешифрование, освобождая серверы от этой задачи
* Кэширование → Сохраняет часто запрашиваемые ответы для более быстрой доставки
* Централизованная аутентификация → Управляет контролем доступа до того, как запросы попадут на серверы

Балансировка нагрузки против обратного прокси-сервера

→ Балансировщик нагрузки → Сосредоточен на равномерном распределении запросов между серверами (справедливое распределение).

→ Обратный прокси-сервер → Сосредоточен на управлении, защите и оптимизации запросов до их попадания на серверы (умный привратник).

Современные инструменты (такие как Nginx, HAProxy, AWS ELB) часто объединяют обе функции.

Как центральный процессор отрисовывает каждый пиксель (на примере визуального симулятора RISC-V), когда мы записываем в буфер кадра один пиксель

Согласованность «читай-то-что-записал» (read-your-writes)
(продолжение в следующем посте)

Согласованность «читай-то-что-записал» (read-your-writes)
(продолжение предыдущего поста)

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

Звучит очевидно! Но есть сценарии, где это не всегда происходит, особенно на масштабных системах.

На одноузловом сервере базы данных это легко гарантировать при условии использования последовательных транзакций.

В среде с главным сервером и репликами нужно быть более осторожным. Многие базы данных настроены так, что все записи и некоторые операции чтения направляются на главный сервер, но большинство операций чтения выполняется репликами. Из-за задержки репликации может возникнуть ситуация, когда клиент записывает запись в БД, а затем сразу пытается прочитать её из реплики, но её там нет! (см. изображение)

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

При использовании асинхронной или полусинхронной репликации, лучше направлять операции чтения только на те реплики, для которых не требуется согласованность «читай-то-что-записал» (read-your-writes).

Паттерны взаимодействия микросервисов

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

[1.] Паттерн Saga → Обеспечение согласованности

Вы бронируете авиабилет и номер в отеле.

Вам нужно, чтобы было подтверждено либо всё, либо ничего.

Именно для этого и существуют Saga.

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

Два варианта реализации:
* Хореография — сервисы обмениваются сообщениями через события («Билет забронирован!», «Отель забронирован!», «Ой, билет отменён!») для поддержания синхронизации.
* Оркестрация — центральный «менеджер» указывает каждому сервису, что делать, и выполняет откат в случае ошибок.

[2.] API Композиция

Персональный помощник для вашего приложения.

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

* API Gateway или BFF (Backend for Frontend) взаимодействует с несколькими микросервисами, собирает данные и предоставляет их клиенту в едином пакете.

[3.] CQRS → Разделение операций чтения и записи

Как два повара на кухне: один готовит (записывает данные), а другой подаёт блюда (читает данные).

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

[4.] Event-Driven Collaboration → Взаимодействие на основе событий

Групповой чат, где сервисы обмениваются обновлениями.

Любой заинтересованный сервис может подписаться и реагировать.

* Сервисы публикуют события («Заказ оформлен!»).
* Другие сервисы подписываются на эти события и выполняют свои задачи при получении релевантных уведомлений.
* Может быть сложно отлаживать, требуется обеспечение правильной последовательности обработки сообщений.

[5.] Command-Side Replica → Локальная копия для ускорения

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

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

[6.] Shared Database (антипаттерн) → Общая база данных

* Несколько микросервисов используют одну и ту же базу данных.

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