Библиотека Java разработчика

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии 📌 https://max.ru/progjob Вакансии в IT Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Бонус 📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы

🕸️ Service Mesh: Инфраструктура, невидимая для кода ❌ Проблема: "Толстые" микросервисы Если вы используете Spring Cloud (Netflix OSS), ваша бизнес-логика перемешана с сетевой логикой. Вам нужно добавлять в код Java аннотации для ретраев (повторных запросов), настраивать Circuit Breaker (Предохранитель), писать логику для распределенной трассировки. А теперь представьте, что в компанию пришла команда, которая пишет на Go или Node.js. Им придется искать аналоги всех этих библиотек для своих языков! Разве сеть это проблема программиста? Нет, это проблема инфраструктуры. 🦸‍♂️ Решение: Service Mesh и паттерн Sidecar Service Mesh (Сервисная сетка) - это выделенный инфраструктурный слой для безопасного, быстрого и надежного общения микросервисов друг с другом. Самый популярный инструмент на рынке - Istio. Вся магия строится на паттерне Sidecar (Коляска мотоцикла). Рядом с вашим контейнером Java в том же поде (Pod) Kubernetes незаметно запускается второй маленький контейнер - Proxy-сервер (обычно это Envoy). Теперь ваше Java-приложение вообще ничего не знает о внешнем мире. 1. Оно хочет отправить запрос в PaymentService? Оно просто шлет HTTP-запрос на localhost. 2. Sidecar-прокси перехватывает этот запрос. 3. Sidecar сам находит нужный сервис, сам шифрует трафик, сам делает ретраи, если сеть моргнула, и отправляет запрос другому Sidecar-у на стороне PaymentService. 🎛️ Как устроен Istio: Data Plane и Control Plane • Data Plane (Плоскость данных): Это армия тех самых Sidecar-прокси (Envoy), которые стоят рядом с каждым сервисом и перекидывают байты. • Control Plane (Плоскость управления): Это мозг (Istiod). Он раздает команды всем прокси-серверам: "Так, с сегодняшнего дня все запросы шифруем", "А теперь 5% трафика направь на новую версию сервиса". ✨ Суперспособности Service Mesh Зачем терпеть усложнение архитектуры? Ради этих фич: 1. Управление трафиком (Traffic Routing) Вам больше не нужно деплоить новую версию на всех сразу и молиться, чтобы она не упала. Вы можете сказать Istio: "Пусти 99% пользователей на версию v1, и только 1% пользователей с iPhone - на версию v2 (Канареечный релиз)". Если v2 работает стабильно, плавно увеличиваем процент. 2. Нулевое доверие (Zero-Trust Security & mTLS) Если хакер проникнет во внутреннюю сеть дата-центра, он сможет "слушать" трафик между вашими сервисами (там могут лететь пароли и токены в открытом виде). Istio из коробки включает mTLS (Mutual TLS). Трафик между ВСЕМИ микросервисами автоматически шифруется. При этом разработчикам не нужно возиться с сертификатами в Java-коде. 3. Наблюдаемость (Observability) без кода Помните Jaeger, Zipkin и Prometheus из прошлого сезона? Чтобы они работали, мы добавляли библиотеки в pom.xml. С Service Mesh это не нужно! Так как все запросы проходят через Sidecar-прокси, он сам собирает метрики (сколько времени занял запрос, какие были ошибки) и сам рисует красивые графы зависимостей в Grafana и Jaeger. 4. Устойчивость к сбоям (Resilience) Если PaymentService "лежит", Sidecar может автоматически сделать 3 повторные попытки (Retry) с интервалом в секунду. Если сервис всё равно не отвечает, Sidecar включит Circuit Breaker (разорвет цепь) и будет сразу возвращать ошибку, чтобы не перегружать зависший сервис. ⚔️ Service Mesh vs API Gateway Часто спрашивают: "Зачем мне Istio, если у меня уже есть Spring Cloud Gateway?" • API Gateway: Управляет трафиком Север-Юг (Снаружи вовнутрь). Он стоит на границе интернета и вашей системы, принимает запросы от пользователей, проверяет JWT-токены и пускает внутрь. • Service Mesh: Управляет трафиком Восток-Запад (Внутри системы). Он следит за тем, как микросервисы общаются между собой за закрытыми дверями. 🔥 Итог Service Mesh (Istio) - это инструмент для крупных и сложных систем. Если у вас 5 микросервисов - это оверкилл, используйте Spring Cloud. Если у вас 100 микросервисов на разных языках программирования, строгие требования к безопасности (банки) и частые релизы без Service Mesh вы сойдете с ума. #SystemDesign #ServiceMesh #Istio #Microservices #DevOps 📲 Мы в MAX 👉@BookJava

Вы знаете названия шаблонов проектирования, но сможете ли выбрать архитектуру, которая выдержит реальную нагрузку? CQRS, Event Sourcing, Saga Pattern звучат убедительно. Но каждый из этих подходов решает конкретные задачи — и добавляет сложности. Ошибка в выборе архитектуры часто обходится дороже, чем ошибка в коде. На открытом уроке «Основные шаблоны проектирования в системном дизайне»: - разберём ключевые архитектурные паттерны на практических примерах (высоконагруженные сервисы, распределённые транзакции, масштабируемые системы). - обсудим, в каких сценариях подход оправдан, а где он только усложняет систему. - поговорим о компромиссах (сложность, стоимость внедрения, производительность). Ведущий Роман Грицуляк — разработчик, консультант по проектированию ИТ-систем. Открытый урок проходит в преддверии старта курса «Проектирование систем». Регистрируйтесь сейчас - напомним перед вебинаром: регистрация Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🔎 Elasticsearch: Как найти иголку в стоге сена за 10 мс Представьте каталог на 10 миллионов товаров. Пользователь вводит в поиск: "айфон 15 про макс". 🐌 1. Почему SQL здесь бессилен? В реляционной базе (PostgreSQL/MySQL) вы бы написали: SELECT * FROM products WHERE name LIKE '%айфон 15%' В чем проблема? 1. Full Table Scan: База данных не может использовать обычный B-Tree индекс для поиска по части слова (с LIKE '%...'). Ей придется прочитать все 10 миллионов строк на диске, чтобы найти совпадения. Это убьет процессор. 2. Нулевая толерантность к ошибкам: Если пользователь опечатался и написал "айфно", SQL вернет 0 результатов. Бизнес потерял клиента. 3. Нет релевантности: SQL не понимает, какой товар подходит "лучше". Он просто отдает всё, что нашел, по дате добавления. 🧠 2. Инвертированный индекс (Inverted Index) Чтобы искать по тексту мгновенно, умные люди придумали структуру данных, которая работает как алфавитный указатель в конце толстой книги. Вместо того чтобы искать слово на страницах, мы заранее составляем список всех слов и записываем, на каких страницах они встречаются. Пример: У нас есть три товара (Документа): • Doc 1: "Красный телефон Apple" • Doc 2: "Синий чехол для телефона" • Doc 3: "Красный чехол" Инвертированный индекс будет выглядеть так: • красный -> [Doc 1, Doc 3] • телефон -> [Doc 1, Doc 2] • apple -> [Doc 1] • синий -> [Doc 2] • чехол -> [Doc 2, Doc 3] Теперь, если мы ищем "красный телефон", система просто берет списки для этих двух слов: [1, 3] и [1, 2]. Пересечение этих списков - Doc 1. Мы нашли результат за O(1)! Никакого сканирования миллионов строк. 🚀 3. Встречайте Elasticsearch (ES) Elasticsearch - это не просто база данных, это полноценный поисковый движок (написанный на Java поверх библиотеки Apache Lucene). Он хранит данные не в таблицах, а в виде JSON-документов, и автоматически строит инвертированный индекс для каждого текстового поля. 🪄 Магия Elasticsearch: 1. Анализаторы (Стемминг и Лемматизация): Перед тем как положить текст в индекс, ES его обрабатывает. Он приводит слова к базовой форме, убирает окончания и предлоги. • Слова "айфон", "айфону", "айфоном" попадут в индекс как один токен "айфон". 2. Поиск с опечатками (Fuzzy Search): ES использует Расстояние Левенштейна (сколько букв нужно изменить, чтобы получить правильное слово). • Запрос "йафон" автоматически найдет "айфон", потому что разница всего в одну перестановку. 3. Релевантность (Scoring - BM25): ES каждому результату присваивает "Оценку". Чем реже слово встречается во всей базе и чем чаще в конкретном документе, тем выше этот документ будет в выдаче. 🏗️ 4. Как это выглядит в Архитектуре? Важное правило: Elasticsearch не заменяет вашу основную базу данных. ES - это поисковик. Он может потерять данные при сбоях (он оптимизирован на скорость чтения, а не на надежность хранения ACID). Правильный паттерн (CQRS-лайт): 1. "Правда" живет в PostgreSQL. 2. Когда товар добавляется или меняется в Postgres, вы отправляете событие в брокер сообщений (Kafka) или используете CDC (Change Data Capture - например, Debezium), чтобы прочитать логи БД. 3. Специальный воркер берет эти изменения из Kafka и синхронизирует их с Elasticsearch. 4. Фронтенд: за созданием/покупкой товара ходит в Postgres, а за поиском — в Elasticsearch. 🔥 Итог • SQL LIKE - для админок и маленьких таблиц. • Инвертированный индекс - ключ к мгновенному поиску. • Elasticsearch - стандарт индустрии для полнотекстового умного поиска, логов (помните ELK?) и аналитики. #SystemDesign #Elasticsearch #Search #Architecture #HighLoad 📲 Мы в MAX 👉@BookJava

🌍 CDN: Как обмануть скорость света и расстояния CDN (Content Delivery Network / Сеть доставки контента) - это географически распределенная сеть серверов, задача которых - отдавать контент пользователю из максимально близкой к нему точки. 🏢 1. Origin и Edge: Разделение ролей В архитектуре с CDN появляются два новых понятия: • Origin Server (Главный сервер): Это ваш настоящий сервер, где крутится Spring Boot, лежит база данных и хранятся оригиналы всех файлов (например, в Amazon S3). • Edge Servers (Граничные серверы / Точки присутствия - PoP): Это тысячи серверов CDN-провайдера (например, Cloudflare или Akamai), раскиданные по всему земному шару: в Сиднее, Токио, Нью-Йорке, Лондоне, Москве. ⚙️ 2. Как это работает (Cache Hit & Miss) Представьте, что австралийский пользователь впервые запрашивает логотип вашего сайта logo.png. 1. Cache Miss (Промах кэша): Запрос летит на ближайший к нему Edge-сервер в Сиднее. Сервер проверяет свою память и видит: "У меня нет этого файла". 2. Поход на Origin: Edge-сервер сам идет на ваш главный сервер в Германию, скачивает logo.png, сохраняет копию у себя на диске (кэширует) и отдает пользователю. Это было долго (те самые 300 мс). 3. Cache Hit (Попадание в кэш): Через секунду заходит второй пользователь из Сиднея и просит тот же logo.png. Edge-сервер моментально отдает ему файл из своей памяти за 5 миллисекунд. Запрос до Германии даже не доходит! 📦 3. Что кладем в CDN, а что нет? CDN идеально подходит для Статического контента: • Картинки, видео, аудио. • Скомпилированные файлы JavaScript и CSS. • Шрифты. CDN категорически НЕ подходит для Динамического контента: • Баланс банковского счета. • Корзина товаров. • Приватные данные пользователя. • (Запросы к API /api/v1/users/me должны идти напрямую на ваш сервер, минуя кэш CDN). 🛡️ 4. Защита от DDoS Современные CDN (тот же Cloudflare) - это не просто кэш. Это гигантский щит. Если хакеры решат "положить" ваш сайт и отправят миллион запросов в секунду, этот удар примут на себя серверы CDN. Их пропускная способность измеряется терабитами. Они отфильтруют "мусорный" трафик, и ваш маленький Origin-сервер в Германии даже не заметит атаки. 🔥 Итог • Ускорение: Пользователи получают тяжелый контент мгновенно, потому что скачивают его из своего же города. • Экономия: Ваш главный сервер больше не тратит процессорное время и трафик на отдачу терабайтов картинок. Вы платите за сервера меньше. • Безопасность: CDN скрывает реальный IP-адрес вашего сервера и защищает от DDoS-атак. #SystemDesign #CDN #Cloudflare #Architecture #HighLoad 📲 Мы в MAX 👉@BookJava

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии 📌 https://max.ru/progjob Вакансии в IT Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Бонус 📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы

🗄️ System Design: Как не "положить" Базу Данных? В большинстве веб-приложений (например, Instagram или Twitter) соотношение чтения к записи составляет примерно 10 к 1. То есть люди в 10 раз чаще смотрят чужие посты, чем пишут свои. Эту особенность мы и будем использовать. 👯‍♂️ 1. Репликация (Master-Slave / Leader-Follower) Идея проста: давайте скопируем базу данных на несколько серверов и разделим обязанности. 🔴Master (Лидер): Это единственная база данных, в которую разрешено ПИСАТЬ (INSERT, UPDATE, DELETE). 🔴Slave (Ведомые/Реплики): Это точные копии Мастера. Из них можно ТОЛЬКО ЧИТАТЬ (SELECT). Как это работает: 1. Пользователь публикует фото. Запрос идет на Master-базу. 2. Master сохраняет фото и мгновенно отправляет новые данные всем своим Slave-копиям (реплицирует). 3. 1000 других пользователей открывают ленту. Их запросы на чтение распределяются между тремя Slave-базами. Итог: Нагрузка на чтение размазана, Мастер спокойно занимается только записью. 🪓 2. Шардирование (Sharding / Горизонтальное партиционирование) Репликация спасает, когда много читают. Но что делать, если пользователи слишком много пишут (например, это система сбора логов или мессенджер)? Мастер перестает справляться. Или что делать, если данных стало 10 Терабайт, и они тупо не влезают на один диск? Приходит время рубить данные на части - Шардировать. Мы берем нашу огромную таблицу Users и разбиваем её на несколько независимых баз данных (Шардов). 🔴Шард 1: Хранит пользователей с ID от 1 до 1,000,000. 🔴Шард 2: Хранит пользователей с ID от 1,000,001 до 2,000,000. Каждый Шард - это отдельный сервер со своим процессором и диском. Сложность: Теперь вашему приложению (или специальному роутеру) нужно понимать, в какую именно базу отправлять SQL-запрос. А сделать JOIN между таблицами, лежащими на разных серверах, становится практически невозможно. 📐 3. Теорема CAP (Закон распределенных систем) Как только ваша база данных перестает жить на одном сервере и разъезжается на несколько (реплики или шарды), вступает в силу суровый закон физики - Теорема CAP. Она гласит, что в распределенной системе вы можете выбрать только ДВА из ТРЕХ свойств: 1. C (Consistency / Консистентность): Все клиенты видят одни и те же данные в один и тот же момент времени. (Если я обновил аватарку на Мастере, следующий же запрос к любому Слейву должен вернуть новую аватарку). 2. A (Availability / Доступность): Система всегда отвечает на запрос, даже если часть серверов сгорела. Никаких ошибок 500. 3. P (Partition Tolerance / Устойчивость к разделению): Система продолжает работать, даже если между серверами БД пропала сеть (они перестали видеть друг друга). Суровая реальность: В интернете сеть пропадает всегда. Поэтому свойство P мы обязаны брать по умолчанию. Остается выбор между CP и AP. 🔴Системы CP (Консистентные): Банковские приложения. Если сеть между Мастером и Репликой упала, база откажется отдавать вам баланс, потому что боится отдать устаревшие данные. Лучше выдать ошибку, чем соврать. 🔴Системы AP (Доступные): Соцсети (Instagram, YouTube). Если вы поставили лайк, а сеть внутри дата-центра моргнула, ваш друг может еще пару минут не видеть этот лайк (данные не консистентны). Но сайт при этом не "лежит", лента листается. Это называется Eventual Consistency (Консистентность в конечном счете). 🔥 Итог 🔴Используйте Репликацию, чтобы масштабировать чтение (Read-heavy). 🔴Используйте Шардирование, чтобы масштабировать запись и объем данных (Write-heavy). 🔴Помните про CAP-теорему: для соцсетей выбираем Доступность (AP), для финансов - Консистентность (CP). 📲 Мы в MAX 👉@BookJava

Совет по Spring Boot💡 Когда вам нужно настроить bean, предоставляемый Spring Boot, проверьте наличие интерфейсов *Customizer - велика вероятность, что вы сможете настроить bean, не отказываясь от автоконфигурации. 📲 Мы в MAX 👉@BookJava

От 1 до миллиона пользователей (Масштабирование) Представьте: вы написали крутой стартап. Он крутится на дешевом сервере за $5 в месяц. База данных, бэкенд и фронтенд лежат в одном месте. Вдруг о вас снимает ролик популярный блогер. Трафик вырастает в 10,000 раз. Сервер ложится через 3 секунды от OutOfMemoryError. Бизнес теряет деньги. Что делать? У вас есть два пути масштабирования (Scaling). 📈 1. Вертикальное масштабирование (Scale Up) Это самый простой и интуитивный подход. Сервер не справляется? Давайте купим сервер мощнее! Было 2 ГБ оперативки - поставим 128 ГБ. Был 1 ядерный процессор - купим 64-ядерный. 🔴Плюсы: Не нужно менять ни строчки кода. Всё просто работает быстрее. 🔴Минусы: 1. Физический предел. Вы не можете купить сервер с бесконечной памятью. Самый мощный сервер рано или поздно закончится. 2. SPOF (Single Point of Failure). Единая точка отказа. Каким бы мощным ни был сервер, если уборщица выдернет шнур питания в дата-центре - ваш бизнес остановится. 🌐 2. Горизонтальное масштабирование (Scale Out) Это путь настоящих джедаев и BigTech-компаний. Вместо покупки одного суперкомпьютера за миллион долларов, мы покупаем 1000 дешевых обычных серверов и заставляем их работать вместе. 🔴Плюсы: Масштабирование практически бесконечно. Упал один сервер? Ничего страшного, трафик подхватят остальные 999. 🔴Минусы: Архитектура становится в разы сложнее. Появляется куча новых проблем: как делить трафик, как синхронизировать данные, как хранить сессии. ⚖️ 3. Балансировщик нагрузки (Load Balancer) Допустим, мы выбрали горизонтальное масштабирование и запустили 5 одинаковых серверов с нашим Spring Boot приложением. Но пользователи (клиенты) знают только один домен: mysite.com. Как сделать так, чтобы запросы распределялись между этими пятью серверами равномерно? Перед нашими серверами встает Load Balancer (Балансировщик) - например, Nginx, HAProxy или облачный AWS ALB. Пользователь стучится в Балансировщик, а тот перенаправляет запрос на наименее загруженный сервер. 🔴Round Robin: Самый простой алгоритм. Запросы раздаются по кругу: первому серверу, второму, третьему, первому, второму... 🔴Least Connections: Запрос уходит на тот сервер, у которого сейчас меньше всего активных соединений. 🧠 4. Главное правило: Stateless (Без состояния) Горизонтальное масштабирование ломает старый подход к хранению сессий. Если пользователь залогинился и попал на Сервер №1, этот сервер сохранил его данные в оперативной памяти. При следующем клике балансировщик может кинуть пользователя на Сервер №2. А Сервер №2 скажет: "Я тебя не знаю, авторизуйся заново". Решение: Серверы приложения должны быть "глупыми" и ничего не помнить (Stateless). Состояние должно храниться в общем внешнем хранилище (например, в Redis, как мы обсуждали в прошлых сезонах), либо передаваться прямо в запросе с помощью токенов (JWT). 🔥 Итог 1. Vertical Scaling (вверх) - купить "железо" помощнее. Дорого, есть предел. 2. Horizontal Scaling (вширь) - поставить больше дешевых серверов. Требует изменения архитектуры. 3. Load Balancer - дирижер, который распределяет трафик между клонами. 4. Stateless - обязательное условие. Приложение не должно хранить локальное состояние. #SystemDesign #Architecture #Scaling #LoadBalancing #Backend 📲 Мы в MAX 👉@BookJava

Когда система на Spring Boot или Jakarta EE падает под нагрузкой, виноват не Java и не фреймворк. Почти всегда проблема — в архитектуре. 🔔 Курс «Highload Architect» учит строить высоконагруженные системы на Java: от микросервисов до монолитов. Вы разберёте весь путь запроса — от клиента до базы данных и обратно — и поймёте, какие архитектурные решения работают под сотнями тысяч и миллионами запросов в секунду. Программа ориентирована на веб‑разработчиков, тимлидов и архитекторов ПО с опытом работы на Java. Вы научитесь: - оптимизировать серверы - эффективно использовать существующие инструменты - проектировать отказоустойчивые системы - аргументированно защищать архитектурные решения перед командой и бизнесом. На курсе рассмотрим типовые и нетривиальные кейсы, с которыми сталкиваются крупные сервисы. 🎁 Закрываем набор до 5.03.2026 в группу февраля — получите скидку 🔤на обучение! Подробности у менеджера. Пройти короткое вступительное тестирование: https://vk.cc/cV1nMV ❗️ Практическое обучение проводится в прямом эфире — вебинары не являются предзаписанными. Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576

☕ Функциональные интерфейсы: Магия за кулисами Лямбд Если вы используете лямбды (а вы наверняка их используете), значит, вы работаете с функциональными интерфейсами. Давайте разберем, что это такое, зачем нужна аннотация и какие интерфейсы вы обязаны знать наизусть. 🎯 Что это такое? Функциональный интерфейс - это интерфейс, который содержит ровно один абстрактный метод. Именно это ограничение позволяет компилятору превращать лямбда-выражение в экземпляр этого интерфейса. 💙 Примечание: В интерфейсе может быть сколько угодно default или static методов. Главное - только один абстрактный. 📝 Аннотация @FunctionalInterface Ставить её над интерфейсом не обязательно, но хорошим тоном считается ставить. Зачем? Она работает как защита от дурака: если вы или ваш коллега случайно добавите второй абстрактный метод в интерфейс, компилятор сразу выдаст ошибку, не дожидаясь падения кода в местах использования лямбд. 🧰 Шпаргалка: "Великолепная четверка" В пакете java.util.function уже есть готовые интерфейсы на 99% случаев жизни. Не пишите свои велосипеды, пока не выучите эти: 1. Predicate <T> 💙Что делает: Проверяет условие. 💙 Метод: boolean test(T t) 💙 Где нужен: Фильтрация стримов (`filter`), проверки. 2. Consumer <T> 💙 Что делает: "Потребляет" объект, ничего не возвращая. 💙 Метод: void accept(T t) 💙 Где нужен: Вывод на экран, запись в БД, forEach. 3. Supplier <T> 💙 Что делает: "Поставляет" объект (из ниоткуда), ничего не принимая. 💙 Метод: T get() 💙 Где нужен: Ленивая инициализация, генерация значений, orElseGet. 4. Function <T, R> 💙 Что делает: Превращает объект типа T в объект типа R. 💙 Метод: R apply(T t) 💙 Где нужен: Преобразование данных, map в стримах. 💻 Пример в коде

@FunctionalInterface
interface Converter {
    int stringToInt(String s);
}

public class Main {
    public static void main(String[] args) {
        // 1. Создаем реализацию через лямбду
        Converter converter = str -> Integer.parseInt(str);
        
        // 2. Использование стандартного Consumer
        java.util.function.Consumer<Integer> print = x -> System.out.println("Result: " + x);

        int result = converter.stringToInt("123");
        print.accept(result); // Вывод: Result: 123
    }
}

🔥 Итог Функциональные интерфейсы - это контракт для лямбда-выражений. Используйте стандартные из java.util.function, чтобы ваш код был понятен другим разработчикам без лишних документаций. #Java #Core #Lambda #FunctionalProgramming 📲 Мы в MAX 👉@BookJava

🔴 КАК ИДЕАЛЬНО ПРОЙТИ СОБЕС? ПОКАЖЕМ ЗАВТРА! Каждый, проходя интервью, думал: «Ну что они хотят услышать? Я же правильно ответил! Почему меня не взяли?» 4 марта(уже завтра!) в 19:00 по мск приходи онлайн на открытое интервью, где будут собеседовать МЕНТОРА ШОРТКАТ Как это будет: 📂 Виктор Анохин, старший разработчик из WildBerries, будет задавать реальные вопросы и задачи старшему разработчику Сергею Чамкину 📂 Сергей будет отвечать на каждый вопрос так, как это ожидает сам от вас на собеседованиях 📂 В конце можно будет задать любой вопрос Сергею и Виктору Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для Java-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_sh_bot Реклама. О рекламодателе.

Совет Spring Framework💡 Вы можете инжектировать (autowire) бины, которые могут отсутствовать, обернув их в java.util.Optional. Таким образом вы сообщаете, что этот бин является необязательным, избегаете исключения, если он не существует, и можете аккуратно обработать его отсутствие с помощью Optional API. 📲 Мы в MAX 👉@BookJava

👩‍💻 Открытый урок «Реализация простого HTTP сервера на Java» 🗓 10 марта в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «Java-разработчик» от Otus. Одно из основных направлений в Java разработке – разработка веб-приложений. Любому веб-разработчику важно понимать, что из себя представляет протокол HTTP и как внутри работает HTTP-сервер. О чем поговорим: ✔ Что из себя представляет протокол HTTP и как внутри работает HTTP-сервер ✔ Как с помощью штатных средств языка Java (без использования сторонних библиотек) разработать простой HTTP сервер ✔ Вопросы возможности экономии ресурсов системы на обработку каждого запроса Кому будет интересно: Вебинар будет полезен тем, у кого есть уверенные знания в базе языка Java и ООП; желательно понимание базовых принципов работы с потоками ввода/вывода (java.io) и многопоточностью. 🔗 Ссылка на регистрацию: https://vk.cc/cUZH9t Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

🕸️ Распределенная Трассировка: Ищем "бутылочное горлышко" (Zipkin & Jaeger) Если логи это текст, а метрики это графики, то трассировка это диаграмма Ганта (каскад) для каждого отдельного HTTP-запроса. 🧩 Главные понятия: Trace и Span Вся магия строится на двух терминах: 1. Trace (След/Трасса): Это весь путь запроса от клика пользователя в браузере до самого глубокого ответа от базы данных. У него есть единый Trace ID. 2. Span (Пролет/Отрезок): Это один конкретный шаг внутри Трассы. Например, "поход в базу данных" - это один Span. "HTTP-запрос в сервис оплаты" - это другой Span. У каждого спана есть свой Span ID и информация о том, сколько миллисекунд он выполнялся. 🕵️‍♂️ Как сервисы передают ID друг другу? Когда Gateway принимает запрос, он генерирует Trace ID (например, abc-123) и кладет его в HTTP-заголовки (обычно используется стандарт W3C traceparent или b3). Когда Gateway вызывает OrderService, он передает эти заголовки дальше. OrderService читает их и понимает: "Ага, я часть большой трассы abc-123". Вам не нужно писать этот код руками! В Spring Boot 3 за это отвечает библиотека Micrometer Tracing. Она автоматически перехватывает все вызовы через RestTemplate, WebClient, Feign и запросы к БД, вклеивая туда нужные ID. 🛠 Настройка (Spring Boot 3 + Zipkin) Вам нужно добавить всего пару зависимостей в pom.xml:

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-tracing-bridge-brave</artifactId>
</dependency>
<dependency>
    <groupId>io.zipkin.reporter2</groupId>
    <artifactId>zipkin-reporter-brave</artifactId>
</dependency>

В application.yaml указываем адрес сервера Zipkin:

management:
  tracing:
    sampling:
      probability: 1.0 # Отправлять 100% запросов (на проде обычно ставят 0.1, чтобы не грузить сеть)
  zipkin:
    tracing:
      endpoint: "http://localhost:9411/api/v2/spans"

🔭 Zipkin и Jaeger: UI для детективов Ваши микросервисы в фоновом режиме отправляют данные о спанах (время старта и конца) в специальный сервер. Самые популярные решения это Zipkin (написан на Java, проще) или Jaeger (от Uber, написан на Go, мощнее). Вы заходите в веб-интерфейс Jaeger, вбиваете Trace ID (который вы скопировали из логов в Kibana) и видите красивую цветную лесенку: 🟦 Gateway (Всего: 5.0s) 🟩 OrderService.create() (4.9s) 🟨 DB: INSERT order (0.05s) 🟧 PaymentService.pay() (4.8s) 👈 АГА! ВОТ КТО ТОРМОЗИТ! 🟥 External Bank API (4.75s) За 5 секунд вы поняли, что проблема не в вашем коде и не в вашей базе данных, а в том, что API стороннего банка отвечает почти 5 секунд. Вы сэкономили часы дебага! 🔥 Итог: "Святая Троица" Observability Теперь у вас есть полный набор инструментов Senior-разработчика: 1. Метрики (Prometheus/Grafana): Говорят ЕСТЬ ЛИ проблема. (У нас всплеск 500-х ошибок!). 2. Трассировка (Jaeger/Zipkin): Говорит ГДЕ проблема. (Ошибки летят из Payment Service при походе в банк). 3. Логи (ELK): Говорят В ЧЕМ проблема. (Смотрим логи Payment Service по Trace ID и видим: ConnectionTimeoutException). #DevOps #Jaeger #Zipkin #Tracing #Microservices #SpringBoot 📲 Мы в MAX 👉@BookJava

🚀 Подборка полезных IT каналов в Max Системное администрирование, DevOps 📌 https://max.ru/i_odmin Все для системного администратора https://max.ru/bash_srv Bash Советы https://max.ru/sysadminof Книги для админов, полезные материалы https://max.ru/i_odmin_book Библиотека Системного Администратора https://max.ru/i_devops DevOps: Пишем о Docker, Kubernetes и др. 1C разработка 📌 https://max.ru/odin1c_rus Cтатьи, курсы, советы, шаблоны кода 1С Программирование C++📌 https://max.ru/cpp_lib Библиотека C/C++ разработчика Программирование Python 📌 https://max.ru/python_of Python академия. https://max.ru/BookPython Библиотека Python разработчика Java разработка 📌 https://max.ru/bookjava Библиотека Java разработчика GitHub Сообщество 📌 https://max.ru/githublib Интересное из GitHub Базы данных (Data Base) 📌 https://max.ru/database_info Все про базы данных Фронтенд разработка 📌 https://max.ru/frontend_1 Подборки для frontend разработчиков Библиотеки 📌 https://max.ru/programmist_of Книги по программированию https://max.ru/proglb Библиотека программиста https://max.ru/bfbook Книги для программистов Программирование 📌 https://max.ru/bookflow Лекции, видеоуроки, доклады с IT конференций https://max.ru/itmozg Программисты, дизайнеры, новости из мира IT https://max.ru/php_lib Библиотека PHP программиста 👨🏼‍💻👩‍💻 Шутки программистов 📌 https://max.ru/itumor Шутки программистов Защита, взлом, безопасность 📌 https://max.ru/thehaking Канал о кибербезопасности https://max.ru/xakkep_1 Хакер Free Книги, статьи для дизайнеров 📌 https://max.ru/odesigners Статьи, книги для дизайнеров Математика 📌 https://max.ru/Pomatematike Канал по математике https://max.ru/phismat_1 Обучающие видео, книги по Физике и Математике Вакансии 📌 https://max.ru/progjob Вакансии в IT Мир технологий 📌 https://max.ru/mir_teh Канал для любознательных Бонус 📌 https://max.ru/piterspb_78 Свежие новости Санкт-Петербурга https://max.ru/mockva_life Свежие новости Москвы

🪵 ELK Stack: Гугл для ваших логов ELK - это аббревиатура трех инструментов, которые стали стандартом индустрии: 1. Elasticsearch (База данных). 2. Logstash (Труба). 3. Kibana (Интерфейс). В современном мире к ним часто добавляется Filebeat (или Fluentd), и стек превращается в EFK. 🏗 Как это работает? (Архитектура) Представьте конвейер: 1. Java App: Просто пишет логи в консоль (STDOUT) в формате JSON. 2. Filebeat: Маленький агент, который стоит на каждом сервере (или в каждом Поде K8s). Он "слушает" консоль приложения, собирает строки и отправляет их дальше. 3. Logstash: (Опционально) Фильтрует и обрабатывает логи (например, скрывает пароли, парсит даты). 4. Elasticsearch: Хранит терабайты логов и позволяет искать по ним мгновенно. 5. Kibana: Сайт, на который вы заходите, чтобы увидеть графики и поиск. 📝 1. JSON Logging: Забудьте про текст Обычные логи Java выглядят так: 2023-10-25 INFO [main] UserService: User created Это плохо. Компьютеру сложно понять, где тут дата, а где сообщение. В микросервисах мы пишем логи в JSON:

{
  "timestamp": "2023-10-25T10:00:00",
  "level": "INFO",
  "logger": "UserService",
  "message": "User created",
  "user_id": "123",
  "trace_id": "abc-987"
}

Как сделать в Spring Boot? Подключаем библиотеку logstash-logback-encoder и настраиваем logback-spring.xml. Теперь ваши логи это структурированные данные, по которым можно фильтровать! 🔍 2. Correlation ID (Trace ID) - Самое важное! Представьте ситуацию: User - Service A - Service B - Service C (Ошибка!). Вы видите ошибку в логах Service C. Но кто её вызвал? Какой пользователь? С какого запроса всё началось? Без связующей нити вы потратите часы на расследование. Решение: Micrometer Tracing (бывший Spring Cloud Sleuth). Он автоматически добавляет Trace ID и Span ID в каждый лог. • Trace ID: Одинаковый для всей цепочки запросов (от входа пользователя до базы данных). • Теперь в Kibana вы просто вбиваете trace_id="abc-987" и видите все логи всех сервисов, которые участвовали в этом конкретном запросе. 📊 3. Kibana: Визуализация Kibana — это не просто поиск. Это аналитика. Вы можете построить дашборд: • Круговая диаграмма: Распределение ошибок по типам (NPE, DatabaseTimeout). • График: Количество логинов в минуту. • Таблица: Топ-10 самых медленных SQL-запросов (если вы логируете время выполнения). 🛠 Pro-Tip: MDC (Mapped Diagnostic Context) Хотите, чтобы в каждом логе автоматически писался ID текущего пользователя или IP-адрес, но не хотите передавать их в каждый метод? Используйте MDC.

// В фильтре на входе запроса
MDC.put("userId", request.getHeader("X-User-ID"));

// Где-то глубоко в сервисе
log.info("Заказ создан"); 
// В JSON-логе автоматически появится поле "userId": "123"

// В конце
MDC.clear();

🔥 Итог 1. Приложение пишет логи в JSON в консоль. 2. Filebeat забирает их и кидает в Elasticsearch. 3. Разработчик открывает Kibana и ищет проблему за 5 секунд по Trace ID. 4. Никаких SSH и grep. #DevOps #ELK #Logging #Kibana #Elasticsearch 📲 Мы в MAX 👉@BookJava

👩‍💻 Открытый урок «JDBC — ваш швейцарский нож для работы с данными» 🗓 26 февраля в 20:00 МСК 🆓 Бесплатно. Урок в рамках старта курса «Java Developer. Professional» от Otus. Мастерство работы с базами данных: эффективные инструменты и лучшие практики для разработчиков. О чём поговорим:  ✔ Основы JDBC: что это такое, зачем нужно и как работает ✔ Практические примеры выполнения сложных запросов ✔ Работа с транзакциями и обработка ошибок в JDBC ✔ Оптимизация производительности при работе с данными через JDBC Кому будет интересно: Вебинар будет полезен разработчикам, инженерам по базам данных и архитекторам ПО, стремящимся улучшить навыки работы с базами данных и оптимизировать взаимодействие с данными. 🔗 Ссылка на регистрацию: https://vk.cc/cUM6xz Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576

📊 Мониторинг: Пульс вашего приложения В мире мониторинга Java есть три главных игрока: 1. Spring Boot Actuator (Генерирует метрики). 2. Prometheus (Собирает и хранит их). 3. Grafana (Рисует красивые графики). Давайте разберем, как они работают вместе. 1️⃣ Spring Boot Actuator & Micrometer Сначала нужно научить приложение рассказывать о себе. В Spring Boot это делается добавлением двух зависимостей: Actuator и Micrometer. Micrometer это как SLF4J, только для метрик. Это фасад. Вы пишете код один раз, а Micrometer умеет отправлять эти данные хоть в Prometheus, хоть в Datadog, хоть в New Relic. В pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>

В application.yaml:

management:
  endpoints:
    web:
      exposure:
        include: prometheus, health, info

Теперь, если вы перейдете по адресу /actuator/prometheus, вы увидите не JSON, а скучный текст:

# HELP jvm_memory_used_bytes The amount of used memory
# TYPE jvm_memory_used_bytes gauge
jvm_memory_used_bytes{area="heap",id="G1 Eden Space",} 2.5165824E7
http_server_requests_seconds_count{uri="/users",status="200",} 452.0

Это и есть пища для Прометея. 2️⃣ Prometheus: Пылесос данных Prometheus это Time Series Database (База данных временных рядов). Она хранит цифры с привязкой ко времени. Его киллер-фича: Pull Model (Модель вытягивания). В отличие от логов, которые приложение само отправляет (Push), Prometheus сам приходит к вашему приложению раз в 15 секунд и скачивает (Scrape) данные со страницы /actuator/prometheus. Почему Pull лучше Push? Если ваше приложение под дикой нагрузкой и умирает, оно не сможет отправить метрики. Но Prometheus придет, увидит, что ответа нет, и зафиксирует: "Сервис упал". 3️⃣ Grafana: Капитанский мостик Prometheus хранит данные, но смотреть на них в текстовом виде больно. Grafana подключается к Prometheus и превращает скучные цифры в космолет. Вы можете создать дашборды для всего: 🔴JVM: Сколько памяти съедено? Как часто работает Garbage Collector? 🔴Tomcat: Сколько потоков занято? 🔴Бизнес-метрики: Сколько заказов оформлено за час? Какая выручка? Alerting (Оповещения): Самое важное - Графана умеет "кричать". Вы настраиваете правило: "Если количество ошибок 500 превышает 1% в течение 5 минут - отправь сообщение в Telegram/Slack команде дежурных". 🛠 Кастомные метрики Spring дает кучу метрик из коробки (CPU, Memory, HTTP requests). Но бизнесу нужны свои цифры. Создать их легко через MeterRegistry.

@Service
public class OrderService {

    private final Counter orderCounter;

    public OrderService(MeterRegistry registry) {
        // Создаем счетчик "orders.created"
        this.orderCounter = registry.counter("orders.created");
    }

    public void createOrder(Order order) {
        repo.save(order);
        orderCounter.increment(); // +1 к метрике
    }
}

Теперь в Grafana вы увидите график "Заказов в секунду". 🔥 Итог 1. Actuator открывает "дверь" (/actuator/prometheus). 2. Prometheus заходит в эту дверь каждые 15 секунд и забирает цифры. 3. Grafana рисует графики на основе этих цифр и будит вас ночью, если всё сломалось. #DevOps #Monitoring #Prometheus #Grafana #SpringBoot 📲 Мы в MAX 👉@BookJava

☸️ Kubernetes: Оркестратор вашего зоопарка Представьте, что у вас 50 микросервисов, каждый запущен в 3 экземплярах (для надежности). Итого 150 контейнеров. Вдруг сервер №2 сгорает. 50 контейнеров умирают. Без K8s: Админ просыпается в 3 ночи и руками запускает их на сервере №3. С K8s: Вы спите. K8s замечает, что "кого-то не хватает", и сам перезапускает умершие контейнеры на живых серверах за секунды. Это называется Self-healing (Самовосстановление). Чтобы понять K8s, нужно выучить всего три главных слова: Pod, Deployment, Service. 📦 1. Pod (Стручок) - Атом системы В Docker мы запускаем Контейнеры. В Kubernetes мы запускаем Поды. • Pod - это минимальная единица. Это обертка вокруг одного (или нескольких) контейнеров. • У Пода есть свой IP-адрес. • Обычно: 1 Pod = 1 Контейнер с вашим app.jar. • Редко: 1 Pod = Java App + Sidecar (например, агент логирования). Они живут вместе, как сиамские близнецы, и делят сеть. 👮‍♂️ 2. Deployment (Развертывание) - Начальник Вы никогда не создаете Поды вручную. Потому что Поды смертны. Если Под умер - он умер. Вместо этого вы создаете Deployment. Это инструкция для K8s:

"Я хочу, чтобы у меня ВСЕГДА было 3 копии моего приложения OrderService".

Deployment создает ReplicaSet, который следит за численностью. • Если один Под упал K8s создает новый. • Если нагрузка выросла Вы меняете цифру 3 на 10, и K8s мгновенно создает еще 7 копий. 🚦 3. Service (Сервис) - Единая точка входа Поды рождаются и умирают. У них меняются IP-адреса. Как фронтенду узнать, на какой IP слать запрос, если они меняются каждую минуту? Тут выходит Service. Это стабильный сетевой адрес (и DNS-имя), который не меняется никогда. • Service работает как Load Balancer (Балансировщик). • Он принимает запрос на http://order-service и пересылает его на один из живых Подов. Ему все равно, 3 их или 30. 📝 Как это выглядит в коде? (YAML) В мире K8s мы не пишем команды, мы пишем Манифесты (YAML-файлы), описывающие Желаемое состояние.

# 1. Описываем Deployment (Что запускать?)
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-java-app
spec:
  replicas: 3 # Хочу 3 экземпляра!
  selector:
    matchLabels:
      app: backend
  template:
    metadata:
      labels:
        app: backend
    spec:
      containers:
      - name: java-app
        image: my-docker-hub/app:v1 # Берем этот образ
        ports:
        - containerPort: 8080

---
# 2. Описываем Service (Как достучаться?)
apiVersion: v1
kind: Service
metadata:
  name: my-backend-service
spec:
  selector:
    app: backend # Ищи Поды с меткой 'backend'
  ports:
    - protocol: TCP
      port: 80 # Внешний порт
      targetPort: 8080 # Порт контейнера

Вы скармливаете этот файл командой kubectl apply -f app.yaml, и магия случается. 🔥 Итог 1. Pod: Обертка над контейнером. 2. Deployment: Следит, чтобы нужное количество Подов всегда работало. 3. Service: Стабильный адрес, распределяющий запросы по Подам. #Kubernetes #K8s #DevOps #Docker #Java 📲 Мы в MAX 👉@BookJava