🎛 Конфигурация Spring Boot: YAML, Профили и Секреты

Хардкодить настройки (порты, пароли, URL-ы) в Java-коде - это моветон. Если вам нужно поменять порт сервера, вы не должны перекомпилировать приложение.

Spring Boot следует принципу: "Код отдельно, настройки отдельно".

1️⃣ Properties vs YAML

По умолчанию Spring создает application.properties. Это старый формат (ключ=значение).
Весь мир переходит на YAML (.yaml или .yml). Он читабельнее и поддерживает иерархию.

Было (.properties):

spring.datasource.url=jdbc:postgresql://localhost/db
spring.datasource.username=admin
server.port=8080

Стало (.yaml):

server:
  port: 8080
spring:
  datasource:
    url: jdbc:postgresql://localhost/db
    username: admin

Меньше дублирования, глазам приятнее.

2️⃣ Как достать настройки в коде?

Способ А: Простой (@Value)
Подходит для точечных настроек.

@Value("${server.port}")
private int port;

Способ Б: Профессиональный (@ConfigurationProperties)
Если настроек много (например, настройки почты или API), лучше собрать их в отдельный класс. Это дает типизацию и проверку данных!

@ConfigurationProperties(prefix = "mail")
public record MailConfig(String host, int port, String username) {}

Теперь вы просто внедряете MailConfig в свои сервисы, как обычный бин.

3️⃣ Профили (Profiles) - Киллер-фича

На локальной машине у вас H2 база данных, а на продакшене - PostgreSQL. Как не менять конфиги вручную?
Используйте Профили.

Вы создаете несколько файлов рядом с основным application.yaml:

🔴application-dev.yaml (для разработки)
🔴application-prod.yaml (для боевого сервера)

В основном файле вы указываете, какой профиль активен по умолчанию:

spring:
  profiles:
    active: dev # По умолчанию грузим dev-настройки

А при запуске на сервере вы просто передаете флаг, и Spring подхватит нужный файл, перетерев дефолтные настройки:
java -jar app.jar -Dspring.profiles.active=prod

4️⃣ Секреты (Никаких паролей в Git!)

Самая страшная ошибка - закоммитить application-prod.yaml с паролем от боевой БД в репозиторий. ☠️

Правило: В файлах храним только дефолтные/безопасные значения. Реальные пароли передаем через Переменные Окружения (Environment Variables).

Spring Boot имеет строгий приоритет загрузки. Переменные окружения OS имеют более высокий приоритет, чем файлы.

🔴В файле: spring.datasource.password=secret
🔴В переменной ОС: SPRING_DATASOURCE_PASSWORD=SuperSecurePass123

Spring увидит переменную в системе и проигнорирует то, что написано в файле. Ваш секрет в безопасности.

🔥 Итог

1. Используйте YAML вместо properties.
2. Группируйте настройки через @ConfigurationProperties.
3. Разделяйте среды через Профили (dev, test, prod).
4. Никогда не храните боевые пароли в файлах. Используйте ENV vars.

#SpringBoot #Configuration #YAML #DevOps #BestPractices

📲 Мы в MAX

👉@BookJava

🚀 CI/CD: Роботы делают рутину за вас

Аббревиатура состоит из двух частей, и они решают разные проблемы.

🛠 1. CI (Continuous Integration / Непрерывная интеграция)

Суть: Разработчики постоянно (несколько раз в день) сливают свой код в общую ветку (например, main или develop).
Каждый раз, когда вы делаете git push, специальный сервер (GitLab CI, GitHub Actions, Jenkins) автоматически:

1. Скачивает ваш свежий код.
2. Собирает проект (mvn clean compile).
3. Запускает все Unit и Integration тесты.

Если хоть один тест упал - сборка помечается красным крестиком (Build Failed). Код не пройдет дальше.
Итог: Ваша главная ветка в Git всегда находится в рабочем состоянии.

📦 2. CD (Continuous Delivery & Deployment)

Здесь две буквы "D", и они немного отличаются:

🔴Continuous Delivery (Доставка): Код автоматически собирается в готовый артефакт (например, Docker-образ) и кладется в хранилище. Нажать кнопку "Опубликовать на Production" должен человек (например, тимлид).

🔴Continuous Deployment (Развертывание): Полная автоматизация. Прошли тесты? Собрался образ? Он сразу же автоматически загружается на боевой сервер и заменяет старую версию. (Так делает Amazon, выкатывая обновления тысячи раз в день).

⚙️ Анатомия Пайплайна (Pipeline)

Пайплайн - это скрипт, состоящий из шагов (Stages), которые выполняются строго друг за другом. Упал предыдущий - следующий не запустится.

Типичный пайплайн для Spring Boot + Docker:

1. Lint (Проверка стиля кода, нет ли неиспользуемых импортов).
2. Test (Запуск JUnit тестов).
3. Build (Сборка `app.jar`).
4. Dockerize (Сборка Docker-образа и отправка его в Docker Registry).
5. Deploy (Команда серверу: "Скачай новый образ и перезапустись").

💻 Как это выглядит в коде? (GitHub Actions)

Вам не нужно кликать мышкой в интерфейсах. Пайплайн описывается кодом (YAML) и лежит прямо в вашем репозитории (подход Infrastructure as Code).

Вот пример простого .github/workflows/build.yml для Java-проекта:

name: Spring Boot CI/CD

on:
  push:
    branches: [ "main" ] # Запускать только при пуше в main

jobs:
  build-and-test:
    runs-on: ubuntu-latest # Выделяем виртуальную машину Linux
    
    steps:
    - uses: actions/checkout@v3 # 1. Скачиваем код из Git
    
    - name: Установка Java 17
      uses: actions/setup-java@v3
      with:
        java-version: '17'
        distribution: 'temurin'
        
    - name: Сборка и Тесты (Maven) # 2. Запускаем тесты и сборку
      run: ./mvnw clean package
      
    # Дальше могут быть шаги для сборки Docker и деплоя...

Стоит вам сделать git push, и GitHub сам поднимет сервер, выполнит эти команды и пришлет вам письмо, если что-то сломалось.

🆚 Что выбрать?

🔴Jenkins: "Дед" в мире CI/CD. Мощный, гибкий, но сложный в настройке (нужно поднимать свой сервер). Написан на Java.

🔴GitLab CI: Стандарт индустрии корпоративного сектора. Очень удобен, так как встроен прямо в репозиторий кода.

🔴GitHub Actions: Современный, быстрый, идеален для Open Source и проектов, уже живущих в GitHub.

🔥 Итог

CI/CD убивает фактор "человеческой ошибки". Вы перестаете бояться релизов. Деплой новой фичи превращается из стрессового события в пятницу вечером в скучную рутину: сделал пуш подождал 5 минут фича на проде.

#DevOps #CICD #Java #SpringBoot #GitHubActions

📲 Мы в MAX

👉@BookJava

📊 Мониторинг: Пульс вашего приложения

В мире мониторинга 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

🕸️ 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