статус кво
в распределенных сценариях. Если служба нестабильна, служба вызывающего абонента будет недоступна, что приведет к лавинному эффекту. Следовательно, необходимо выполнить обработку перехода на более раннюю версию предохранителя, когда исходная служба недоступна.
анализировать
Переход на более раннюю версию может ограничить ток сервера, лимит шлюза и лимит клиента.
1. Текущий лимит клиента: проверьте, достигнут ли порог при вызове метода для инициации запроса. Если порог достигнут, не инициировать запрос вызова
Преимущества: Вы можете напрямую управлять экспортом трафика на стороне потребителя услуги, уменьшая инициирование ненужных запросов.
Недостатки: Клиенту необходимо понимать показатели работы сервиса и правила аварийного восстановления. Каждая деловая сторона должна повторить разработку
2. Текущее ограничение на стороне сервера: поставщик услуг настраивает логику аварийного восстановления и после получения запроса решает, следует ли следовать резервной логике в соответствии с текущим состоянием.
Преимущества. Правила и пороговые значения устойчивости к стихийным бедствиям полностью инкапсулированы в поставщике услуг. Незаметно для звонящего.
Недостаток: если все поставщики услуг отключены, аварийное восстановление невозможно.
3. Текущий предел шлюза: Исходные запросы на прямой вызов провайдера перенаправляются прокси-сервером уровня шлюза. Логика конфигурации и понижения правил аварийного восстановления инкапсулирована на уровне шлюза.
Преимущества: клиентам и серверам не нужно понимать логику аварийного восстановления.
Недостатки: еще один сетевой запрос, rt становится больше
В большинстве случаев мы выбираем ограничение тока на стороне сервера. Но клиент сильно зависит от интерфейса платформы данных. Если приложение поиска зависает, клиенту все равно необходимо просмотреть данные. По сравнению с высокой доступностью небольшое увеличение rt допустимо, поэтому запустите шлюз аварийного восстановления данных.
Технический отбор
Существует две среды аварийного восстановления с открытым исходным кодом: hystrix и sentinel.
hystrix: Компонент понижения версии предохранителя, обычно используемый в springcloud. Основная функция — изоляция ресурсов и устранение сбоев между различными сервисами. Базовой реализацией является Rxjava. Он обеспечивает два режима изоляции ресурсов: изоляцию семафора и изоляцию пула потоков. Обычно используйте изоляцию пула потоков. Он потребляет определенное количество ресурсов, но, напротив, поддерживает тайм-ауты и асинхронное выполнение. Похоже, что он может охватывать большинство сценариев, но не поддерживает более требовательное управление потоком, например управление qps. Следовательно, для управления потоком необходимо использовать отдельное ведро маркеров с утечкой.
sentinel: Распределенный компонент управления трафиком Ali с открытым исходным кодом. Поддержка управления потоком, понижение рейтинга предохранителей, защита системы и т. д. Все ресурсы соответствуют имени ресурса и записи. При создании каждой записи также создается ряд подключаемых модулей (подключаемый модуль защиты системы: SystemSlot, подключаемый модуль управления потоком: FlowSlot, подключаемый модуль понижения версии Fuse LDegradeSlot и т. д.). Каждый плагин следит за метриками в своей зоне ответственности. NodeSelectorSlot хранит пути вызовов каждого ресурса в виде дерева для текущего ограничения и понижения. Вызывающий объект выполняет метод, создавая контекст и запрашивая маркер. Если BlockException не выброшено, запрос выполнен успешно. Он поддерживает управление потоком concurrency/qps и переход на более раннюю версию автоматического выключателя.
Контраст: 1. Предохранители hystrix вращаются вокруг пула потоков. Это больше подходит для изоляции ресурсов, но накладные расходы пула потоков будут расточительны, когда одно приложение имеет несколько служб. hystrix это разовый таймаут, который сразу сдувается, да и контрольная сила тоньше. Это можно рассматривать для сценариев с несколькими микрослужбами. 2. Sentinel основан на количестве параллелизма и поддерживает более сложные сценарии с низкими накладными расходами.Он подходит для повышения пропускной способности при обеспечении стабильности обслуживания. Но его тайм-аут — это среднее время ответа на 5 запросов. Не очень строго. но приемлемо для большинства сценариев
Метод доступа
Sentinel поддерживает два метода доступа: API и аннотацию. В качестве шлюза аварийного восстановления многие интерфейсы могут быть подключены позже. Для легкого доступа и без вмешательства в код. Требует использования аннотаций. Но у нативного @SentinelResource есть несколько проблем:
1. Можно указать только имя ресурса и резервный метод. Пользователям по-прежнему необходимо создавать правила аварийного восстановления через API.
2. Кроме того, в параметры резервного метода следует добавить BlockException. Этот метод доступа не очень элегантный.
3. Отдельно следует указать метод исключения управления потоком FlowException.
Таким образом, слой пользовательской аннотации @AegisResource инкапсулируется на основе Sentinel.
@AegisResource(value = "hello",limitThread = 0,timeOut = 100,failRate = 0.5,timeWindows = 100,fallback = "exceptionHandler")
Описание параметра:
значение: имя ресурса, по умолчанию — имя метода
limitThread: максимальное количество потоков, по умолчанию -1, то есть не включено
timeOut: время ожидания интерфейса, по умолчанию -1, не включено
failRate: частота отказов, по умолчанию -1, т.е. не включено
timeWindows: запуск понижения версии, но продолжительность, по умолчанию 100
fallback: резервный метод, должен быть указан
доступ к демо
/**
* 保护的方法
* @return
*/
@GetMapping("resourcetest")
@AegisResource(value = "hello",limitThread = 0,timeOut = 100,failRate = 0.5,timeWindows = 100,fallback = "exceptionHandler")
public String hello() {
return "ok";
}
/**
* 降级的方法
* @return
*/
public String exceptionHandler() {
// Do some log here.
return "Oops, error occurred at " ;
}
В новом интерфейсе нужно только написать метод, который вы хотите выполнить, и метод перехода на более раннюю версию, а затем добавить @AegisResource (fallBack="название резервного метода") к методу, который вы хотите выполнить для неинвазивного аварийного восстановления. Аспект определяет порог устойчивости к сбоям по умолчанию. Вы также можете установить пользовательские пороги для соответствующих свойств.
Позднее планирование
Текущий шлюз аварийного восстановления может удовлетворить текущие потребности. В настоящее время существует консоль с открытым исходным кодом, которая может просматривать панель управления вызовами службы и динамически настраивать правила аварийного восстановления. Недостатком является то, что текущая коллекция индексов является методом http. Правила аварийной устойчивости и рабочие индикаторы не сохраняются постоянно. Позже, при необходимости, вы можете использовать существующую консоль с открытым исходным кодом для вторичной разработки.