#c# #.net #azure-functions #microsoft-graph-api #microsoft-graph-sdks
#c# #.net #azure-функции #microsoft-graph-api #microsoft-graph-sdks
Вопрос:
Я понимаю, что Graph SDK реализует обработчик повторных попыток по умолчанию, который может выполнить повторную попытку при возникновении 429. После прохождения класса RetryHandler.cs на GitHub я вижу, что каждый ответ проверяется на 429, и если есть ответ 429 (слишком много запросов), он использует заголовок Retry-After (если доступно) или экспоненциальный откат, чтобы определить время, на которое задача будет отложена.
На мой вопрос, пожалуйста, рассмотрите следующий сценарий:
- У меня есть функция Azure, которая использует поток учетных данных клиента
- Это может быть вызвано другим приложением (не пользователем)
- У меня есть клиент службы graph, который является статическим объектом и использует graph
- Один из запросов в конечном итоге регулируется (429), и выполнение задач откладывается
- Пока эта задача ожидает (откладывается), в приложение, которое использует тот же ресурс graph, поступают другие запросы
Вопрос: Будет ли клиент службы Graph, учитывая, что это тот же статический объект, а другая задача задерживается, снова отправлять запрос в Graph, не учитывая, что конечная точка регулируется?
Спасибо
Ответ №1:
Каждый запрос отправляется конечной точке graph независимо от текущих ожидающих регулируемых запросов или состояния регулируемой конечной точки (он не поддерживает какое-либо состояние по этому поводу). GraphClient по сути использует HttpClient, а RetryHandler — это просто обработчик делегирования http-клиента (концепция). Кроме того, что касается вашей точки зрения о статическом объекте, он не блокирует новые запросы, пока есть ожидающая повторная попытка предыдущего (вот где пригодится асинхронное планирование задач). Фактически HttpClient предназначен для создания экземпляра один раз и повторного использования на протяжении всего срока службы приложения. Создание экземпляра класса HttpClient для каждого запроса исчерпает количество сокетов, доступных при больших нагрузках. Это приведет к ошибкам SocketException.
Если служба начинает регулировать из-за чрезмерно большого объема запросов (через GraphAPI, предназначенный для большого объема), вам следует сначала рассмотреть возможность повторного просмотра вашего приложения, почему у вас такое большое количество вызовов Graph API из приложения. Если у вас есть возможность отправлять пакетные запросы в graph api, рассмотрите возможность использования этого. Проверьте руководство по регулированию Graph API https://learn.microsoft.com/en-us/graph/throttling. Даже после этого, если вы хотите обработать повторную попытку пользовательским способом, вы можете использовать Polly, который поддерживает прерывание цепи и переборкуhttps://github.com/App-vNext/Polly
Надеюсь, это отвечает на ваш вопрос. Если у вас есть дополнительные вопросы, пожалуйста, дайте мне знать.
Комментарии:
1. Поскольку состояние регулирования конечной точки не поддерживается, и если клиент продолжит отправлять запросы на график, не увеличит ли это время повторения ? Если это произойдет, первый запрос, который был отрегулирован, снова будет регулироваться при повторном выполнении после задержки в соответствии с заголовком retry-after. Хорошая ли идея убедиться, что другие (новые) запросы не отправляются на график, если конечная точка находится в регулируемом состоянии? Если да, должен ли я реализовать пользовательский обработчик повторных попыток?
2. @GMDev, я включил поясняющую часть в сам ответ. Пожалуйста, свяжитесь с нами, если у вас возникнут дополнительные вопросы.