Обновление службы Service Fabric, которая не учитывает токен отмены

Это невозможно для службы с отслеживанием состояния, использующей инфраструктуру Service Fabric, вам потребуется время простоя при обновлении. Если у вас есть версия, поддерживающая токен отмены, все будет в порядке.

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

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

Всегда есть некоторое время простоя, даже при полностью непрерывных обновлениях, поскольку переключение основного узла на другой никогда не происходит мгновенно, и вызывающим абонентам необходимо обнаружить новое местоположение. С помощью этих команд вы просто преобразуете более плавное завершение работы и очистку в отказ, что приводит к тому же основному свопу. Не должно быть большой разницы, поскольку клиенты (и SF) в любом случае должны нормально справляться с ошибками.

Я бы продолжал использовать эти команды, поскольку они дают вам хороший ручной контроль над тем, какие реплики / процессы нужно тыкать, когда что-то застревает.