Пользовательский сценарий последовательно вызывает пять сервисов, доступность каждого 99,9%. Какова примерная доступность сценария и что из этого следует?
- Как считается доступность цепочки сервисов?
- Почему синхронные цепочки снижают надёжность?
В синхронной цепочке доступности перемножаются: 0,999⁵ ≈ 0,995. Простой вырастает впятеро — с ~43 минут до ~3,6 часа в месяц.
- Задержки складываются, а хвостовые задержки ещё и усиливаются
- Лечат пересмотром границ (сценарий — в одном сервисе) и асинхронностью там, где ответ не нужен сразу
- Таймауты, повторы, circuit breaker и bulkhead ограничивают ущерб, но не устраняют причину
А ещё Параллельные вызовы с запасным ответом и кэшированием не перемножают доступность
Подробно
Если запрос успешен, только когда успешны все пять сервисов, вероятность успеха — произведение: 0,999 × 0,999 × 0,999 × 0,999 × 0,999 ≈ 0,995. Для месяца (≈ 43 200 минут) это ~216 минут недоступности против ~43 у одного сервиса. С двадцатью зависимостями — 0,98, уже 14 часов.
Что ещё ухудшается:
- задержка — сумма задержек цепочки, а p99 цепочки хуже p99 каждого звена;
- каскадные отказы — медленный нижний сервис занимает потоки всех верхних;
- повторы на каждом уровне умножают нагрузку при сбое.
Что делать:
- пересмотреть границы — чтобы основной сценарий выполнялся в одном сервисе с его собственными данными;
- асинхронность — то, что не нужно для ответа пользователю (уведомления, начисление бонусов, аналитика), выполнять по событию;
- локальные копии данных чужих сервисов через события вместо запроса на каждый вызов;
- деградация — необязательные зависимости вызывать с таймаутом и запасным ответом (без рекомендаций страница всё равно открывается);
- защитные механизмы — таймауты, повторы с джиттером, circuit breaker, bulkhead.
Пример
одна зависимость 99,9% → простой ≈ 43 мин/мес
цепочка из 5 → 0,999^5 ≈ 99,5% → ≈ 3,6 ч/мес
цепочка из 20 → 0,999^20 ≈ 98,0% → ≈ 14 ч/месЧто хотят услышать
- Расчёт: перемножение доступностей и перевод в минуты простоя.
- Сложение задержек и каскадные отказы.
- Главное лечение — границы и асинхронность, защитные механизмы — вторично.
Частые ошибки
- Считать, что доступность цепочки равна доступности самого слабого звена.
- Надеяться, что повторы «вернут» доступность.
Проверьте себя
Один верный вариант. Подумайте, потом откройте ответ.
Показать варианты и ответ
- ✓Около 99,5%: доступности перемножаются, синхронные цепочки надо укорачивать
- ✗99,9% — доступность определяется самым надёжным звеном
- ✗99,98% — избыточность сервисов повышает общую доступность
- ✗Не зависит от числа звеньев, если настроены таймауты
Что спросят дальше
- Как асинхронное взаимодействие меняет эту арифметику?
- Что такое bulkhead и от чего он защищает?
Разбор темы
- Монолит, микросервисы и границы сервисов
Когда микросервисы оправданы, а когда вредны; bounded context и DDD как способ резать систему; распределённый монолит и его признаки; база на сервис и организационная цена.
Связанные вопросы
- Какие признаки указывают на распределённый монолит? Middle
- Как правильно настраивать таймауты и повторы запросов? Middle
- Почему время ответа измеряют перцентилями, а не средним? Middle
- Внешний платёжный провайдер начал отвечать за 30 секунд вместо 200 миллисекунд. Через минуту сервис перестал отвечать вообще, включая страницы, не связанные с оплатой. Что произошло? Middle
Разбор собеседования с sotto
После собеседования sotto разбирает разговор: оценка, каждый вопрос — хорошо, частично или слабо, чего не хватило в ответе и над чем поработать к следующему разу. Первые 30 минут бесплатно.