Оптимизация и масштабирование
1. Хранение и ротация ключей
Для HMAC-SHA ключи должны безопасно храниться (например, в Vault или AWS KMS).
Для RSA/ECDSA используйте ротацию ключей с поддержкой JWK (JSON Web Key) для автоматического обновления публичных ключей.
2. Масштабирование в микросервисах
Централизуйте выдачу токенов через отдельный сервис (например, Auth Service).
Используйте JWK для распространения публичных ключей между сервисами.
3. Кэширование токенов
Кэшируйте проверенные токены в Redis или другом in-memory хранилище, чтобы снизить нагрузку на парсинг и валидацию.
Используйте TTL кэша, соответствующий exp токена.
4. Логирование и мониторинг
Логируйте попытки использования невалидных или истекших токенов для анализа атак.
Мониторьте время парсинга и валидации токенов, чтобы выявить узкие места.
Пример интеграции с Spring Security
JWT часто используется в связке с Spring Security для защиты REST API.
Пример конфигурации:
#Java #middle #on_request #Jwt
1. Хранение и ротация ключей
Для HMAC-SHA ключи должны безопасно храниться (например, в Vault или AWS KMS).
Для RSA/ECDSA используйте ротацию ключей с поддержкой JWK (JSON Web Key) для автоматического обновления публичных ключей.
2. Масштабирование в микросервисах
Централизуйте выдачу токенов через отдельный сервис (например, Auth Service).
Используйте JWK для распространения публичных ключей между сервисами.
3. Кэширование токенов
Кэшируйте проверенные токены в Redis или другом in-memory хранилище, чтобы снизить нагрузку на парсинг и валидацию.
Используйте TTL кэша, соответствующий exp токена.
4. Логирование и мониторинг
Логируйте попытки использования невалидных или истекших токенов для анализа атак.
Мониторьте время парсинга и валидации токенов, чтобы выявить узкие места.
Пример интеграции с Spring Security
JWT часто используется в связке с Spring Security для защиты REST API.
Пример конфигурации:
import io.jsonwebtoken.Jwts;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter;
@Configuration
public class SecurityConfig {
@Bean
public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
http
.authorizeRequests()
.antMatchers("/api/public").permitAll()
.anyRequest().authenticated()
.and()
.addFilterBefore(new JwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class);
return http.build();
}
}
public class JwtAuthenticationFilter extends OncePerRequestFilter {
@Override
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain)
throws ServletException, IOException {
String header = request.getHeader("Authorization");
if (header != null && header.startsWith("Bearer ")) {
String token = header.substring(7);
try {
Claims claims = Jwts.parserBuilder()
.setSigningKey(Keys.hmacShaKeyFor("secret".getBytes()))
.build()
.parseClaimsJws(token)
.getBody();
String username = claims.getSubject();
if (username != null) {
UsernamePasswordAuthenticationToken auth = new UsernamePasswordAuthenticationToken(
username, null, Collections.emptyList());
SecurityContextHolder.getContext().setAuthentication(auth);
}
} catch (Exception e) {
SecurityContextHolder.clearContext();
}
}
chain.doFilter(request, response);
}
}
#Java #middle #on_request #Jwt
👍4
Введение в Nginx
Nginx (произносится как "engine x") — это высокопроизводительное программное обеспечение с открытым исходным кодом, выполняющее функции веб-сервера, обратного прокси-сервера, балансировщика нагрузки, TCP/UDP-прокси и почтового прокси-сервера. Созданное Игорем Сысоевым в 2004 году, оно распространяется под лицензией BSD из 2 пунктов. Nginx завоевал популярность благодаря своей скорости, стабильности и низкому потреблению ресурсов, что делает его выбором для многих высоконагруженных сайтов, таких как Netflix, Dropbox, Яндекс и ВКонтакте.
Согласно данным W3Techs (по состоянию на апрель 2025 года), Nginx занимает первое место среди веб-серверов, обслуживая 33,8% всех веб-сайтов, опережая Apache (26,4%) и Cloudflare Server (23,4%). Это подчеркивает его широкое признание и надежность.
Как работает Nginx?
Nginx использует асинхронную событийно-ориентированную архитектуру, которая позволяет обрабатывать тысячи одновременных соединений с минимальным использованием ресурсов.
Основные аспекты его работы включают:
Один основной процесс и несколько рабочих процессов: Основной процесс управляет конфигурацией и координирует работу, а рабочие процессы обрабатывают запросы пользователей. Это снижает накладные расходы по сравнению с многопоточной моделью, используемой, например, в Apache.
Механизмы событий: Nginx поддерживает такие технологии, как kqueue (FreeBSD), epoll (Linux) и другие, для эффективной обработки сетевых соединений.
Оптимизация передачи данных: Использование технологий, таких как sendfile и асинхронный ввод/вывод (AIO), минимизирует копирование данных и ускоряет доставку контента.
Низкое потребление памяти: Например, для 10 000 неактивных HTTP keep-alive соединений требуется всего около 2,5 МБ памяти.
Запросы пользователей разбиваются на небольшие сетевые соединения, которые обрабатываются асинхронно. После обработки они собираются в единый ответ и отправляются клиенту. Одно соединение может обрабатывать до 1024 запросов, что значительно повышает производительность.
Для чего нужен Nginx?
Nginx универсален и применяется в различных сценариях:
Веб-сервер
Обслуживает статический контент (HTML, CSS, изображения, JavaScript) с высокой скоростью.
Обратный прокси
Перенаправляет запросы к другим серверам, скрывая их от клиента.
Балансировка нагрузки
Распределяет входящий трафик между несколькими серверами для повышения отказоустойчивости.
Кеширование
Сохраняет часто запрашиваемый контент для ускорения доставки.
Почтовый прокси
Поддерживает протоколы IMAP, POP3, SMTP с возможностью аутентификации через HTTP.
Безопасность
Поддерживает SSL/TLS, ограничение доступа по IP и защиту от DDoS-атак.
Nginx особенно эффективен для высоконагруженных веб-приложений, где требуется быстрая доставка контента и стабильность при большом количестве запросов.
Почему выбрать Nginx?
Nginx выделяется среди других веб-серверов, таких как Apache, по нескольким причинам:
Высокая производительность: Асинхронная архитектура позволяет обрабатывать больше запросов с меньшими ресурсами.
Эффективность для статического контента: Nginx быстрее Apache в доставке статических файлов, таких как изображения и CSS.
Модульная архитектура: Легко расширяется с помощью модулей для добавления новых функций.
Низкое потребление ресурсов: Минимизирует использование памяти и процессора, что идеально для серверов с ограниченными ресурсами.
Широкое применение: Используется крупными компаниями, такими как Netflix, Dropbox и WordPress.com, что подтверждает его надежность.
Nginx также может работать в связке с Apache: Nginx обрабатывает статический контент, а Apache — динамический, что оптимизирует производительность сайта.
#Java #middle #on_request #nginx
Nginx (произносится как "engine x") — это высокопроизводительное программное обеспечение с открытым исходным кодом, выполняющее функции веб-сервера, обратного прокси-сервера, балансировщика нагрузки, TCP/UDP-прокси и почтового прокси-сервера. Созданное Игорем Сысоевым в 2004 году, оно распространяется под лицензией BSD из 2 пунктов. Nginx завоевал популярность благодаря своей скорости, стабильности и низкому потреблению ресурсов, что делает его выбором для многих высоконагруженных сайтов, таких как Netflix, Dropbox, Яндекс и ВКонтакте.
Согласно данным W3Techs (по состоянию на апрель 2025 года), Nginx занимает первое место среди веб-серверов, обслуживая 33,8% всех веб-сайтов, опережая Apache (26,4%) и Cloudflare Server (23,4%). Это подчеркивает его широкое признание и надежность.
Как работает Nginx?
Nginx использует асинхронную событийно-ориентированную архитектуру, которая позволяет обрабатывать тысячи одновременных соединений с минимальным использованием ресурсов.
Основные аспекты его работы включают:
Один основной процесс и несколько рабочих процессов: Основной процесс управляет конфигурацией и координирует работу, а рабочие процессы обрабатывают запросы пользователей. Это снижает накладные расходы по сравнению с многопоточной моделью, используемой, например, в Apache.
Механизмы событий: Nginx поддерживает такие технологии, как kqueue (FreeBSD), epoll (Linux) и другие, для эффективной обработки сетевых соединений.
Оптимизация передачи данных: Использование технологий, таких как sendfile и асинхронный ввод/вывод (AIO), минимизирует копирование данных и ускоряет доставку контента.
Низкое потребление памяти: Например, для 10 000 неактивных HTTP keep-alive соединений требуется всего около 2,5 МБ памяти.
Запросы пользователей разбиваются на небольшие сетевые соединения, которые обрабатываются асинхронно. После обработки они собираются в единый ответ и отправляются клиенту. Одно соединение может обрабатывать до 1024 запросов, что значительно повышает производительность.
Для чего нужен Nginx?
Nginx универсален и применяется в различных сценариях:
Веб-сервер
Обслуживает статический контент (HTML, CSS, изображения, JavaScript) с высокой скоростью.
Обратный прокси
Перенаправляет запросы к другим серверам, скрывая их от клиента.
Балансировка нагрузки
Распределяет входящий трафик между несколькими серверами для повышения отказоустойчивости.
Кеширование
Сохраняет часто запрашиваемый контент для ускорения доставки.
Почтовый прокси
Поддерживает протоколы IMAP, POP3, SMTP с возможностью аутентификации через HTTP.
Безопасность
Поддерживает SSL/TLS, ограничение доступа по IP и защиту от DDoS-атак.
Nginx особенно эффективен для высоконагруженных веб-приложений, где требуется быстрая доставка контента и стабильность при большом количестве запросов.
Почему выбрать Nginx?
Nginx выделяется среди других веб-серверов, таких как Apache, по нескольким причинам:
Высокая производительность: Асинхронная архитектура позволяет обрабатывать больше запросов с меньшими ресурсами.
Эффективность для статического контента: Nginx быстрее Apache в доставке статических файлов, таких как изображения и CSS.
Модульная архитектура: Легко расширяется с помощью модулей для добавления новых функций.
Низкое потребление ресурсов: Минимизирует использование памяти и процессора, что идеально для серверов с ограниченными ресурсами.
Широкое применение: Используется крупными компаниями, такими как Netflix, Dropbox и WordPress.com, что подтверждает его надежность.
Nginx также может работать в связке с Apache: Nginx обрабатывает статический контент, а Apache — динамический, что оптимизирует производительность сайта.
#Java #middle #on_request #nginx
👍6🔥3
Простая установка Nginx на Ubuntu
Установка Nginx на Ubuntu проста и занимает всего несколько минут.
Обновите списки пакетов:
Установите Nginx:
Запустите Nginx:
Включите автозапуск Nginx:
Проверьте статус Nginx:
Для настройки брандмауэра (если используется ufw) разрешите HTTP-трафик:
Демонстрация работы Nginx
После выполнения вышеуказанных шагов откройте веб-браузер и введите IP-адрес вашего сервера (например, http://your_server_ip). Вы увидите стандартную страницу приветствия Nginx.
Эта страница подтверждает, что Nginx установлен и функционирует корректно. Если страница не отображается, проверьте статус сервера и настройки брандмауэра.
#Java #middle #on_request #nginx
Установка Nginx на Ubuntu проста и занимает всего несколько минут.
Обновите списки пакетов:
sudo apt update
Эта команда обновляет индекс пакетов для системы управления пакетами apt.
Установите Nginx:
sudo apt install nginx
Подтвердите установку, нажав Y и Enter, когда система запросит разрешение.
Запустите Nginx:
sudo systemctl start nginx
Эта команда запускает веб-сервер.
Включите автозапуск Nginx:
sudo systemctl enable nginx
Это гарантирует, что Nginx будет запускаться автоматически при перезагрузке системы.
Проверьте статус Nginx:
sudo systemctl status nginx
Если в выводе указано active (running), сервер работает корректно.
Для настройки брандмауэра (если используется ufw) разрешите HTTP-трафик:
sudo ufw allow 'Nginx HTTP'
sudo ufw status
Демонстрация работы Nginx
После выполнения вышеуказанных шагов откройте веб-браузер и введите IP-адрес вашего сервера (например, http://your_server_ip). Вы увидите стандартную страницу приветствия Nginx.
Эта страница подтверждает, что Nginx установлен и функционирует корректно. Если страница не отображается, проверьте статус сервера и настройки брандмауэра.
#Java #middle #on_request #nginx
👍5🔥1
Введение в NoSQL базы данных
Что такое NoSQL и почему они появились
NoSQL базы данных — это нереляционные системы, которые хранят информацию не в табличной форме. Они возникли в 2000-х годах благодаря компаниям вроде Google и Amazon, чтобы обрабатывать петабайты данных в распределенных системах. В отличие от реляционных баз, как MySQL или PostgreSQL, NoSQL не требуют предопределенной схемы данных, что упрощает разработку и изменения.
Отличия от реляционных баз
Реляционные базы используют таблицы, где данные организованы в строки и столбцы с отношениями через ключи. Они следуют ACID-принципам: атомарность (все или ничего), согласованность, изоляция и долговечность. NoSQL, напротив, часто следуют BASE-модели: базовая доступность, мягкое состояние и eventual consistency. Это значит, что данные могут быть временно несогласованными, но система всегда доступна. NoSQL лучше масштабируется горизонтально, добавляя дешевые серверы, в то время как SQL — вертикально, улучшая один сервер.
Что такое NoSQL базы данных?
NoSQL (от "not only SQL") — это класс баз данных, которые не придерживаются строгой реляционной модели. В отличие от классических баз, где данные хранятся в таблицах с фиксированными столбцами и строками, NoSQL позволяют работать с данными в более естественной форме. Термин "NoSQL" появился в конце 1990-х, но настоящий бум пришелся на 2000-е годы благодаря компаниям вроде Google (с их BigTable) и Amazon (Dynamo). Эти системы предназначены для обработки огромных объемов данных в распределенных средах, где традиционные базы дают сбой из-за масштаба.
NoSQL фокусируются на горизонтальной масштабируемости (sharding — разделение данных по серверам) и отказоустойчивости. Они часто реализуют распределенные архитектуры с репликацией (копированием данных на несколько узлов), что обеспечивает высокую доступность. Однако это требует понимания trade-off'ов, таких как потеря строгой consistency в пользу availability, как описано в CAP-теореме Эрика Брюера: в распределенной системе можно гарантировать только два из трех свойств — Consistency (согласованность), Availability (доступность) и Partition tolerance (устойчивость к разделению сети). Большинство NoSQL выбирают AP (availability + partition tolerance), жертвуя immediate consistency.
Где применяются NoSQL базы данных
NoSQL shine в сценариях с высокой нагрузкой и разнообразными данными. Они доминируют в web 2.0 и cloud-native приложениях.
- Big Data и аналитика: Для обработки петабайт данных, как в Hadoop-экосистемах. Пример: HBase для хранения логов в Facebook.
- Реал-тайм приложения: Социальные сети (Twitter использует Cassandra для timeline), рекомендации (Netflix с DynamoDB-подобными системами).
- IoT и сенсорные данные: Миллионы устройств генерируют неструктурированные данные; NoSQL справляется с velocity (скоростью поступления).
- E-commerce: Управление каталогами, сессиями, корзинами. Amazon DynamoDB для Black Friday трафика.
- Мобильные и гейминг apps: Redis для лидербордов, MongoDB для пользовательских профилей.
- Контент-менеджмент: CMS вроде WordPress на MongoDB для динамического контента.
В микросервисах NoSQL поддерживает polyglot persistence — разные сервисы используют разные базы. Например, key-value для caching в Redis, graph для fraud detection в Neo4j. Учитывайте latency: NoSQL часто использует in-memory storage для sub-millisecond отклика, но требует мониторинга quorum (кворума реплик) для consistency. В hybrid подходах сочетают SQL для транзакций и NoSQL для scale-out.
#Java #middle #on_request #no_sql_db
Что такое NoSQL и почему они появились
NoSQL базы данных — это нереляционные системы, которые хранят информацию не в табличной форме. Они возникли в 2000-х годах благодаря компаниям вроде Google и Amazon, чтобы обрабатывать петабайты данных в распределенных системах. В отличие от реляционных баз, как MySQL или PostgreSQL, NoSQL не требуют предопределенной схемы данных, что упрощает разработку и изменения.
Отличия от реляционных баз
Реляционные базы используют таблицы, где данные организованы в строки и столбцы с отношениями через ключи. Они следуют ACID-принципам: атомарность (все или ничего), согласованность, изоляция и долговечность. NoSQL, напротив, часто следуют BASE-модели: базовая доступность, мягкое состояние и eventual consistency. Это значит, что данные могут быть временно несогласованными, но система всегда доступна. NoSQL лучше масштабируется горизонтально, добавляя дешевые серверы, в то время как SQL — вертикально, улучшая один сервер.
Что такое NoSQL базы данных?
NoSQL (от "not only SQL") — это класс баз данных, которые не придерживаются строгой реляционной модели. В отличие от классических баз, где данные хранятся в таблицах с фиксированными столбцами и строками, NoSQL позволяют работать с данными в более естественной форме. Термин "NoSQL" появился в конце 1990-х, но настоящий бум пришелся на 2000-е годы благодаря компаниям вроде Google (с их BigTable) и Amazon (Dynamo). Эти системы предназначены для обработки огромных объемов данных в распределенных средах, где традиционные базы дают сбой из-за масштаба.
NoSQL фокусируются на горизонтальной масштабируемости (sharding — разделение данных по серверам) и отказоустойчивости. Они часто реализуют распределенные архитектуры с репликацией (копированием данных на несколько узлов), что обеспечивает высокую доступность. Однако это требует понимания trade-off'ов, таких как потеря строгой consistency в пользу availability, как описано в CAP-теореме Эрика Брюера: в распределенной системе можно гарантировать только два из трех свойств — Consistency (согласованность), Availability (доступность) и Partition tolerance (устойчивость к разделению сети). Большинство NoSQL выбирают AP (availability + partition tolerance), жертвуя immediate consistency.
Где применяются NoSQL базы данных
NoSQL shine в сценариях с высокой нагрузкой и разнообразными данными. Они доминируют в web 2.0 и cloud-native приложениях.
- Big Data и аналитика: Для обработки петабайт данных, как в Hadoop-экосистемах. Пример: HBase для хранения логов в Facebook.
- Реал-тайм приложения: Социальные сети (Twitter использует Cassandra для timeline), рекомендации (Netflix с DynamoDB-подобными системами).
- IoT и сенсорные данные: Миллионы устройств генерируют неструктурированные данные; NoSQL справляется с velocity (скоростью поступления).
- E-commerce: Управление каталогами, сессиями, корзинами. Amazon DynamoDB для Black Friday трафика.
- Мобильные и гейминг apps: Redis для лидербордов, MongoDB для пользовательских профилей.
- Контент-менеджмент: CMS вроде WordPress на MongoDB для динамического контента.
В микросервисах NoSQL поддерживает polyglot persistence — разные сервисы используют разные базы. Например, key-value для caching в Redis, graph для fraud detection в Neo4j. Учитывайте latency: NoSQL часто использует in-memory storage для sub-millisecond отклика, но требует мониторинга quorum (кворума реплик) для consistency. В hybrid подходах сочетают SQL для транзакций и NoSQL для scale-out.
#Java #middle #on_request #no_sql_db
👍7
Основные типы и виды NoSQL баз
NoSQL классифицируют по модели данных. Вот четыре основных типа с примерами и применениями.
1. Key-Value stores (хранилища ключ-значение)
Самые простые, как словарь в Python. Ключ — уникальный идентификатор, значение — любой blob данных (строка, объект). Нет сложных запросов, только get/set по ключу.
- Преимущества: Высокая скорость, простота, отличны для caching.
- Недостатки: Нет поддержки сложных поисков без индексов.
- Примеры: Redis (in-memory, поддерживает pub/sub), Amazon DynamoDB (managed, с auto-scaling).
- Применения: Сессии пользователей, временные данные, как в онлайн-играх.
2. Document stores (документные базы)
Хранят данные как документы (JSON, BSON, XML). Каждый документ — самодостаточный, с вложенными структурами.
- Преимущества: Гибкость, естественное маппинг на объекты в коде, поддержка индексов и aggregation.
- Недостатки: Могут быть неэффективны для глубоких joins.
- Примеры: MongoDB (с MQL-запросами, sharding), CouchDB (фокус на replication для offline-first apps).
- Применения: CMS, e-commerce каталоги, где схема эволюционирует.
3. Column-family stores (столбцовые или wide-column базы)
Данные в таблицах, но столбцы динамические и группируются в семьи. Эффективны для sparse data (много null).
- Преимущества: Масштабируемость для write-heavy нагрузок, compression столбцов.
- Недостатки: Сложные для ad-hoc запросов.
- Примеры: Apache Cassandra (ring-архитектура, tunable consistency), HBase (на Hadoop, для time-series).
- Применения: Логи, аналитика, социальные фиды.
4. Graph databases (графовые базы)
Данные как узлы (nodes), ребра (edges) и свойства. Идеальны для traversal (проход по связям).
- Преимущества: Быстрые запросы на отношения (e.g., "друзья друзей"), алгоритмы вроде shortest path.
- Недостатки: Меньше подходит для простых CRUD.
- Примеры: Neo4j (Cypher язык, ACID-транзакции), ArangoDB (multi-model, сочетает document+graph).
- Применения: Социальные сети, рекомендации, knowledge graphs в AI.
#Java #middle #on_request #no_sql_db
NoSQL классифицируют по модели данных. Вот четыре основных типа с примерами и применениями.
1. Key-Value stores (хранилища ключ-значение)
Самые простые, как словарь в Python. Ключ — уникальный идентификатор, значение — любой blob данных (строка, объект). Нет сложных запросов, только get/set по ключу.
- Преимущества: Высокая скорость, простота, отличны для caching.
- Недостатки: Нет поддержки сложных поисков без индексов.
- Примеры: Redis (in-memory, поддерживает pub/sub), Amazon DynamoDB (managed, с auto-scaling).
- Применения: Сессии пользователей, временные данные, как в онлайн-играх.
2. Document stores (документные базы)
Хранят данные как документы (JSON, BSON, XML). Каждый документ — самодостаточный, с вложенными структурами.
- Преимущества: Гибкость, естественное маппинг на объекты в коде, поддержка индексов и aggregation.
- Недостатки: Могут быть неэффективны для глубоких joins.
- Примеры: MongoDB (с MQL-запросами, sharding), CouchDB (фокус на replication для offline-first apps).
- Применения: CMS, e-commerce каталоги, где схема эволюционирует.
3. Column-family stores (столбцовые или wide-column базы)
Данные в таблицах, но столбцы динамические и группируются в семьи. Эффективны для sparse data (много null).
- Преимущества: Масштабируемость для write-heavy нагрузок, compression столбцов.
- Недостатки: Сложные для ad-hoc запросов.
- Примеры: Apache Cassandra (ring-архитектура, tunable consistency), HBase (на Hadoop, для time-series).
- Применения: Логи, аналитика, социальные фиды.
4. Graph databases (графовые базы)
Данные как узлы (nodes), ребра (edges) и свойства. Идеальны для traversal (проход по связям).
- Преимущества: Быстрые запросы на отношения (e.g., "друзья друзей"), алгоритмы вроде shortest path.
- Недостатки: Меньше подходит для простых CRUD.
- Примеры: Neo4j (Cypher язык, ACID-транзакции), ArangoDB (multi-model, сочетает document+graph).
- Применения: Социальные сети, рекомендации, knowledge graphs в AI.
#Java #middle #on_request #no_sql_db
👍6
Kubernetes
Зачем миру нужен Kubernetes?
Представьте, что вы строите небоскреб. У вас есть тысячи кирпичей (контейнеров), краны (серверы), рабочие (процессы). Без грамотного архитектора и прораба всё превратится в хаос: кирпичи будут лежать криво, краны простаивать, а рабочие — спорить, кто за что отвечает.
Kubernetes (сокр. K8s) — это и есть тот самый «цифровой прораб», который автоматизирует развертывание, масштабирование и управление контейнеризированными приложениями. Но это не просто инструмент — это стандарт де-факто для оркестрации контейнеров в мире cloud-native разработки.
Почему это важно?
Когда приложения разбиваются на микросервисы (десятки или сотни независимых компонентов), ручное управление ими становится невозможным. Kubernetes решает эту проблему, превращая инфраструктуру в «самонастраивающуюся» систему, которая:
- Автоматически восстанавливает упавшие сервисы
- Масштабирует нагрузку «на лету»
- Обеспечивает непрерывную доставку кода без простоя
История: от внутренних систем Google к мировому стандарту
2014: Рождение в недрах Google
Kubernetes не появился на пустом месте. Его корни уходят в Borg — секретную систему оркестрации, которую Google использовал с 2003 года для управления своими сервисами (Поиск, Gmail, YouTube). Borg обрабатывал миллионы контейнеров ежедневно, но был закрыт для внешнего мира.
В 2014 году Google, совместно с Red Hat и Other, открыли исходный код Kubernetes (название происходит от греческого слова «κυβερνήτης» — «капитан, рулевой»). Это был не «облегченный Borg», а переработанная система с учетом опыта Google, но адаптированная для открытого использования.
2015: Передача в CNCF
Google передал Kubernetes Cloud Native Computing Foundation (CNCF) — некоммерческой организации, поддерживающей cloud-native технологии. Это был стратегический ход: чтобы система стала стандартом, она должна быть нейтральной и развиваться сообществом. Сегодня Kubernetes — самый успешный проект CNCF, с участием AWS, Microsoft, IBM и тысяч разработчиков.
Почему именно Kubernetes победил?
На момент появления существовали конкуренты (Docker Swarm, Mesos), но K8s выделялся:
- Глубокая проработка edge cases (опыт Google с миллиардами запросов)
- Декларативная модель (описывайте «что нужно», а не «как сделать»)
- Экосистема расширений (API можно расширять без изменения ядра)
Архитектура: как устроен «цифровой прораб»
Kubernetes работает по принципу control plane + data plane. Это как центр управления полетами (control plane) и самолеты (data plane).
Control Plane: «мозг» кластера
Располагается на master-нодах (хотя термин «master» устарел — теперь используется control plane node).
Состоит из:
1. API Server
Что это: Единственная точка входа для всех операций (развертывание, мониторинг).
Как работает: Принимает REST-запросы, проверяет права (через RBAC), записывает изменения в etcd.
Нюанс: Все компоненты взаимодействуют через API Server, даже сам Kubernetes. Это обеспечивает единую точку контроля и аудита.
2. etcd
Что это: Распределенное хранилище «состояния кластера» (какая нода работает, какие поды запущены).
Как работает: Хранит данные в виде ключ-значение. При изменении состояния (например, запуске нового пода) etcd рассылает события.
Нюанс: Требует нечетного числа нод (3, 5, 7) для кворума. Потеря большинства нод — катастрофа (split-brain).
3. Scheduler
Что это: «Распределитель задач». Решает, на какой ноде запустить новый под.
Как работает: Анализирует ресурсы нод (CPU, память), правила (taints/tolerations, affinity), выбирает оптимальный вариант.
Нюанс: Можно написать кастомный scheduler через API, если стандартный не подходит (например, для HPC-задач).
#Java #middle #on_request #Kubernetes
Зачем миру нужен Kubernetes?
Представьте, что вы строите небоскреб. У вас есть тысячи кирпичей (контейнеров), краны (серверы), рабочие (процессы). Без грамотного архитектора и прораба всё превратится в хаос: кирпичи будут лежать криво, краны простаивать, а рабочие — спорить, кто за что отвечает.
Kubernetes (сокр. K8s) — это и есть тот самый «цифровой прораб», который автоматизирует развертывание, масштабирование и управление контейнеризированными приложениями. Но это не просто инструмент — это стандарт де-факто для оркестрации контейнеров в мире cloud-native разработки.
Почему это важно?
Когда приложения разбиваются на микросервисы (десятки или сотни независимых компонентов), ручное управление ими становится невозможным. Kubernetes решает эту проблему, превращая инфраструктуру в «самонастраивающуюся» систему, которая:
- Автоматически восстанавливает упавшие сервисы
- Масштабирует нагрузку «на лету»
- Обеспечивает непрерывную доставку кода без простоя
История: от внутренних систем Google к мировому стандарту
2014: Рождение в недрах Google
Kubernetes не появился на пустом месте. Его корни уходят в Borg — секретную систему оркестрации, которую Google использовал с 2003 года для управления своими сервисами (Поиск, Gmail, YouTube). Borg обрабатывал миллионы контейнеров ежедневно, но был закрыт для внешнего мира.
В 2014 году Google, совместно с Red Hat и Other, открыли исходный код Kubernetes (название происходит от греческого слова «κυβερνήτης» — «капитан, рулевой»). Это был не «облегченный Borg», а переработанная система с учетом опыта Google, но адаптированная для открытого использования.
2015: Передача в CNCF
Google передал Kubernetes Cloud Native Computing Foundation (CNCF) — некоммерческой организации, поддерживающей cloud-native технологии. Это был стратегический ход: чтобы система стала стандартом, она должна быть нейтральной и развиваться сообществом. Сегодня Kubernetes — самый успешный проект CNCF, с участием AWS, Microsoft, IBM и тысяч разработчиков.
Почему именно Kubernetes победил?
На момент появления существовали конкуренты (Docker Swarm, Mesos), но K8s выделялся:
- Глубокая проработка edge cases (опыт Google с миллиардами запросов)
- Декларативная модель (описывайте «что нужно», а не «как сделать»)
- Экосистема расширений (API можно расширять без изменения ядра)
Архитектура: как устроен «цифровой прораб»
Kubernetes работает по принципу control plane + data plane. Это как центр управления полетами (control plane) и самолеты (data plane).
Control Plane: «мозг» кластера
Располагается на master-нодах (хотя термин «master» устарел — теперь используется control plane node).
Состоит из:
1. API Server
Что это: Единственная точка входа для всех операций (развертывание, мониторинг).
Как работает: Принимает REST-запросы, проверяет права (через RBAC), записывает изменения в etcd.
Нюанс: Все компоненты взаимодействуют через API Server, даже сам Kubernetes. Это обеспечивает единую точку контроля и аудита.
2. etcd
Что это: Распределенное хранилище «состояния кластера» (какая нода работает, какие поды запущены).
Как работает: Хранит данные в виде ключ-значение. При изменении состояния (например, запуске нового пода) etcd рассылает события.
Нюанс: Требует нечетного числа нод (3, 5, 7) для кворума. Потеря большинства нод — катастрофа (split-brain).
3. Scheduler
Что это: «Распределитель задач». Решает, на какой ноде запустить новый под.
Как работает: Анализирует ресурсы нод (CPU, память), правила (taints/tolerations, affinity), выбирает оптимальный вариант.
Нюанс: Можно написать кастомный scheduler через API, если стандартный не подходит (например, для HPC-задач).
#Java #middle #on_request #Kubernetes
👍5
Архитектура Kubernetes
Kubernetes работает по принципу control plane + data plane. Это как центр управления полетами (control plane) и самолеты (data plane).
Control Plane: "мозг" кластера
Располагается на master-нодах (хотя термин «master» устарел — теперь используется control plane node).
Состоит из:
1. API Server
Что это: Единственная точка входа для всех операций (развертывание, мониторинг).
Как работает: Принимает REST-запросы, проверяет права (через RBAC), записывает изменения в etcd.
Нюанс: Все компоненты взаимодействуют через API Server, даже сам Kubernetes. Это обеспечивает единую точку контроля и аудита.
2. etcd
Что это: Распределенное хранилище «состояния кластера» (какая нода работает, какие поды запущены).
Как работает: Хранит данные в виде ключ-значение. При изменении состояния (например, запуске нового пода) etcd рассылает события.
Нюанс: Требует нечетного числа нод (3, 5, 7) для кворума. Потеря большинства нод — катастрофа (split-brain).
3. Scheduler
Что это: «Распределитель задач». Решает, на какой ноде запустить новый под.
Как работает: Анализирует ресурсы нод (CPU, память), правила (taints/tolerations, affinity), выбирает оптимальный вариант.
Нюанс: Можно написать кастомный scheduler через API, если стандартный не подходит (например, для HPC-задач).
4. Controller Manager
Что это: Набор «контроллеров», следящих за состоянием кластера.
Как работает: Например, Deployment Controller следит, чтобы количество запущенных подов соответствовало желаемому. Если под падает — пересоздает его.
Нюанс: Контроллеры работают по принципу reconciliation loop: постоянно сравнивают текущее состояние с желаемым.
5. Cloud Controller Manager (опционально)
Что это: Интеграция с облачными провайдерами (AWS, GCP).
Как работает: Управляет балансировщиками нагрузки, томами, сетями через API облака.
Data Plane: "рабочие руки"
Состоит из worker nodes (рабочих нод), где запускаются приложения:
1. Kubelet
Что это: Агент на каждой ноде.
Как работает: Получает задания от API Server, запускает/останавливает контейнеры через container runtime (Docker, containerd).
Нюанс: Kubelet не перезапускает контейнеры сам — это делают контроллеры (например, через Deployment).
2. Kube-proxy
Что это: Сетевой прокси.
Как работает: Обеспечивает доступ к сервисам через iptables/IPVS. Например, при обращении к my-service перенаправляет трафик на поды.
Нюанс: В режиме IPVS используется хэширование для балансировки, что эффективнее iptables при 10k+ сервисов.
3. Container Runtime
Что это: Движок для запуска контейнеров (Docker, containerd, CRI-O).
Нюанс: Kubernetes использует CRI (Container Runtime Interface) — абстрактный API, поэтому можно менять runtime без пересборки K8s.
#Java #middle #on_request #Kubernetes
Kubernetes работает по принципу control plane + data plane. Это как центр управления полетами (control plane) и самолеты (data plane).
Control Plane: "мозг" кластера
Располагается на master-нодах (хотя термин «master» устарел — теперь используется control plane node).
Состоит из:
1. API Server
Что это: Единственная точка входа для всех операций (развертывание, мониторинг).
Как работает: Принимает REST-запросы, проверяет права (через RBAC), записывает изменения в etcd.
Нюанс: Все компоненты взаимодействуют через API Server, даже сам Kubernetes. Это обеспечивает единую точку контроля и аудита.
2. etcd
Что это: Распределенное хранилище «состояния кластера» (какая нода работает, какие поды запущены).
Как работает: Хранит данные в виде ключ-значение. При изменении состояния (например, запуске нового пода) etcd рассылает события.
Нюанс: Требует нечетного числа нод (3, 5, 7) для кворума. Потеря большинства нод — катастрофа (split-brain).
3. Scheduler
Что это: «Распределитель задач». Решает, на какой ноде запустить новый под.
Как работает: Анализирует ресурсы нод (CPU, память), правила (taints/tolerations, affinity), выбирает оптимальный вариант.
Нюанс: Можно написать кастомный scheduler через API, если стандартный не подходит (например, для HPC-задач).
4. Controller Manager
Что это: Набор «контроллеров», следящих за состоянием кластера.
Как работает: Например, Deployment Controller следит, чтобы количество запущенных подов соответствовало желаемому. Если под падает — пересоздает его.
Нюанс: Контроллеры работают по принципу reconciliation loop: постоянно сравнивают текущее состояние с желаемым.
5. Cloud Controller Manager (опционально)
Что это: Интеграция с облачными провайдерами (AWS, GCP).
Как работает: Управляет балансировщиками нагрузки, томами, сетями через API облака.
Data Plane: "рабочие руки"
Состоит из worker nodes (рабочих нод), где запускаются приложения:
1. Kubelet
Что это: Агент на каждой ноде.
Как работает: Получает задания от API Server, запускает/останавливает контейнеры через container runtime (Docker, containerd).
Нюанс: Kubelet не перезапускает контейнеры сам — это делают контроллеры (например, через Deployment).
2. Kube-proxy
Что это: Сетевой прокси.
Как работает: Обеспечивает доступ к сервисам через iptables/IPVS. Например, при обращении к my-service перенаправляет трафик на поды.
Нюанс: В режиме IPVS используется хэширование для балансировки, что эффективнее iptables при 10k+ сервисов.
3. Container Runtime
Что это: Движок для запуска контейнеров (Docker, containerd, CRI-O).
Нюанс: Kubernetes использует CRI (Container Runtime Interface) — абстрактный API, поэтому можно менять runtime без пересборки K8s.
#Java #middle #on_request #Kubernetes
👍5
Основные понятия Kubernetes
Cluster (кластер)
Что это: Группа нод (физических/виртуальных машин), управляющих приложениями.
Зачем: Объединяет ресурсы в единый «суперкомпьютер».
Нюанс: В production используют multi-zone кластеры для отказоустойчивости (ноды в разных зонах AZ).
Node (нода)
Что это: Отдельный сервер в кластере (worker или control plane).
Нюанс: Ноды могут иметь taints («отметки»), чтобы блокировать запуск подов (например, dedicated=gpu:NoSchedule).
Pod
Что это: Минимальная единица развертывания. Группа контейнеров, разделяющих сеть и томы.
Почему не один контейнер?
- Сторонние контейнеры (sidecar) для логирования, мониторинга
- Общая файловая система (например, веб-сервер + статика)
Нюанс: Pod не переживает перезагрузку ноды — его пересоздает контроллер.
Service
Что это: Абстракция для доступа к подам через стабильный IP/DNS.
Типы:
- ClusterIP (внутри кластера)
- NodePort (порт на каждой ноде)
- LoadBalancer (облачный балансировщик)
Нюанс: Service использует kube-proxy и EndpointSlice для балансировки. При 1000+ подах лучше включить EndpointSlice (уменьшает нагрузку на etcd).
Deployment
Что это: Управляет состоянием подов через ReplicaSet.
Как работает:
- Описывает желаемое состояние (например, 3 реплики)
- Обеспечивает rolling update (постепенное обновление без простоя)
- Поддерживает откат к предыдущей версии
Нюанс: Можно настроить readinessProbe (проверка готовности) и livenessProbe (проверка жизни) для корректного обновления.
ConfigMap и Secret
Что это: Хранение конфигурации и секретов.
Разница: Secret шифруется base64 (но не защищен по умолчанию — используйте etcd encryption или external secrets manager).
Нюанс: Избегайте монтирования ConfigMap как volume — при обновлении значения попадут в под с задержкой (до 1 минуты).
Как это работает: от команды до работающего приложения
1. Вы описываете желаемое состояние
Например, в YAML-манифесте Deployment указываете: replicas: 3, image: my-app:v2.
2. API Server сохраняет состояние в etcd
Все компоненты получают уведомление через watch API.
3. Scheduler назначает поды на ноды
Выбирает ноды с достаточными ресурсами, учитывая правила (например, nodeSelector: disk=ssd).
4. Kubelet запускает контейнеры
Через container runtime создает Pod с вашим приложением и sidecar-контейнерами (если есть).
5. Service направляет трафик
При обращении к my-service kube-proxy балансирует запросы между подами.
6. Контроллеры поддерживают стабильность
Если нода упала — Deployment Controller создаст новые поды на других нодах.
Ключевые особенности: почему это enterprise-ready
Декларативная модель
Вы говорите «каким должно быть приложение», а не «как его развернуть».
Например:
Kubernetes сам решает, как достичь этого состояния (запустить новые поды, убить старые).
Self-healing
- Автоматический перезапуск упавших контейнеров
- Перемещение подов с нерабочих нод
- Проверка здоровья через liveness/readiness probes
Горизонтальное масштабирование
- HPA (Horizontal Pod Autoscaler): Масштабирует поды по CPU/memory или кастомным метрикам (например, RPS)
- Cluster Autoscaler: Добавляет/удаляет ноды в облаке при нехватке ресурсов
Организация конфигурации
- Namespaces: Изоляция сред (dev, prod)
- Resource Quotas: Ограничение ресурсов на namespace
- Network Policies: Контроль трафика между подами (как firewall)
Экосистема: Kubernetes как платформа
Kubernetes — не монолит, а ядро для построения платформы.
Расширения через:
- Operators: Управление stateful-приложениями (PostgreSQL, Kafka) как нативными объектами
- CRD (Custom Resource Definitions): Добавление своих типов объектов (например, CronTab)
- Helm: Управление версиями манифестов («пакетный менеджер для K8s»)
- Istio: Сервис-меш для продвинутой маршрутизации, мониторинга
#Java #middle #on_request #Kubernetes
Cluster (кластер)
Что это: Группа нод (физических/виртуальных машин), управляющих приложениями.
Зачем: Объединяет ресурсы в единый «суперкомпьютер».
Нюанс: В production используют multi-zone кластеры для отказоустойчивости (ноды в разных зонах AZ).
Node (нода)
Что это: Отдельный сервер в кластере (worker или control plane).
Нюанс: Ноды могут иметь taints («отметки»), чтобы блокировать запуск подов (например, dedicated=gpu:NoSchedule).
Pod
Что это: Минимальная единица развертывания. Группа контейнеров, разделяющих сеть и томы.
Почему не один контейнер?
- Сторонние контейнеры (sidecar) для логирования, мониторинга
- Общая файловая система (например, веб-сервер + статика)
Нюанс: Pod не переживает перезагрузку ноды — его пересоздает контроллер.
Service
Что это: Абстракция для доступа к подам через стабильный IP/DNS.
Типы:
- ClusterIP (внутри кластера)
- NodePort (порт на каждой ноде)
- LoadBalancer (облачный балансировщик)
Нюанс: Service использует kube-proxy и EndpointSlice для балансировки. При 1000+ подах лучше включить EndpointSlice (уменьшает нагрузку на etcd).
Deployment
Что это: Управляет состоянием подов через ReplicaSet.
Как работает:
- Описывает желаемое состояние (например, 3 реплики)
- Обеспечивает rolling update (постепенное обновление без простоя)
- Поддерживает откат к предыдущей версии
Нюанс: Можно настроить readinessProbe (проверка готовности) и livenessProbe (проверка жизни) для корректного обновления.
ConfigMap и Secret
Что это: Хранение конфигурации и секретов.
Разница: Secret шифруется base64 (но не защищен по умолчанию — используйте etcd encryption или external secrets manager).
Нюанс: Избегайте монтирования ConfigMap как volume — при обновлении значения попадут в под с задержкой (до 1 минуты).
Как это работает: от команды до работающего приложения
1. Вы описываете желаемое состояние
Например, в YAML-манифесте Deployment указываете: replicas: 3, image: my-app:v2.
2. API Server сохраняет состояние в etcd
Все компоненты получают уведомление через watch API.
3. Scheduler назначает поды на ноды
Выбирает ноды с достаточными ресурсами, учитывая правила (например, nodeSelector: disk=ssd).
4. Kubelet запускает контейнеры
Через container runtime создает Pod с вашим приложением и sidecar-контейнерами (если есть).
5. Service направляет трафик
При обращении к my-service kube-proxy балансирует запросы между подами.
6. Контроллеры поддерживают стабильность
Если нода упала — Deployment Controller создаст новые поды на других нодах.
Ключевые особенности: почему это enterprise-ready
Декларативная модель
Вы говорите «каким должно быть приложение», а не «как его развернуть».
Например:
replicas: 5 # Не "запусти 5 экземпляров", а "должно быть 5 реплик"
Kubernetes сам решает, как достичь этого состояния (запустить новые поды, убить старые).
Self-healing
- Автоматический перезапуск упавших контейнеров
- Перемещение подов с нерабочих нод
- Проверка здоровья через liveness/readiness probes
Горизонтальное масштабирование
- HPA (Horizontal Pod Autoscaler): Масштабирует поды по CPU/memory или кастомным метрикам (например, RPS)
- Cluster Autoscaler: Добавляет/удаляет ноды в облаке при нехватке ресурсов
Организация конфигурации
- Namespaces: Изоляция сред (dev, prod)
- Resource Quotas: Ограничение ресурсов на namespace
- Network Policies: Контроль трафика между подами (как firewall)
Экосистема: Kubernetes как платформа
Kubernetes — не монолит, а ядро для построения платформы.
Расширения через:
- Operators: Управление stateful-приложениями (PostgreSQL, Kafka) как нативными объектами
- CRD (Custom Resource Definitions): Добавление своих типов объектов (например, CronTab)
- Helm: Управление версиями манифестов («пакетный менеджер для K8s»)
- Istio: Сервис-меш для продвинутой маршрутизации, мониторинга
#Java #middle #on_request #Kubernetes
👍6
Введение в GraphQL
GraphQL — это язык запросов для приложения, который позволяет клиентам (например, мобильным приложениям или веб-сайтам) запрашивать ровно те данные, которые им нужны, без лишнего. Он был создан компанией Facebook в 2012 году и стал открытым стандартом в 2015. В отличие от традиционных подходов, где сервер диктует, какие данные отдавать, здесь клиент сам формирует запрос. Это делает систему гибкой и эффективной.
Почему GraphQL вместо привычных методов?
Представь, что у тебя есть интернет-магазин. В старом подходе, называемом REST (это аббревиатура от "Representational State Transfer", что значит "передача состояния представления" — способ организации API, где каждый запрос идёт по фиксированному адресу), ты бы создал отдельные точки входа: одну для списка товаров, другую для деталей пользователя, третью для отзывов. Клиент запрашивает всё сразу, даже если ему нужно только имя товара и цена — и получает кучу лишних данных. Это тратит трафик и замедляет приложение.
GraphQL решает это одной точкой входа (обычно /graphql). Клиент пишет запрос на языке, похожем на JSON, указывая, какие поля нужны. Сервер возвращает только их.
Плюсы:
Меньше запросов: Можно получить данные из нескольких источников за один раз.
Типизация: Всё строго описано в схеме (это как каркас данных, где указано, какие типы полей и как они связаны).
Версионирование не нужно: Клиенты сами выбирают, что запрашивать, без изменений в API.
Интроспекция: Клиент может "спросить" сервер о доступных данных.
В экосистеме Java GraphQL интегрируется легко, особенно с Spring Boot — это фреймворк для быстрой разработки приложений на Java, который упрощает настройку серверов. Есть библиотека graphql-java, но для Spring лучше использовать spring-graphql — она берёт на себя интеграцию.
Настройка проекта: Шаги для старта
Давай создадим простой проект. Предполагаем, у тебя есть Java 17+ и Maven (система сборки проектов). Если новичок, скачай Spring Initializr с сайта spring.io — это онлайн-генератор проектов.
Создай проект Spring Boot с зависимостями:
Spring Web (для HTTP-сервера).
Spring GraphQL (для поддержки GraphQL).
Spring Data JPA (если нужно база данных, для хранения данных).
H2 Database (встроенная база для тестов).
В файле pom.xml (это конфигурация Maven) добавь:
Определи схему. Схема — это файл с описанием типов данных.
Создай файл schema.graphqls в resources/graphql:
Создай модель данных. В Java это классы с аннотациями (метками для фреймворка).
Для книги:
#Java #middle #on_request #GraphQL
GraphQL — это язык запросов для приложения, который позволяет клиентам (например, мобильным приложениям или веб-сайтам) запрашивать ровно те данные, которые им нужны, без лишнего. Он был создан компанией Facebook в 2012 году и стал открытым стандартом в 2015. В отличие от традиционных подходов, где сервер диктует, какие данные отдавать, здесь клиент сам формирует запрос. Это делает систему гибкой и эффективной.
Почему GraphQL вместо привычных методов?
Представь, что у тебя есть интернет-магазин. В старом подходе, называемом REST (это аббревиатура от "Representational State Transfer", что значит "передача состояния представления" — способ организации API, где каждый запрос идёт по фиксированному адресу), ты бы создал отдельные точки входа: одну для списка товаров, другую для деталей пользователя, третью для отзывов. Клиент запрашивает всё сразу, даже если ему нужно только имя товара и цена — и получает кучу лишних данных. Это тратит трафик и замедляет приложение.
GraphQL решает это одной точкой входа (обычно /graphql). Клиент пишет запрос на языке, похожем на JSON, указывая, какие поля нужны. Сервер возвращает только их.
Плюсы:
Меньше запросов: Можно получить данные из нескольких источников за один раз.
Типизация: Всё строго описано в схеме (это как каркас данных, где указано, какие типы полей и как они связаны).
Версионирование не нужно: Клиенты сами выбирают, что запрашивать, без изменений в API.
Интроспекция: Клиент может "спросить" сервер о доступных данных.
В экосистеме Java GraphQL интегрируется легко, особенно с Spring Boot — это фреймворк для быстрой разработки приложений на Java, который упрощает настройку серверов. Есть библиотека graphql-java, но для Spring лучше использовать spring-graphql — она берёт на себя интеграцию.
Настройка проекта: Шаги для старта
Давай создадим простой проект. Предполагаем, у тебя есть Java 17+ и Maven (система сборки проектов). Если новичок, скачай Spring Initializr с сайта spring.io — это онлайн-генератор проектов.
Создай проект Spring Boot с зависимостями:
Spring Web (для HTTP-сервера).
Spring GraphQL (для поддержки GraphQL).
Spring Data JPA (если нужно база данных, для хранения данных).
H2 Database (встроенная база для тестов).
В файле pom.xml (это конфигурация Maven) добавь:
xml<dependencies>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-graphql</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>
<dependency>
<groupId>com.h2database</groupId>
<artifactId>h2</artifactId>
<scope>runtime</scope>
</dependency>
</dependencies>
Определи схему. Схема — это файл с описанием типов данных.
Создай файл schema.graphqls в resources/graphql:
graphqltype Query {
bookById(id: ID): Book
allBooks: [Book]
}
type Book {
id: ID
title: String
author: Author
}
type Author {
id: ID
name: String
books: [Book]
}
Здесь Query — это корневой тип для запросов. ID — уникальный идентификатор, String — текст. [Book] значит список книг. Это позволяет запрашивать книги с авторами, и сервер сам свяжет данные.Создай модель данных. В Java это классы с аннотациями (метками для фреймворка).
Для книги:
javaimport jakarta.persistence.Entity;
import jakarta.persistence.Id;
import jakarta.persistence.ManyToOne;
@Entity
public class Book {
@Id
private Long id;
private String title;
@ManyToOne
private Author author;
// Геттеры и сеттеры (методы для чтения и записи полей)
public Long getId() { return id; }
public void setId(Long id) { this.id = id; }
public String getTitle() { return title; }
public void setTitle(String title) { this.title = title; }
public Author getAuthor() { return author; }
public void setAuthor(Author author) { this.author = author; }
}
#Java #middle #on_request #GraphQL
🔥3👍1
Репозитории для доступа к данным. Spring Data упрощает это:
Резолверы: Где происходит магия
Резолверы — это методы, которые "разрешают" запросы, то есть вычисляют данные.
В Spring создай класс:
Чтобы связать автора с книгами, добавь резолвер для типа Book:
Запуск и тестирование
В основном классе приложения (обычно с @SpringBootApplication) ничего менять не нужно — Spring сам настроит /graphql.
Запусти приложение:
Теперь протестируй в инструменте вроде GraphiQL (встроен в Spring GraphQL, доступен по /graphiql).
Пример запроса:
Сервер вернёт:
Только то, что запрошено! Если нужно мутации (изменения данных), добавь type Mutation в схему и резолверы для createBook и т.д.
Продвинутые советы для опытных
Обработка ошибок: Используй GraphQLError для кастомных сообщений.
Производительность: Добавь DataLoader для batch-запросов, чтобы избежать N+1 проблемы (когда для списка из N элементов делается N запросов в базу).
Безопасность: Включи аутентификацию с Spring Security, ограничи поля по ролям.
Интеграция с другими сервисами: GraphQL может агрегировать данные из микросервисов.
Пример с DataLoader для оптимизации:
Сначала добавь зависимость graphql-java-tools.
Затем в конфигурации:
В резолвере используй контекст для загрузки.
Это делает систему масштабируемой.
#Java #middle #on_request #GraphQL
javaimport org.springframework.data.jpa.repository.JpaRepository;
public interface BookRepository extends JpaRepository<Book, Long> {
}
Это интерфейс, который автоматически генерирует методы вроде findById.
Резолверы: Где происходит магия
Резолверы — это методы, которые "разрешают" запросы, то есть вычисляют данные.
В Spring создай класс:
javaimport graphql.kickstart.tools.GraphQLQueryResolver;
import org.springframework.beans.factory.annotation.Autowired;
public class QueryResolver implements GraphQLQueryResolver {
@Autowired
private BookRepository bookRepository;
public Book bookById(Long id) {
return bookRepository.findById(id).orElse(null); // Возвращает книгу или null, если не найдена
}
public List<Book> allBooks() {
return bookRepository.findAll(); // Все книги
}
}
@Autowired — это инъекция зависимости, Spring сам подставит репозиторий. Для автора аналогично создай AuthorResolver для поля books.
Чтобы связать автора с книгами, добавь резолвер для типа Book:
javaimport graphql.kickstart.tools.GraphQLResolver;
public class BookResolver implements GraphQLResolver<Book> {
public Author author(Book book) {
return book.getAuthor(); // Просто возвращает автора из модели
}
}
Это позволяет в запросе GraphQL получить автора без дополнительных усилий.
Запуск и тестирование
В основном классе приложения (обычно с @SpringBootApplication) ничего менять не нужно — Spring сам настроит /graphql.
Запусти приложение:
mvn spring-boot:run.
Теперь протестируй в инструменте вроде GraphiQL (встроен в Spring GraphQL, доступен по /graphiql).
Пример запроса:
graphqlquery {
bookById(id: 1) {
title
author {
name
}
}
}Сервер вернёт:
json{
"data": {
"bookById": {
"title": "Война и мир",
"author": {
"name": "Лев Толстой"
}
}
}
}Только то, что запрошено! Если нужно мутации (изменения данных), добавь type Mutation в схему и резолверы для createBook и т.д.
Продвинутые советы для опытных
Обработка ошибок: Используй GraphQLError для кастомных сообщений.
Производительность: Добавь DataLoader для batch-запросов, чтобы избежать N+1 проблемы (когда для списка из N элементов делается N запросов в базу).
Безопасность: Включи аутентификацию с Spring Security, ограничи поля по ролям.
Интеграция с другими сервисами: GraphQL может агрегировать данные из микросервисов.
Пример с DataLoader для оптимизации:
Сначала добавь зависимость graphql-java-tools.
Затем в конфигурации:
@Bean
public DataLoaderRegistry dataLoaderRegistry(BookRepository bookRepo) {
DataLoaderRegistry registry = new DataLoaderRegistry();
registry.register("authorLoader", DataLoader.newDataLoader((List<Long> authorIds) ->
CompletableFuture.supplyAsync(() -> bookRepo.findAuthorsByIds(authorIds)))); // Batch-запрос
return registry;
}
В резолвере используй контекст для загрузки.
Это делает систему масштабируемой.
#Java #middle #on_request #GraphQL
🔥3👍1