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

Шаблон — Тайм-ауты

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

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

Время ожидания подключения — время, необходимое для открытия сетевого подключения к серверу

Время ожидания запроса — время, необходимое серверу для обработки запроса

Тайм-аут запроса почти всегда будет самым длинным из двух, и я рекомендую, чтобы тайм-аут определялся в конфигурации службы. Хотя изначально вы можете установить произвольное значение, скажем, 10 секунд, вы можете изменить его после того, как система заработает в производственной среде, и у вас будет приличный набор данных о времени транзакций для просмотра.

Шаблон — Отступить

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

Использование этой стратегии внутри API, вызываемого клиентом, может быть нежелательным, поскольку это противоречит требованию быстрого отказа. Однако, если у нас есть рабочий процесс, который обрабатывает только очередь сообщений, то это может быть как раз правильной стратегией для добавления небольшой защиты вашей системе.

Шаблон — разрыв цепи

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

Давайте рассмотрим пример веб-приложения внешнего интерфейса, которое зависит от нижестоящей службы для предоставления рекомендаций по службам, которые может использовать пользователь. Поскольку этот вызов синхронен с загрузкой главной страницы, веб-сервер не будет возвращать данные до тех пор, пока он не вернет рекомендации. Теперь вы рассчитаны на отказ и ввели тайм-аут в пять секунд для этого вызова. Однако, поскольку существует проблема с системой рекомендаций, вызов, который обычно занимает 20 миллисекунд, теперь завершается ошибкой за 5000 миллисекунд. Каждый пользователь, который просматривает сервисы, ждет на пять секунд дольше, чем обычно; ваше приложение не обрабатывает запросы и не высвобождает ресурсы так быстро, как обычно, и его производительность значительно снижается. В дополнение к этому количество одновременных подключений к основному веб-сайту увеличилось из-за времени, которое требуется для обработки запроса одной страницы; это добавляет нагрузку на переднюю часть, которая начинает замедляться. Конечным результатом будет то, что если служба рекомендаций не начнет отвечать, то весь сайт перестанет работать.

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

– вы восстанавливаете возможности просмотра для других пользователей на сайте.

– Вы немного ухудшаете работу в одной области.

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

В данном случае это должна быть относительно простая продажа. Предположим, что рекомендации повышают конверсию на 1%; однако медленная загрузка страниц снижает его на 90%. Тогда не лучше ли деградировать на 1% вместо 90%? Этот пример ясен, но что, если нижестоящим сервисом была система проверки запасов; следует ли принимать заказ, если есть вероятность, что у вас нет запасов для его выполнения?

Как это будет работать?

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

Поведение при ошибках — это не вопрос, на который инженеры-программисты могут ответить сами по себе; заинтересованные стороны бизнеса должны быть вовлечены в это решение. Когда вы планируете дизайн своих систем, вы говорите об отказе как о части ваших нефункциональных требований и заранее решаете, что вы будете делать в случае сбоя нижестоящего сервиса.

Посмотрите еще несколько шаблонов микросервисовПознакомьтесь с микросервисами № 4 — еще несколько шаблонов для изучения!