Что необходимо соблюдать, чтобы сервисы ответили одинаково при их масштабировании

Гарантирование идентичного поведения при масштабировании сервисов

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

1. Stateless архитектура

Первое и самое важное правило: сервис должен быть stateless (без состояния).

// ПЛОХО: состояние внутри сервиса
@Service
public class UserService {
    private Map<Long, User> cache = new HashMap<>();  // Состояние!
    
    public User getUser(Long id) {
        // Разные инстансы имеют разный кэш
        return cache.computeIfAbsent(id, this::fetchFromDB);
    }
}

// ХОРОШО: стателесс
@Service
public class UserService {
    private final UserRepository repository;
    private final RedisCache cache;  // Общий кэш для всех инстансов
    
    public User getUser(Long id) {
        return cache.getOrElse(id, () -> repository.findById(id).orElseThrow());
    }
}

Проблема stateful сервисов:

• Request #1 приходит на инстанс A, он кэширует значение X
• Request #2 приходит на инстанс B, у него нет кэша, он получает Y
• Разные ответы на одинаковые запросы

2. Централизованное хранилище состояния

Если состояние необходимо, оно должно храниться вне приложения — в централизованном месте, доступном всем инстансам:

// Правильно: используем внешний кэш
@Service
public class OrderService {
    private final RedisTemplate<String, Order> redisTemplate;
    private final OrderRepository orderRepository;
    
    public Order getOrder(Long id) {
        String key = "order:" + id;
        Order cached = redisTemplate.opsForValue().get(key);
        
        if (cached != null) {
            return cached;
        }
        
        Order order = orderRepository.findById(id).orElseThrow();
        redisTemplate.opsForValue().set(key, order, Duration.ofHours(1));
        return order;
    }
}

// Правильно: используем БД как источник истины
@Service
public class SessionService {
    private final SessionRepository sessionRepository;  // Основано на БД
    
    public Session getSession(String sessionId) {
        return sessionRepository.findById(sessionId).orElseThrow();
    }
}

3. Идемпотентность операций

Опера должна быть идемпотентной — выполняться 1 раз или 100 раз дать одинаковый результат.

// ПЛОХО: не идемпотентно
@PostMapping("/accounts/{id}/deposit")
public void deposit(@PathVariable Long id, @RequestParam BigDecimal amount) {
    Account account = accountRepository.findById(id).orElseThrow();
    account.setBalance(account.getBalance().add(amount));  // Каждый раз добавляет!
    accountRepository.save(account);
}

// ХОРОШО: идемпотентно, используем уникальный ключ
@PostMapping("/accounts/{id}/deposit")
public void deposit(
    @PathVariable Long id,
    @RequestParam BigDecimal amount,
    @RequestHeader("Idempotency-Key") String idempotencyKey  // Уникальный ID запроса
) {
    // Проверяем, был ли уже такой запрос
    Optional<Transaction> existing = transactionRepository.findByIdempotencyKey(idempotencyKey);
    if (existing.isPresent()) {
        return existing.get();  // Возвращаем результат старого запроса
    }
    
    Account account = accountRepository.findById(id).orElseThrow();
    account.setBalance(account.getBalance().add(amount));
    accountRepository.save(account);
    
    Transaction transaction = new Transaction(idempotencyKey, id, amount);
    transactionRepository.save(transaction);
}

4. Согласованность данных через распределённые транзакции

В микросервисной архитектуре одного сервиса может быть недостаточно. Используй Saga Pattern:

// Сага для перевода денег между счётами
@Service
public class TransferSaga implements Saga {
    @Transactional
    public void transferMoney(Long fromId, Long toId, BigDecimal amount) {
        try {
            // Шаг 1: дебет со счёта
            accountService.debit(fromId, amount);
            
            // Шаг 2: кредит на счёт
            accountService.credit(toId, amount);
            
        } catch (Exception e) {
            // Откат: возврат денег
            accountService.credit(fromId, amount);
            throw new TransferFailedException(e);
        }
    }
}

5. Настройка балансировщика нагрузки

Балансировщик должен распределять трафик справедливо между инстансами:

# nginx.conf
upstream backend {
    least_conn;  # Метод выбора (least_conn, round_robin, ip_hash)
    server app1:8080 weight=1;
    server app2:8080 weight=1;
    server app3:8080 weight=1;
    
    # Проверка здоровья инстанса
    server app4:8080 down;  # Этот инстанс отключен
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

6. Версионирование API

При обновлении сервиса версии инстансов могут различаться. Используй версионирование:

// API версии
@RestController
@RequestMapping("/api/v1/users")
public class UserControllerV1 {
    @GetMapping("/{id}")
    public UserDtoV1 getUser(@PathVariable Long id) {
        // Старый формат ответа
    }
}

@RestController
@RequestMapping("/api/v2/users")
public class UserControllerV2 {
    @GetMapping("/{id}")
    public UserDtoV2 getUser(@PathVariable Long id) {
        // Новый формат ответа с доп. полями
    }
}

7. Конфигурация через Environment Variables

Все инстансы должны получать конфигурацию из одного источника:

@Configuration
@ConfigurationProperties(prefix = "app")
public class AppConfig {
    private String database;
    private String cacheHost;
    private int maxConnections;
    
    // Getters/Setters
}

// application.yml или Environment Variables
// ВСЕМ инстансам одинаковая конфигурация!
app:
  database: jdbc:postgresql://postgres-prod:5432/mydb
  cache-host: redis-prod:6379
  max-connections: 100

8. Логирование и трассировка

Для отладки должна быть полная видимость поведения всех инстансов:

@Service
public class UserService {
    private static final Logger logger = LoggerFactory.getLogger(UserService.class);
    
    public User getUser(Long id) {
        logger.info("Fetching user with id={}, hostname={}", id, getHostname());
        // ...
        logger.info("User fetched successfully, userId={}, hostname={}", user.getId(), getHostname());
    }
    
    private String getHostname() {
        return System.getenv().getOrDefault("HOSTNAME", "unknown");
    }
}

9. Graceful Shutdown

При масштабировании инстансы могут отключаться. Важно корректно завершить работу:

@SpringBootApplication
public class Application {
    @Bean
    public GracefulShutdown gracefulShutdown() {
        return new GracefulShutdown();
    }
}

@Component
public class GracefulShutdown {
    @PreDestroy
    public void onShutdown() throws InterruptedException {
        logger.info("Graceful shutdown initiated");
        // Перестаём принимать новые запросы
        // Даём существующим запросам время завершиться (max 30 сек)
        Thread.sleep(30_000);
        logger.info("Graceful shutdown complete");
    }
}

10. Sticky Sessions vs. Stateless

Если состояние всё же есть, можно использовать sticky sessions (но это антипаттерн):

# nginx.conf - стикие сессии (НЕ рекомендуется)
upstream backend {
    ip_hash;  # Один клиент всегда идёт на один инстанс
    server app1:8080;
    server app2:8080;
    server app3:8080;
}

Проблемы стикых сессий:

• Когда инстанс упадёт, клиент потеряет всю сессию
• Неравномерное распределение нагрузки (один клиент всегда на одном сервере)
• Сложно масштабировать

Чеклист для масштабирования

✓ Сервис полностью stateless
✓ Все состояния в Redis/БД
✓ API идемпотентны
✓ Одинаковая конфигурация для всех инстансов
✓ Балансировщик нагрузки настроен
✓ Версионирование API реализовано
✓ Логирование с информацией о хосте
✓ Health checks работают
✓ Graceful shutdown реализован
✓ Тесты нагрузки пройдены

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