Расскажите про опыт настройки Spring Cloud компонентов, таких как Config Server и Circuit Breaker

Что проверяют

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

Как отвечать

Про Config Server расскажите цепочку.

• Хранилище конфигурации: git-репозиторий, разделение по приложениям, профилям и веткам.
• Подключение клиента через spring.config.import и поведение при недоступном сервере: падать сразу с повторами или стартовать на локальных значениях. Это решение принимают осознанно, а не по умолчанию.
• Обновление без перезапуска: @RefreshScope и вызов через actuator, рассылка события на все экземпляры через шину.
• Секреты: шифрование значений средствами конфигурационного сервера или отдельное хранилище, пароли в открытом виде в репозитории не лежат.

Про предохранитель говорите через настройки и поведение: Resilience4j, размер скользящего окна, порог доли ошибок, время в открытом состоянии, пробные вызовы в полуоткрытом. Рядом обязательно таймаут и ограничение числа одновременных вызовов, а также осмысленный запасной ответ: данные из кэша, частичная выдача, понятная ошибка вместо тишины.

Где спотыкаются

Рассказывают про Hystrix как про текущий выбор. Он давно не развивается, в новых проектах берут Resilience4j, а Spring Cloud работает через общую абстракцию предохранителя. Такой ответ сразу выдаёт опыт, собранный по старым статьям.

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

Ждут, что @RefreshScope обновит вообще всё. Перечитываются только помеченные бины, значение, попавшее в синглтон при старте, останется старым, а часть инфраструктуры, вроде пула соединений к базе, так на лету не меняется.