Хочу с Вами поделиться примером, как гибко настроить HTTP клиент.
Под гибкостью я имею ввиду возможность настроить поведение каждого конкретного исходящего HTTP запроса.
Например если стандартным способом подключить Polly политики Retry/Timeout/CircuitBreaker, то они будут применяться для всех исходящих HTTP запросов этого клиента.
Часто хочется настроить разные таймауты для запросов да и не все запросы безопасно ретраить.
Можно обойти проблему настроив фильтр, чтобы только для GET запросов включались ретраи или только для определенных URI.
Это будет работать, но согласитесь, что это не самое красивое решение, потому что знание о URI будет в двух местах, а значит есть риск забыть об этом при их изменении.
Можно настроить несколько именованных HTTP клиентов под каждый сценарий. Но помимо добавления к клиенту политик придется еще продублировать настройки базовых адресов, аутентификации и т.п.
А еще теряется эффективность пула HttpClientHandler и будет много разных логов связанных с именем клиента.
Еще нужно будет правильно расшарить CircuitBreaker чтобы они собирали общую статистику
В качестве решения проблемы предлагаю отдельно от клиента зарегистрировать политики и потом использовать ResiliencePipelineProvider для того получать нужную политику для конкретного запроса.
Естественно не хочется это тащить в саму реализацию клиента и оборачивать каждый запрос в Pipeline.Execute(() => ...)
Хорошо бы просто указать название политики и чтобы оно само вызвалось.
Вызов можно сделать в DelegatingHandler и он будет достаточно универсальным и подойдет всем HTTP клиентам.
Но остался вопрос - как передать название политики в него?
Это можно сделать через HttpRequestMessage.Options, но такой вариант плох по следующим причинам:
1. Придется везде создавать самим HttpRequestMessage чтобы прокинуть название политики в его Options и потом передать в HttpClient.SendAsync. Использовать готовые методы типа GetAsync не выйдет.
А если у Вас проект не новый, то еще и придется переписать HTTP вызовы.
2. Не всегда есть возможность внести эти изменения из пункта 1, если используются различные библиотечные или генерируемые HttpClient.
Поэтому самым гибким вариантом будет использование AsyncLocal.
Он является аналогом ThreadLocal. Только ThreadLocal позволяет в себя записать и считать данные только из одного и того же треда.
А AsyncLocal сохраняет доступ к данным в рамках асинхронного потока исполнения.
Самые популярные примеры использования AsyncLocal:
- IHttpClientAccessor
- System.Diagnostics.Activity
Сделаем тоже самое в виде класса OutgoingHttpRequestContext.
Он позволит создать контекст для запроса и записать в него любые данные в Properties.
Которые потом можно будет вычитать, в PipelineExecuteDelegatingHandler, получить нужный Pipeline и запустить его для запроса.
Помимо политик Polly, данный пример можно использовать и для любых других целей.
Например для кэширования, управления каким сервисным ключом аутентифироваться, собирать или не собирать кастомные метрики и в целом все что только можно придумать :)
Нюансы которые нужно учесть:
1. Оборачивайте контекст в using
Если у вас выполняется несколько HTTP запросов (подряд или вложенно), то скорее всего Вам захочется каждому из них назначить свой контекст
Для этого просто создавайте контекст непосредственно перед вызовом и оберните в using
При создании нового контекста предыдущий (родительский) контекст будет запомнен и восстановлен после dispose
Если так не сделать, может выполниться не тот пайплайн который вы хотели бы
2. Некоторые Polly политики, такие как RateLimiter, CircuitBreaker для своей работы ведут статистику запросов.
Если Вы для всех HTTP клиентов переиспользуете общую политику, то когда один из HTTP клиентов начнет получать 500ки и включит CircuitBreaker, все остальные тоже не смогут работать, так как политика подключена общая.
Поэтому нужно аккуратно настраивать политики и их переиспользование
3. Названия политик запишите в константы, чтобы избежать неприятной ситуации, когда политику назвали одним образом, а в контексте запроса указали другое название.
Под гибкостью я имею ввиду возможность настроить поведение каждого конкретного исходящего HTTP запроса.
Например если стандартным способом подключить Polly политики Retry/Timeout/CircuitBreaker, то они будут применяться для всех исходящих HTTP запросов этого клиента.
Часто хочется настроить разные таймауты для запросов да и не все запросы безопасно ретраить.
Можно обойти проблему настроив фильтр, чтобы только для GET запросов включались ретраи или только для определенных URI.
Это будет работать, но согласитесь, что это не самое красивое решение, потому что знание о URI будет в двух местах, а значит есть риск забыть об этом при их изменении.
Можно настроить несколько именованных HTTP клиентов под каждый сценарий. Но помимо добавления к клиенту политик придется еще продублировать настройки базовых адресов, аутентификации и т.п.
А еще теряется эффективность пула HttpClientHandler и будет много разных логов связанных с именем клиента.
Еще нужно будет правильно расшарить CircuitBreaker чтобы они собирали общую статистику
В качестве решения проблемы предлагаю отдельно от клиента зарегистрировать политики и потом использовать ResiliencePipelineProvider для того получать нужную политику для конкретного запроса.
Естественно не хочется это тащить в саму реализацию клиента и оборачивать каждый запрос в Pipeline.Execute(() => ...)
Хорошо бы просто указать название политики и чтобы оно само вызвалось.
Вызов можно сделать в DelegatingHandler и он будет достаточно универсальным и подойдет всем HTTP клиентам.
Но остался вопрос - как передать название политики в него?
Это можно сделать через HttpRequestMessage.Options, но такой вариант плох по следующим причинам:
1. Придется везде создавать самим HttpRequestMessage чтобы прокинуть название политики в его Options и потом передать в HttpClient.SendAsync. Использовать готовые методы типа GetAsync не выйдет.
А если у Вас проект не новый, то еще и придется переписать HTTP вызовы.
2. Не всегда есть возможность внести эти изменения из пункта 1, если используются различные библиотечные или генерируемые HttpClient.
Поэтому самым гибким вариантом будет использование AsyncLocal.
Он является аналогом ThreadLocal. Только ThreadLocal позволяет в себя записать и считать данные только из одного и того же треда.
А AsyncLocal сохраняет доступ к данным в рамках асинхронного потока исполнения.
Самые популярные примеры использования AsyncLocal:
- IHttpClientAccessor
- System.Diagnostics.Activity
Сделаем тоже самое в виде класса OutgoingHttpRequestContext.
Он позволит создать контекст для запроса и записать в него любые данные в Properties.
Которые потом можно будет вычитать, в PipelineExecuteDelegatingHandler, получить нужный Pipeline и запустить его для запроса.
Помимо политик Polly, данный пример можно использовать и для любых других целей.
Например для кэширования, управления каким сервисным ключом аутентифироваться, собирать или не собирать кастомные метрики и в целом все что только можно придумать :)
Нюансы которые нужно учесть:
1. Оборачивайте контекст в using
Если у вас выполняется несколько HTTP запросов (подряд или вложенно), то скорее всего Вам захочется каждому из них назначить свой контекст
Для этого просто создавайте контекст непосредственно перед вызовом и оберните в using
При создании нового контекста предыдущий (родительский) контекст будет запомнен и восстановлен после dispose
Если так не сделать, может выполниться не тот пайплайн который вы хотели бы
2. Некоторые Polly политики, такие как RateLimiter, CircuitBreaker для своей работы ведут статистику запросов.
Если Вы для всех HTTP клиентов переиспользуете общую политику, то когда один из HTTP клиентов начнет получать 500ки и включит CircuitBreaker, все остальные тоже не смогут работать, так как политика подключена общая.
Поэтому нужно аккуратно настраивать политики и их переиспользование
3. Названия политик запишите в константы, чтобы избежать неприятной ситуации, когда политику назвали одним образом, а в контексте запроса указали другое название.