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 (антипаттерн) → Общая база данных

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

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

Сегодня - главное событие этого года в мире Java - вышла Java 25/ JDK 25. Особенностью этого релиза является то, что у некоторых вендоров он идет как LTS-релиз, а значит у него будут выходить обновления как минимум 5 лет с момента выхода (до сентября 2030 года).
Перечислю некоторые ключевые изменения:

- Компактные исходные файлы и instance-методы main(). То есть теперь можно писать без полного объявления класса и метода main

String greeting = "Hello, World!";

void main() {
    System.out.println(greeting);
}

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

- Module Import Declarations
Декларация "import module M" эквивалентна импорту всех экспортированных пакетов из модуля M и его транзитивных зависимостей в текущий модуль.

- Flexible Constructor Bodies
Flexible Constructor Bodies разрешают писать инструкции кода в конструкторе перед явным вызовом конструктора (super() или this())

- 32-битный x86 порт OpenJDK был окончательно удалён. Это означает, что из кодовой базы удалены части кода, отвечающие за 32 бит x86. Собрать JDK под эту платформу больше нельзя.

- Scoped Values
Класс ScopedValue позволяет обмениваться иммутабельными данными без их передачи через аргументы методов. Он является альтернативой существующему классу ThreadLocal.
Классы ThreadLocal и ScopedValue похожи тем, что решают одну и ту же задачу: передать значение переменной в рамках одного потока (или дерева потоков) из одного места в другое без использования явного параметра.

- Key Derivation Function API
Функции выведения ключа (KDF - Key Derivation Functions) могут использоваться для вывода криптографически сильных секретных ключей (например, AES) на основе материала ключа (например, пароля) и других данных (например, соли).

Основные изменения можно посмотреть здесь:
https://jdk.java.net/25/release-notes

Microsoft прекратит поддержку Windows 10 в октябре
Компания Microsoft объявила, что прекратит поддержку операционной системы Windows 10 с 14 октября 2025 года. После этой даты все версии перестанут получать ежемесячные обновления безопасности, что сделает устройства уязвимыми к угрозам.

По данным «Лаборатории Касперского» на сентябрь 2025 года, более половины пользователей все еще работают на Windows 10.
Эксперты предупреждают, что использование устаревшей операционной системы создает серьезные риски, особенно для бизнеса, так как повышает уязвимость к хакерским атакам и может вызвать несовместимость с новым программным обеспечением.

https://learn.microsoft.com/ru-ru/windows/release-health/windows-message-center#3656

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

Контейнеризация
(описание к предыдущему посту)

→ Что такое контейнеризация

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

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

→ Docker в DevOps

Docker — самая популярная платформа для контейнеризации.

✓ Dockerfile → определяет инструкции для создания образов контейнеров.
✓ Docker Image → шаблон среды приложения.
✓ Docker Container → работающий экземпляр образа Docker.
✓ Docker Registry → репозиторий (например, Docker Hub) для хранения и обмена образами.

→ Жизненный цикл контейнера

Жизненный цикл контейнера включает несколько этапов:

✓ Create → контейнер создаётся на основе образа.
✓ Start/Run → контейнер запускает приложение.
✓ Pause/Stop → временное или полное приостановление работающего контейнера.
✓ Delete/Remove → удаление неиспользуемых контейнеров для освобождения ресурсов.

→ Интеграция с CI/CD

✓ Контейнеры создаются как часть конвейера.
✓ Обеспечивают согласованную среду от разработки до продакшена.
✓ Откаты и масштабирование упрощаются с помощью инструментов оркестрации контейнеров, таких как Kubernetes.

→ Преимущества контейнеризации

✓ Переносимость между средами.
✓ Более быстрые циклы разработки и развёртывания.
✓ Эффективное использование системных ресурсов.
✓ Упрощённое масштабирование и оркестрация.

ИИ пишет код, который невозможно поддерживать

Новое исследование от Codility выявило серьёзный недостаток в том, как мы оцениваем генерацию кода с помощью ИИ. Их бенчмарк COMPASS протестировал три ведущие модели: Claude Opus 4, Gemini 2.5 Pro и OpenAI O4-Mini-High на 50 задачах по конкурентному программированию.

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

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

Claude Opus 4 показал 72% по корректности, но только 35% по эффективности. Это означает, что его решения часто превышали лимит времени или использовали метод полного перебора там, где существовали более элегантные алгоритмы.

Решение с временной сложностью O(n³) может пройти тесты, но упадёт в продакшене.

Качество кода показало другую картину. Все три модели стабильно генерировали чистый, читаемый Python-код с оценкой выше 89% по метрикам поддерживаемости.

ОДнако качество кода практически не коррелирует с корректностью или эффективностью. Модель может писать красивый нерабочий код или уродливый, но работающий.

O4-Mini-High стал явным победителем, набрав более 93% как по корректности, так и по эффективности. Однако даже топовые модели демонстрировали тревожную непоследовательность.

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

Основные выводы:

1. Не доверяйте алгоритмам, сгенерированным ИИ, без анализа эффективности
2. Проверка кода должна занимать больше времени на комплексную оценку, а не только на проверку функциональности
3. Используйте разные модели для разных задач (O4-Mini-High для алгоритмов, Gemini для читаемых утилит)
4. Внедрите уровни валидации, которые отсекают неэффективные решения до продакшена

Бенчмарк выявил фундаментальное несоответствие: мы оптимизируем модели для корректности, потому что это легко измерить. Но код для продакшена требует всех трёх параметров.

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

Само исследование https://www.arxiv.org/abs/2508.13757

Microsoft увеличил срок поддержки версий .NET со стандартной поддержкой (STS) с 18 до 24 месяцев. Это изменение вступает в силу, начиная с версии .NET 9, то есть поддержка .NET 9 завершится 10 ноября 2026 года.
Это сделано, чтобы избежать проблем с новыми фичами в новых STS-версиях, срок поддержки которыз заканчивается раньше, чем в более старых LTS-версиях, где еще нет новых фич.
Напомню, что также есть версии с долгосрочной поддержкой (LTS), как .NET 8 или .NET 10 (которая ожидается в ноябре), которые поддерживаются в течение трёх лет.
https://devblogs.microsoft.com/dotnet/dotnet-sts-releases-supported-for-24-months/

Рекомендации по обеспечению безопасности (TLS/SSL, CSRF, SQL-инъекции, XSS)
(продолжение в следующем посте)

Рекомендации по обеспечению безопасности (TLS/SSL, CSRF, SQL-инъекции, XSS)
(продолжение предыдущего поста)

### Почему безопасность важна

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

### TLS/SSL (безопасность транспортного уровня / защищённый сокетный слой)

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

### CSRF (межсайтовая подделка запросов)

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

✓ Внедрите CSRF-токены в формы.
✓ Используйте SameSite-куки для блокировки сторонних эксплойтов.
✓ Проверяйте заголовки реферера для валидации запросов.

### SQL-инъекции

→ Возникают, когда злоумышленники внедряют вредоносный SQL-код в запросы для доступа к базам данных или их изменения.
→ Лучшие практики:

✓ Всегда используйте параметризованные запросы или подготовленные операторы.
✓ Избегайте конкатенации динамических SQL-строк.
✓ Применяйте принцип минимальных привилегий для пользователей баз данных.

### XSS (межсайтовый скриптинг)

→ Внедрение вредоносного JavaScript-кода на сайт для кражи cookies, перехвата сессий или распространения вредоносного ПО.
→ Лучшие практики:

✓ Очищайте и экранируйте все пользовательские данные.
✓ Используйте политику безопасности контента (CSP).
✓ Кодируйте выходные данные перед их отображением в HTML, JavaScript или URL.

### Аналогии

→ TLS/SSL → Как запечатывание писем в конверты с защитой от вскрытия.
→ CSRF → Как обман человека, чтобы он подписал чек, который не писал.
→ SQL-инъекции → Как вставка скрытых инструкций в форму заказа.
→ XSS → Как размещение вредоносной листовки на общественной доске объявлений.

### Чек-лист безопасности для backend-разработчиков

✓ Используйте HTTPS везде с TLS/SSL
✓ Проверяйте и очищайте все пользовательские данные
✓ Используйте параметризованные запросы для доступа к базе данных
✓ Экранируйте выходные данные для предотвращения XSS-атак
✓ Внедрите защиту от CSRF с помощью токенов и SameSite-куки
✓ Применяйте принцип минимальных привилегий для ролей базы данных и сервера
✓ Регулярно обновляйте программные зависимости и применяйте патчи безопасности
✓ Отслеживайте журналы на предмет подозрительной активности
✓ Используйте ограничение частоты запросов для блокировки брутфорс-атак
✓ Проводите тесты на проникновение и сканирование уязвимостей

### Типы портов VLAN

1. Access Port:
- Каждый порт привязан к одному VLAN.
- Передаёт и принимает немаркированные пакеты (Untagged Packets).
- Коммутатор добавляет тег VLAN на основе конфигурации порта.
- Конечным устройствам не требуется знание о VLAN.
- Один широковещательный домен на VLAN.

2. Trunk Port:
- Используется для соединения с другими коммутаторами.
- Передаёт маркированные пакеты (Tagged Packets), принадлежащие нескольким VLAN.
- Обеспечивает изоляцию VLAN.
- Поддерживает до 4094 VLAN (стандарт 802.1Q).

### Структура пакетов

1. Untagged Packet:
- Стандартный кадр Ethernet II.
- Не содержит информации о VLAN.
- Размер кадра: 64–1518 байт.
- Используется конечными устройствами (компьютеры, телефоны и т.д.).

2. Tagged Packet (802.1Q):
- Содержит 4-байтовый тег VLAN (общий размер кадра: 60–1522 байт).
- Включает:
- TPID (0x8100): идентификатор тега.
- PCP (Priority Code Point): приоритет (0–7).
- VLAN ID (1–4094): идентификатор VLAN.
- Ethernet Original Type: тип Ethernet.

### Пример сетевой диаграммы

На диаграмме показаны два коммутатора (Switch A и Switch B), соединённые через Trunk Port. Trunk Port передаёт маркированный трафик (Tagged Traffic) между несколькими VLAN (VLAN 1, VLAN 2, VLAN 3). Конечные устройства подключены через Access Ports и используют немаркированные пакеты.

Типы портов VLAN
(диаграмма к предыдущему посту)

Закон Конвея и архитектура программного обеспечения

Архитектура программного обеспечения часто отражает структуру вашей организации.

Вы слышали о законе Конвея (𝗖𝗼𝗻𝘄𝗮𝘆'𝘀 𝗟𝗮𝘄)? Это теория, созданная компьютерным учёным Мелвином Конвеем (Melvin Conway) в 1967 году, которая гласит: «Организации, которые разрабатывают системы, склонны продуцировать проекты, которые отражают коммуникационные структуры этих организаций»
(в оригинале: "𝘖𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯𝘴, 𝘸𝘩𝘰 𝘥𝘦𝘴𝘪𝘨𝘯 𝘴𝘺𝘴𝘵𝘦𝘮𝘴, 𝘢𝘳𝘦 𝘤𝘰𝘯𝘴𝘵𝘳𝘢𝘪𝘯𝘦𝘥 𝘵𝘰 𝘱𝘳𝘰𝘥𝘶𝘤𝘦 𝘥𝘦𝘴𝘪𝘨𝘯𝘴 𝘸𝘩𝘪𝘤𝘩 𝘢𝘳𝘦 𝘤𝘰𝘱𝘪𝘦𝘴 𝘰𝘧 𝘵𝘩𝘦 𝘤𝘰𝘮𝘮𝘶𝘯𝘪𝘤𝘢𝘵𝘪𝘰𝘯 𝘴𝘵𝘳𝘶𝘤𝘵𝘶𝘳𝘦𝘴 𝘰𝘧 𝘵𝘩𝘦𝘴𝘦 𝘰𝘳𝘨𝘢𝘯𝘪𝘻𝘢𝘵𝘪𝘰𝘯𝘴.").

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

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

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

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

Чтобы смягчить это влияние, можно использовать манёвр «Обратная Конвея» (𝗜𝗻𝘃𝗲𝗿𝘀𝗲 𝗖𝗼𝗻𝘄𝗮𝘆 𝗺𝗮𝗻𝗲𝘂𝘃𝗲𝗿). Этот метод включает привлечение архитекторов программного обеспечения, инженеров и руководителей к определению организационных структур. Это может привести к созданию более качественного программного обеспечения.

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