То есть, по-русски это звучит примерно следующим образом:
На вершине диапазона навыков преимущество у защитников от раша. Но с другой стороны диапазона навыков преимущество у атакующего, потому что раш легко провести и сложно остановить.
Attacker != противник easy to execute and harder to stop != начать пользоваться и сложнее прекратить (наркоман, что ли?)
Несколько секунд, а тем более 20, это довольно значительное время даже по меркам http-запросов.
Я привёл выше ошибки с eventually consistency, когда информация, нужная для запроса, еще не успела записаться в БД. Ошибки блокировки записей в БД.
И не забывайте, что речь идёт не только о взаимодействии пользователя с системой, а о распределенной системе, где сервисы взаимодействуют между собой в том числе через http-запросы. Если Вы думаете, что в интернет-магазине весь процесс заканчивается, после того, как пользователь нажал на кнопку «Заказать», то Вы сильно ошибаетесь.
Все описанные подходы по сути решают проблему с транзиентными ошибками, то есть, мы считаем, что это не бизнес-ошибка, что это временный сбой системы, который с течением времени исправится.
Сделать последствия таких сбоев менее заметными и не усугубить ситуацию — для этого и используются все эти политики.
Ну и, в дополнение, существует еще ряд несистемных транзиентных ошибок, которые могут быть заложены бизнес-логикой приложения. Например, eventually consistency или optimistic concurrency в принципе используют такой дизайн, что ошибки (а с ними и ретраи) будут неизбежны.
В баскетболе, если игрок физически препятствует другому игроку, судья (рефери) фиксирует нарушение (фол), а игрок, совершивший фол, получает штрафной бросок. Соперники верили скорее в то, что Шак пропустит штрафной бросок, чем в то, что его команда отдаст мяч.
Игрок, на ком совершили фол, получает штрафной бросок. И как можно «пропустить» штрафной бросок в баскетболе?
Первой была шуточная игра: «камень-бумага-ножницы-ящерица-Спок».
Первый раз слышу, чтобы «бумага» шла перед «ножницами».
На вершине диапазона навыков преимущества остаются именно у защитников от раша. С другой стороны диапазона навыков эти преимущества достаются противникам, так как рашем легко начать пользоваться, но сложнее прекратить.
Какие противники? О чём вообще речь в этом фрагменте?
Это то, что я пытался описать в решениях 3 и 4. Возможно, не так структурировано, как у Вас. И тут всегда остаётся вопрос, что есть «долго запускающийся» сервис. Получение секретов из внешнего хранилища — это долго или нет? По мнению тех, кто писал получение из Azure KeyVault, недолго, раз можно обойтись без healthcheck в этом случае.
По первому пункту — какой-то принципиальной практической разницы действительно нет, это сугубо вопрос организации кода. Опять же, жили без асинхронного Main(), с ним особо ничего не поменялось, кроме организации кода.
Про балансировщики — признаюсь, я не очень глубоко копал этот вопрос. Но выглядит так, как будто помимо настройки самого балансировщика необходимо будет настроить и сервис, чтобы весь механизм healthcheck/readiness/startup заработал.
В точку! Я бы даже обобщил. Это моё сугубо личное мнение, основанное не то чтобы на очень богатом опыте использования, но по факту весь фреймворк ASP.NET — он как раз про организацию кода. А я всегда за то, чтобы код был организован единообразно.
Можете использовать этот подход вполне. А можете один из тех четырех, что описаны в статье. А можете вариант из первого комментария.
Мне вот лично не нравится вызывать асинхронный код в синхронном, если этого можно не делать. Какой-то принципиальной выгоды этот подход не даёт.
Посмотрел внимательнее. Похоже, Вы правы. Что-то я не дожал этот вопрос. Что ж, я завтра еще раз перепроверю, и если всё так, то выкину этот кусок кода) Спасибо!
Что, надеюсь, не отменяет полезности оставшейся части статьи)
Нет, не кэширует. Перед тем, как написать этот код, я специально разбирался, как работает хендлер. Не только читал код, но и дебажил.
Вся суть в том, что JwtBearerHandler региструется транзиентно, поэтому вот это условие при каждом вызове возвращает true, и конфигурация читается заново.
Да, Ваш вариант тоже можно добавить в копилку. Отдельное спасибо за ссылку на гитхаб. Собственно, основная мысль, которая побудила меня написать статью, что до тех пор, пока у нас не появится официального async Startup, мы все будем вынуждены придумывать свои более или менее очевидные решения.
Да, на ASP.NET Core. Пока не выложили, потому что там секреты и доступы к БД прописаны. Наверное, можем создать отдельный репозиторий и залить туда финальный код без конфиденциальной инфы и истории коммитов) Ceridan, что думаешь?
Да, было два выигрыша с точки зрения написания кода:
1. Удобно было писать «вложенные» асинхронные действия с помощью стандартного механизма async/await.
2. Внутри некоторых вызовов были сетевые запросы. Я вообще не думал, можно ли их описать корутинами, но хотелось их встроить в общий «пайплайн».
Изначально я вообще всё написал на «голом» async/await, но у него внезапно вылезли проблемы на iOS-устройствах. Скорее всего, там некорректно отрабатывает await Task.Delay(...), когда задержка занимает небольшое время.
В своих предыдущих проектах я использовал корутины, в этот раз попробовал UnitRx, и с ним реально как-то проще.
На вершине диапазона навыков преимущество у защитников от раша. Но с другой стороны диапазона навыков преимущество у атакующего, потому что раш легко провести и сложно остановить.
Attacker != противник
easy to execute and harder to stop != начать пользоваться и сложнее прекратить (наркоман, что ли?)
То есть, полное искажение смысла переводчиком.
Простейший пример — сеть моргнула.
Я привёл выше ошибки с eventually consistency, когда информация, нужная для запроса, еще не успела записаться в БД. Ошибки блокировки записей в БД.
И не забывайте, что речь идёт не только о взаимодействии пользователя с системой, а о распределенной системе, где сервисы взаимодействуют между собой в том числе через http-запросы. Если Вы думаете, что в интернет-магазине весь процесс заканчивается, после того, как пользователь нажал на кнопку «Заказать», то Вы сильно ошибаетесь.
Сделать последствия таких сбоев менее заметными и не усугубить ситуацию — для этого и используются все эти политики.
Ну и, в дополнение, существует еще ряд несистемных транзиентных ошибок, которые могут быть заложены бизнес-логикой приложения. Например, eventually consistency или optimistic concurrency в принципе используют такой дизайн, что ошибки (а с ними и ретраи) будут неизбежны.
Игрок, на ком совершили фол, получает штрафной бросок. И как можно «пропустить» штрафной бросок в баскетболе?
Первый раз слышу, чтобы «бумага» шла перед «ножницами».
Какие противники? О чём вообще речь в этом фрагменте?
GetAwaiter().GetResult() возвращает осмысленный Exception, в то время как просто Result возвращает AggregateException.
Про балансировщики — признаюсь, я не очень глубоко копал этот вопрос. Но выглядит так, как будто помимо настройки самого балансировщика необходимо будет настроить и сервис, чтобы весь механизм healthcheck/readiness/startup заработал.
Мне вот лично не нравится вызывать асинхронный код в синхронном, если этого можно не делать. Какой-то принципиальной выгоды этот подход не даёт.
Вот, скажу нашим сочинителям заголовков, что они должны быть не только завлекательными, но и не вводящими в заблуждение!
Что, надеюсь, не отменяет полезности оставшейся части статьи)
Вся суть в том, что JwtBearerHandler региструется транзиентно, поэтому вот это условие при каждом вызове возвращает true, и конфигурация читается заново.
Да, на ASP.NET Core. Пока не выложили, потому что там секреты и доступы к БД прописаны. Наверное, можем создать отдельный репозиторий и залить туда финальный код без конфиденциальной инфы и истории коммитов) Ceridan, что думаешь?
1. Удобно было писать «вложенные» асинхронные действия с помощью стандартного механизма async/await.
2. Внутри некоторых вызовов были сетевые запросы. Я вообще не думал, можно ли их описать корутинами, но хотелось их встроить в общий «пайплайн».
Изначально я вообще всё написал на «голом» async/await, но у него внезапно вылезли проблемы на iOS-устройствах. Скорее всего, там некорректно отрабатывает
await Task.Delay(...), когда задержка занимает небольшое время.В своих предыдущих проектах я использовал корутины, в этот раз попробовал UnitRx, и с ним реально как-то проще.