METANIT.COM

Сегодня - главное событие этого года в мире 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

Паттерны взаимодействия микросервисов Микросервисы отлично подходят для создания гибких и масштабируемых систем, но они также создают проблему обеспечения слаженной работы независимых сервисов между собой. Паттерны взаимодействия — ключ к решению этой задачи. [1.] Паттерн Saga → Обеспечение согласованности Вы бронируете авиабилет и номер в отеле. Вам нужно, чтобы было подтверждено либо всё, либо ничего. Именно для этого и существуют Saga. * Разбивают большую задачу на более мелкие шаги, каждый из которых обрабатывается отдельным микросервисом. * Если один шаг завершается неудачей, остальные отменяют свои изменения. Два варианта реализации: * Хореография — сервисы обмениваются сообщениями через события («Билет забронирован!», «Отель забронирован!», «Ой, билет отменён!») для поддержания синхронизации. * Оркестрация — центральный «менеджер» указывает каждому сервису, что делать, и выполняет откат в случае ошибок. [2.] API Композиция Персональный помощник для вашего приложения. Вместо того чтобы самостоятельно обращаться к каждому сервису, вы просите помощника собрать всё необходимое. * API Gateway или BFF (Backend for Frontend) взаимодействует с несколькими микросервисами, собирает данные и предоставляет их клиенту в едином пакете. [3.] CQRS → Разделение операций чтения и записи Как два повара на кухне: один готовит (записывает данные), а другой подаёт блюда (читает данные). * Используются отдельные модели для чтения и записи данных. * Это позволяет оптимизировать каждую сторону под конкретную задачу. * Сложная настройка, требуется синхронизация двух моделей. [4.] Event-Driven Collaboration → Взаимодействие на основе событий Групповой чат, где сервисы обмениваются обновлениями. Любой заинтересованный сервис может подписаться и реагировать. * Сервисы публикуют события («Заказ оформлен!»). * Другие сервисы подписываются на эти события и выполняют свои задачи при получении релевантных уведомлений. * Может быть сложно отлаживать, требуется обеспечение правильной последовательности обработки сообщений. [5.] Command-Side Replica → Локальная копия для ускорения Хранение копий часто используемых файлов на рабочем столе для быстрого доступа вместо постоянного обращения к сетевому диску. * Сервис хранит локальную, доступную только для чтения копию данных другого сервиса. * Это ускоряет операции чтения и снижает зависимость от доступности другого сервиса. * Данные могут быть немного устаревшими (задержка репликации), требуется сложность для поддержания синхронизации копий. [6.] Shared Database (антипаттерн) → Общая база данных * Несколько микросервисов используют одну и ту же базу данных. Обычно не рекомендуется к использованию и применяется только как временный шаг при разбиении монолита.

В канале Selectel Newsfeed новые бесплатные курсы! Наши бесплатные курсы для специалистов всех уровней помогут разобраться в темах быстро, структурно и последовательно. Вступайте в сообщество IT-специалистов в Telegram от Selectel и развивайте новые навыки📚 Смотреть #реклама 16+ О рекламодателе

Согласованность «читай-то-что-записал» (read-your-writes) (продолжение предыдущего поста) Любая запись, внесённая в базу данных, будет немедленно доступна для чтения тем же клиентом. Звучит очевидно! Но есть сценарии, где это не всегда происходит, особенно на масштабных системах. На одноузловом сервере базы данных это легко гарантировать при условии использования последовательных транзакций. В среде с главным сервером и репликами нужно быть более осторожным. Многие базы данных настроены так, что все записи и некоторые операции чтения направляются на главный сервер, но большинство операций чтения выполняется репликами. Из-за задержки репликации может возникнуть ситуация, когда клиент записывает запись в БД, а затем сразу пытается прочитать её из реплики, но её там нет! (см. изображение) Это возможно при использовании асинхронной или полусинхронной репликации, поскольку они не требуют, чтобы все реплики получили запись перед ответом клиенту. При синхронной репликации все реплики должны подтвердить получение записи, прежде чем главный сервер ответит. При использовании асинхронной или полусинхронной репликации, лучше направлять операции чтения только на те реплики, для которых не требуется согласованность «читай-то-что-записал» (read-your-writes).

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

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

Стань экспертом в сфере ВЭД Время получать новые знания! Готовим профессионалов в сфере экспорта. Присоединяйся! Подать заявку #реклама 16+ ved.rudn.ru О рекламодателе

Load Balancing и Reverse Proxy (Балансировка нагрузки и обратный прокси-сервер) (продолжение предыдущего поста) → Что такое Load Balancing (балансировка нагрузки)? Представьте загруженный ресторан с несколькими поварами на кухне. Вместо того чтобы перегружать одного повара всеми заказами, менеджер ресторана (балансировщик нагрузки) равномерно распределяет заказы между всеми поварами. Это гарантирует, что ни один повар не будет перегружен, а клиенты получат свои блюда быстрее. → Зачем нужна балансировка нагрузки? ✓ Предотвращает перегрузку любого отдельного сервера ✓ Улучшает производительность приложений ✓ Повышает надёжность и время бесперебойной работы ✓ Обеспечивает масштабируемость при росте трафика → Типы балансировки нагрузки ✓ Круговая система (Round Robin) → Каждый сервер получает запросы по очереди, как при раздаче карт за покерным столом. ✓ Наименьшее количество соединений (Least Connections) → Новые запросы направляются на сервер с наименьшим количеством активных запросов, подобно выбору самой короткой очереди в супермаркете. ✓ IP-хеш (IP Hash) → IP-адрес клиента определяет, к какому серверу он подключается, как если бы клиентов распределяли по постоянным столикам. Что такое обратный прокси-сервер? → Обратный прокси-сервер располагается перед серверами и направляет клиентские запросы к ним. Представьте администратора в офисе, который направляет посетителей к нужному сотруднику, не позволяя им свободно перемещаться. → Преимущества обратного прокси-сервера * Безопасность → Скрывает внутренние серверы от прямого доступа * Терминация SSL → Обрабатывает шифрование и дешифрование, освобождая серверы от этой задачи * Кэширование → Сохраняет часто запрашиваемые ответы для более быстрой доставки * Централизованная аутентификация → Управляет контролем доступа до того, как запросы попадут на серверы Балансировка нагрузки против обратного прокси-сервера → Балансировщик нагрузки → Сосредоточен на равномерном распределении запросов между серверами (справедливое распределение). → Обратный прокси-сервер → Сосредоточен на управлении, защите и оптимизации запросов до их попадания на серверы (умный привратник). Современные инструменты (такие как Nginx, HAProxy, AWS ELB) часто объединяют обе функции.

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

Нетворкинг с ТОПами ритейла в одном канале. Ведущие эксперты из X5, «Магнита», «Ашана», «Лента», и еще 50+ сетей. Эксклюзивные кейсы, инсайды и требования рынка. Стань частью комьюнити. Подпишись! Подписаться #реклама 16+ О рекламодателе

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 (Скользящее окно): ограничивает запросы в подвижном временном интервале для более плавного контроля.

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

Фактически смерть еще одного отечественного проекта Юрлицо российского игрового движка Nau Engine, в который VK планировал инвестировать 1 млрд руб., находится в стадии ликвидации. Участники рынка называют шаг логичным, команда проекта уже перешла в контур университета ИТМО, а ответственная за разработку ассоциация говорит, что технология будет развиваться силами профильного сообщества. Но пока движок не нашел его поддержки, говорят разработчики, и рынок использует зарубежные решения Unity и Unreal Engine. Как заявляется, развитие движка продолжится сообществом при поддержке АПРИОРИ и техническом сопровождении ИТМО. Финансирование проекта, согласно плану, должно было происходить за счет продаж лицензий на его коммерческую версию, в том числе по подписке. Официально VK сообщил о начале работы над игровым движком только в 2023 году, в его разработку планировалось вложить1 млрд руб. и сформировать профильную команду. https://www.kommersant.ru/doc/8039708

Развертывание (Docker, Kubernetes, CI/CD) (продолжение предыдущего поста) Что такое развертывание? → Развертывание — это процесс, который делает ваше приложение доступным для пользователей. → Современное развертывание использует инструменты и конвейеры для обеспечения согласованности, скорости и надежности. ### Docker (Контейнеризация) → Представьте Docker как транспортный контейнер для программного обеспечения. → Он упаковывает код, библиотеки и зависимости вместе, чтобы приложение работало одинаково в любой среде. → Преимущества: переносимость, изоляция и согласованность между средами (разработка, тестирование, продакшен). ### Kubernetes (Оркестрация) → Когда у вас появляется много контейнеров, вам нужен менеджер. → Kubernetes — это как портовая администрация, которая направляет, масштабирует и перезапускает контейнеры. → Управляет балансировкой нагрузки, масштабированием, поэтапными обновлениями и самовосстановлением контейнеризированных приложений. ### CI/CD (Непрерывная интеграция и непрерывное развертывание) → CI — это как проверка каждого продукта перед отправкой с завода: тесты запускаются автоматически при каждом внесении изменений разработчиками. → CD — это система доставки: одобренные изменения автоматически отправляются в продакшен. → Преимущества: более быстрые релизы, меньше ошибок, более слаженная командная работа. ### Аналогия → Docker → Герметичный ящик, содержащий ваши товары. → Kubernetes → Логистическая компания, организующая и маршрутизирующая все ящики. → CI/CD → Конвейер, который непрерывно отправляет ящики без задержек.

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

Реклама для бизнеса любого уровня в Яндекс Директе Создайте эффективную рекламную кампанию с алгоритмами Яндекс Директа 👌 Начните прямо сейчас ⚡ Зарегистрироваться #реклама direct.yandex.ru О рекламодателе

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

Ищу желающих заполнять карточки товаров на ВБ! Работа полностью на удаленке с зп до150 000 рублей в месяц. Без опыта, нужен только телефон, занятость 3-6 часов в день. Всему обучат на бесплатном курсе и после возьму на работу: ✅ 3 дня уроков по 30 минут ✅ Домашки с проверкой и оплатой бонусами ✅ Плачу 10 тыс за каждую выполненную домашку Все кто пройдет курс, получат сертификат от школы с образовательной лицензией. ⚡ Набор заканчивается завтра. 👍 Для регистрации жмите кнопку "Зарегистрироваться" Зарегистрироваться #реклама 16+ course.wildmanager.ru О рекламодателе

Шпаргалка по использованию очередей (описание к предыдущему посту) За каждой масштабируемой системой стоит очередь. За каждым сбоем стоит неправильно использованная очередь. Очереди встречаются повсюду: фоновые задачи, потоки событий, брокеры сообщений. Они являются основой масштабируемых систем, но также являются частой причиной сбоев. Основные определения: 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) → обработка срочных задач в первую очередь