💹 Сверхустойчивость: как мы учились работать в режиме «минус один дата-центр» Всем привет, это Алексей Терентьев, я руковожу одной из служб отдела эффективности Яндекс Go. Недавно перед нами поставили амбициозную цель: так оптимизировать ресурсы, чтобы бесперебойно работать при стопроцентной нагрузке серверов, учитывая, что у нас осталось только два из трёх дата-центров. Для начала мы решили понять, с чем столкнулись. Аудит кодовой базы подсветил болячки, которые давно копились под капотом у наших сервисов. ❇️ Первая проблема — некритичные зависимости с фатальными последствиями Вот, например: сердце нашего продукта — обработка заказов такси — синхронно ждёт ответа от сервиса, который отправляет чеки. Если тот прилёг из-за ошибки в релизе, то основной бизнес-процесс тоже останавливается. ☠️ Эта беда осложняется разными багами. Например, в ответе основного сервиса было поле optional_data, которое обогащали данными из десятка других мест. Одно из них упало, а код не был готов к null. В итоге падал весь конвейер. В нашем случае код был на C++ (std::optional), и разыменование nullptr приводило к core dump. Процесс опять мгновенно останавливался. Это как если бы двигатель машины заглох, потому что в бардачке перегорела лампочка. Абсурдно, но в мире микросервисов такое происходит сплошь и рядом. Поэтому нам нужно было изолировать критичные места от всего, что не нужно для их базовой работы. ❇️ Вторая проблема — поллинг Предположим, что для отрисовки баллов Плюса на экране заказов Такси мы периодически ходим в сервис пользовательской статистики, который отправляет запросы в Яндекс Плюс. А чтобы данные не протухали, ему нужно делать это регулярно, например раз в пять секунд. Теперь умножаем эту цифру на количество активных пользователей. Получается шквал запросов, 99,9% которых приносят один и тот же ответ, ведь баланс баллов меняется от силы пару раз в день. С учётом того, что подобных параметров может быть много, это создаёт серьёзную холостую нагрузку на бэкенд. 🔶 Очевидно, обе эти проблемы можно исправить, если внедрить событийную модель. Но дьявол, как всегда, кроется в деталях. Подробнее о них я рассказываю в статье на Хабре. Она будет интересна разработчикам, которые занимаются микросервисной архитектурой и думают об оптимизации своих продуктов. Подписывайтесь: 💬 @Yandex4Backend 📹 @YandexforBackend