Представьте ситуацию: единое тестовое окружение, в котором работает более 300 микросервисов, нагрузка свыше 300 RPS на сервис, и этим окружением пользуются все — от разработчиков до аналитиков.

Задача: нам нужны моки для негативных сценариев, ускорения текущих автотестов и стабилизации сервисов, но нельзя просто взять и замокать сервисы, ведь остальным нужно ходить в реальные сервисы.

Мы выбрали Wiremock, который может быть не только мок-сервером, но и прокси. Однако оказалось все не так просто — Wiremock начал падать даже при нагрузке в 100 RPS, Kubernetes перезапускал поды, а один из багов Kubernetes и вовсе сломал мастер-ноду.

Всё это мало напоминало успех, но в результате — после множества экспериментов и расследований — мне удалось разобраться в причинах. После исправлений всех проблем и аппрува от создателя Wiremock — производительность Wiremock выросла в десятки раз, он стал выдерживать нагрузку более 1000 RPS. Чтобы узнать, как мы с этим справились, с какими проблемами столкнулись и как мы их решали, приходите на мой доклад. Будет интересно и поучительно!