OSCHINA-MIRROR/didiopensource-sds

SDS (Service Downgrade System)

1. Предыстория

Эпоха мобильного интернета привела к тому, что бизнес получил крылья для роста. В то же время это стало серьёзным вызовом для серверных приложений: большой объём трафика, высокая степень параллелизма и огромные объёмы данных стали стандартом для серверных приложений.

Чтобы обеспечить единую обработку запросов, авторизацию и балансировку нагрузки, серверные приложения обычно имеют уровень шлюза, который перехватывает весь трафик, осуществляет равномерное ограничение трафика, аутентификацию и управление переадресацией трафика. Уровень ниже шлюза представляет собой сеть крупных сервисов, управляемую определённой системой управления сервисами. Хотя мы можем использовать микросервисную архитектуру для разделения приложений, делая обязанности и границы между ними более чёткими, позволяя им независимо расширяться в ширину и соответствовать командам для быстрой итерации разработки и обслуживания. Микросервисная архитектура может привести к увеличению количества приложений, которые необходимо поддерживать команде, сложной зависимости от сервисов и невозможности чётко определить зависимости между приложениями. Если одно приложение или зависимый компонент выходит из строя, это может привести к сбою всего основного сервиса. Большинство систем управления сервисами имеют простые возможности автоматического устранения неисправностей, изоляции и восстановления, поэтому требуется специализированная система для выполнения специализированных задач, и именно так мы разработали SDS.

2. Введение в SDS

SDS (Service Downgrade System) — это лёгкая, простая и удобная система ограничения трафика, отключения и понижения уровня обслуживания, которая позволяет Java-приложениям автоматически ограничивать трафик, отключать и быстро восстанавливаться, повышая общую «эластичность» приложений. В настоящее время серверы используют популярную микросервисную архитектуру, чтобы справиться со сложными сценариями с большим объёмом трафика и по-прежнему обеспечивать высокую способность к быстрой итерации и масштабируемости. Микросервисная архитектура не делает всю систему проще, наоборот, сложность управления микросервисной архитектурой выше, чем у традиционной централизованной архитектуры, поэтому важно обеспечить стабильность каждого узла системы в сложных условиях, используя инструменты для защиты узлов от перегрузки трафика и сбоев зависимостей.

Рисунок 1. Логотип SDS

3. Архитектура SDS

В архитектуре SDS используется модель клиент-сервер. Пока Java-приложение зависит от и использует пакет sdс-client, оно является клиентом SDS, а sdс-admin является сервером, предназначенным для настройки стратегии понижения уровня, предоставления богатого инструментария и сохранения статистики, отправленной клиентами, а также для ответа на последнюю стратегию понижения уровня (быстрый опыт sdс-admin: https://sds.chpengzh.com/).

Рисунок 2. Архитектура SDS

Как sdс-client взаимодействует с sdс-admin? Клиент SDS отправляет сердцебиение каждые 10 секунд, чтобы отправить статистику и данные о понижении уровня за последний полный цикл (10 секунд) и получить последнюю стратегию понижения уровня от сервера. Стоит отметить, что sdс-client имеет мало зависимостей, использует только память для сбора статистики, а данные клиентов агрегируются на сервере. Сервер использует сердцебиение клиента для распространения последней стратегии понижения уровня.

4. Принцип работы sdс-client

Из архитектуры SDS видно, что сервер sdс-admin отвечает за сохранение данных, настройку стратегии и отображение данных, в то время как клиентский jar-файл sdс-client отвечает за применение стратегии, сбор статистики, выполнение стратегии и отправку данных. sdс-client — это клиентская часть функций ограничения трафика и отключения, основная функция:

Ограничение трафика по количеству запросов: если количество запросов превышает заданный порог в течение 10-секундного окна времени, трафик ограничивается.
Ограничение параллельных запросов: можно ограничить количество одновременных вызовов определённого метода до заданного числа.
Отключение при ошибках: можно указать, что определённый метод достигает определённого количества ошибок или достигает определённого коэффициента ошибок в 10-секундном окне времени, чтобы отключить его.
Тайм-аут: можно установить тайм-аут для определённого метода в 10-секундном временном окне, и если количество запросов превысит заданное значение тайм-аута, трафик будет ограничен.
Алгоритм токена: реализуется путём генерации определённого количества токенов каждую секунду и использования максимального объёма корзины.

Следует отметить, что все параметры и пороги для вышеупомянутых стратегий ограничения могут быть настроены в sdс-admin и динамически изменены во время выполнения, и эти параметры применяются только к отдельному серверу, а не ко всему кластеру.

4.1 Ограничение трафика по количеству запросов

Ограничение трафика по количеству запросов является наиболее часто используемой стратегией ограничения, обычно существует два подхода:

Подход 1: подсчитывается количество вызовов данного метода в единицу времени, и когда достигается заданный порог, вызовы этого метода ограничиваются в оставшееся время единицы времени. Когда наступает следующая единица времени, счётчик сбрасывается и начинается новый отсчёт. Этот подход называется ограничением трафика на основе естественного времени.
Подход 2: подсчитывается количество вызовов метода в единицу времени, но единица времени не фиксирована, как в подходе 1, а изменяется со временем, подобно скользящему окну TCP. Этот подход называется ограничением трафика на основе скользящего окна.

Подход 1 имеет недостаток в том, что при переключении единиц времени счётчик должен быть сброшен, что приводит к скачку ограничения трафика, поскольку всё должно начинаться заново. Например, когда 90% времени единицы достигает порога, ограничение трафика вступает в силу только в оставшиеся 10% времени, пока не произойдёт переключение на следующую единицу времени и счётчик не будет сброшен. Подход 2 был разработан для решения этой проблемы, подсчитывая количество вызовов в скользящем окне фиксированной ширины, которое перемещается вперёд с течением времени. Это похоже на эффект скользящего окна в TCP или согласованности хэширования.

SDS 2.0 использует подход 2, где ширина окна составляет 10 секунд и шаг скольжения равен 1 секунде. Хотя в открытой структуре Hystrix нет ограничения трафика по количеству запросов, она использует метод скользящего окна для сбора данных об ошибках. SDS 2.0 вдохновлена её дизайном, но в отличие от Hystrix, ширина и размер шага скользящего окна SDS 2.0 не могут быть изменены. Конечно, пороги и коэффициенты ограничения трафика в sdс-admin настраиваются.

Итак, как SDS 2.0 реализует скользящее окно? Ответ заключается в использовании массива AtomicLongArray.

На рисунке каждый маленький квадрат представляет шаг времени, равный 1 секунде, а ширина скользящего окна постоянна и равна 10 секундам. Чтобы эффективно использовать пространство, мы проектируем AtomicLongArray в виде кольца, позволяя скользящему окну бесконечно перемещаться в ограниченном пространстве. Внимательные читатели заметят, что на рисунке всего 30 маленьких квадратов, хотя теоретически можно бесконечно перемещать скользящее окно в ограниченном пространстве, достаточно 11 квадратов, сформированных в кольцо. Почему их 30?

Помимо необходимости подсчёта данных скользящего окна, sdс-client также выполняет две задачи: сбор и отправка статистических данных и получение последней стратегии понижения уровня с сервера sdс-admin. Статистические данные, отправляемые на сервер, основаны не на скользящем окне, а на естественном временном окне продолжительностью 10 секунд. Порог ограничения трафика также определяется на основе данных, отображаемых на панели инструментов. Поэтому статистические данные, передаваемые sdс-client, похожи на [12:10:00~~12:10:10), [12:10:10~~12:10:20) и [12:10:20~12:10:30), как показано на рисунке, то есть статистические данные за естественный период времени, такой как красный, жёлтый и синий области на рисунке. Например, если текущее время равно 12:10:11, статистические данные текущего момента попадают в первый квадрат слева (жёлтая область). Продолжая в том же духе, когда время достигает 12:10:12, текущие статистические данные попадают в 12-й квадрат. Когда время достигает 12:10:15, sdс-client отправляет статистические данные предыдущего естественного периода времени (красная область) на sdс-admin, а затем очищает статистические данные следующего естественного периода времени (синяя область), готовясь к следующему циклу. Этот процесс повторяется, что объясняет, почему используется 30 квадратов. Пороги ограничения трафика можно динамически настраивать в sdс-admin.

4.2 Ограничение параллельных запросов

Существует два распространённых способа реализации ограничения параллельных запросов: один использует пул потоков для изоляции, ограничивая количество параллельных вызовов через размер пула потоков, другой использует семафоры для ограничения параллелизма. Известный инструмент ограничения трафика и отключения Hystrix использует оба этих метода. У каждого из них есть свои преимущества и недостатки: пулы потоков могут привести к нестабильности системы при неправильном использовании, но они могут возвращать результаты раньше времени из-за асинхронного выполнения. Семафоры имеют низкие накладные расходы, высокую производительность и меньший риск, но не могут возвращать результаты заранее. SDS 2.0 выбирает семафорный подход. Как и пороговое значение ограничения трафика, пороговое значение параллельного ограничения также можно настроить в sdс-admin. Текст запроса:

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

Ограничение количества исключений, как следует из названия, использует скользящее окно для подсчёта количества исключений. Когда это количество достигает установленного порога, применяется заданный коэффициент деградации согласно конфигурации в SDS-admin. Обратите внимание, что упомянутое здесь скользящее окно и окно доступа для ограничения потока являются одинаковыми.

С появлением ограничения количества исключений возникает потребность в ограничении доли исключений. Ограничение доли исключений указывает на то, что доля исключений достигает определённого процента, например, 40%. В этот момент начинается ограничение потока. Здесь доля исключений = количество исключений в скользящем окне / (количество обращений в скользящем окне - количество понижений в скользящем окне).

Внимательные читатели могут подумать, что при небольшом объёме трафика, когда в секунду поступает всего несколько запросов, создаваемое количество исключений может привести к значительным колебаниям в статистике доли исключений, например, если на 4 запроса приходится 2 исключения, доля исключений достигнет 50%! Это явно не соответствует нашим ожиданиям. Поэтому, когда мы используем ограничение доли исключений, помимо установки порога доли исключений также необходимо установить начальное значение объёма обращений для расчёта доли исключений.

Некоторые услуги, когда трафик увеличивается, а нагрузка системы возрастает, среднее время обработки обычно увеличивается. При дальнейшем увеличении трафика и нагрузки системы могут возникать ошибки, такие как тайм-ауты. SDS 2.0 предлагает решение для ограничения времени ожидания. Оно заключается в подсчёте количества запросов, время выполнения которых превышает установленный порог тайм-аута (в миллисекундах), в пределах скользящего окна. Если это количество превышает установленный порог количества тайм-аутов, происходит ограничение потока. Конечно, пороги тайм-аута и количества тайм-аут можно настроить в SDS-admin.

Коэффициент деградации — это целое число от 0 до 100, представляющее вероятность деградации, если стратегия выполнения определяет необходимость деградации. Например, установка коэффициента на 50 означает, что вероятность деградации составляет 50%, если стратегия выполнения решает, что поток должен быть понижен. Следовательно, если коэффициент установлен на 100, после определения стратегии выполнения как требующей деградации поток обязательно будет понижен. Напротив, если коэффициент равен 0, поток никогда не будет понижен.

Коэффициенты деградации можно использовать в качестве стратегии постепенного внедрения изменений!

Подробности см.: https://github.com/didi/sds/wiki/SDS%E7%9A%84%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97

Использование:

Известно, что вся логика деградации будет реализована через sdс-client.jar. Чтобы приложение стало клиентом SDS, оно должно зависеть от следующего jar:

<dependency>
   <groupId>com.didiglobal.sds</groupId>
   <artifactId>sds-easy</artifactId>
   <version>1.0.1-SNAPSHOT</version>
</dependency>

Sds-easy зависит от sdс-client, и его появление призвано упростить использование sdс-client.

Если вы используете Dubbo, вы также можете полагаться на sds-dubbo, который содержит встроенный фильтр Dubbo для лёгкого подключения к структуре Dubbo:

<dependency>
   <groupId>com.didiglobal.sds</groupId>
   <artifactId>sds-dubbo</artifactId>
   <version>1.0.1-SNAPSHOT</version>
</dependency>

Создание экземпляра SdsClient:

Обратите внимание, что этот объект должен использоваться в режиме одиночного элемента и может быть создан напрямую с помощью фабрики SdsClient:

// SDS控制台地址
private static final String SERVER_URL = "http://127.0.0.1:8887";
// Через фабричный метод для создания экземпляра SdsClient
private static final SdsClient sdsClient = SdsClientFactory.getOrCreateSdsClient("BikeBusinessDepartment", "order", SERVER_URL);

Мы можем инициализировать его в файле конфигурации Spring следующим образом:

<bean id="sdsClient" class="com.didiglobal.sds.client.SdsClientFactory" factory-method="getOrCreateSdsClient">
    <constructor-arg type="java.lang.String" value="BikeBusinessDepartment" />
    <constructor-arg type="java.lang.String" value="order" />
    <constructor-arg type="java.lang.String" value="http://127.0.0.1:8887" />
</bean>

Применение SdsClient для деградации (не рекомендуется, использование затруднительно):

Во-первых, когда нам нужно защитить определённый метод от деградации, мы должны пометить этот метод как точку деградации, чтобы мы могли настроить стратегию деградации для этого метода на стороне сервера. Мы называем эту точку деградации «точкой деградации». На самом деле это строка, которая используется для эстетических целей. Мы используем стиль именования переменных Java для имён точек деградации.

Например, нам нужна защита от деградации для метода businessMethod, мы можем назвать эту точку деградации businessMethodPoint (приложение обычно имеет много точек деградации, которые можно поместить в файл констант для централизованного управления), после определения точки деградации мы можем сразу приступить к кодированию:

/**
 * Имитация бизнес-метода
 * Если выполнение логики бизнеса возвращает true, иначе возвращается false
 *
 * @return
 */
protected boolean businessMethod() {
    try {
        /**
         * 1. Определение необходимости деградации
         */
        if (sdsClient.shouldDowngrade("somePoint")) {
            // Деградация после настройки по умолчанию или выброса исключения
            return false;
        }
 
        // Ниже нормальная бизнес-логика
        // TODO
        return true;
 
    } catch (Exception e) {
        /**
         * 2. Используется для записи количества исключений
         */
        sdsClient.exceptionSign("somePoint", e);
 
        // Не забудьте выбросить исключение, иначе будет сложно
        throw e;
 
    } finally {
        /**
         *  3. Освобождение ресурсов, обычно вызывается в блоке finally
         */
        sdsClient.downgradeFinally("somePoint");
    }
}

Можно видеть, что для выполнения метода деградации нам необходимо вызвать три метода SdsClient:

shouldDowngrade: на основе текущей информации и стратегии деградации определить, следует ли деградацию этой точке деградации, вернуть true, если требуется деградация, иначе вернуть false.

exceptionSign: запись количества исключений, запись того, было ли исключение в этом запросе, если да, то количество исключений увеличивается на 1.

downgradeFinally: отметить завершение жизненного цикла деградации.

Следует отметить, что метод downgradeFinally должен быть вызван (поместить его в блок finally), иначе некоторые ресурсы не могут быть освобождены!

6. Более простой способ использования (рекомендуется)

6.1 Вышеупомянутый метод слишком сложен, на самом деле мы можем напрямую использовать SdsEasyUtil для выполнения деградации (эффект такой же)

Ранее упоминалось, что sds-easy предоставляет более простой метод использования, то есть использование класса SdsEasyUtil, например:

protected static final String SERVER_URL = "http://127.0.0.1:8887";
 
static {
    // Можно найти тихое место для инициализации SdsClient
    SdsClientFactory.getOrCreateSdsClient("BikeBusinessDepartment", "order", SERVER_URL);
}
 
// Здесь имитируется бизнес-сервис
private ThreadLocal<String> traceIdService = ThreadLocal.withInitial(() -> "古墓丽影");
 
@Test
public void invokerMethodTest() {
 
    // Некоторая локальная переменная (прохожий A)
    Date date = new Date();
 
    /**
     * Включает логику бизнес-решения с оценкой деградации
     *
     * Обратите внимание: класс SdsEasyUtil является упрощённым инструментом
     */
    String result = SdsEasyUtil.invokerMethod("somePoint", "Я являюсь значением по умолчанию после деградации", () -> {
 
        // Здесь можно добавить некоторую странную бизнес-логику

В исходном тексте запроса присутствуют технические термины и конструкции, характерные для разработки программного обеспечения. Основной язык текста запроса — английский. ```
System.out.println(date);
return traceIdService.get();

Assert.assertEquals("古墓丽影", result);
}

Конечно, в приведённом выше коде используется синтаксис Lambda. Если вы используете версию JDK ниже 8, можно использовать следующий код:

String result = SdsEasyUtil.invokerMethod("somePoint", "我是降级后的默认值", new BizFunction<String>() {
    @Override
    public String invokeBizMethod() {
        // Здесь можно добавить некоторые странные бизнес-логики
        System.out.println(date);
        return traceIdService.get();
    }
});

7. Поддержка аннотаций (рекомендуется)

SDS также поддерживает использование аннотаций для подключения. Нам нужно только использовать @SdsDowngradeMethod на методе. Существует два способа использования аннотации: один — использовать возможности Java Agent для внедрения кода SDS во время загрузки класса (аналогично Pinpoint), другой — использовать возможности Aspectj для динамического внедрения.

7.1 Использование аннотаций через Java Agent

Первый шаг: используйте зависимость maven sdss-bootstrap.jar (или поместите sdss-bootstrap.jar в абсолютный путь, например /home/sds/lib/sds-bootstrap.jar).

<dependency>
    <groupId>com.didiglobal.sds</groupId>
    <artifactId>sds-bootstrap</artifactId>
    <version>1.0.1-SNAPSHOT</version>
</dependency>

Второй шаг: при запуске JVM используйте javaagent для импорта sdss-bootstrap.jar, поэтому нам нужно изменить скрипт запуска, например:

# Через относительный путь импортировать sdss-bootstrap.jar (здесь предполагается, что после упаковки проекта sdss-bootstrap.jar находится в каталоге lib текущего каталога проекта)
java -javaagent:lib/sds-bootstrap.jar MyApplication

# Конечно, вы также можете импортировать sdss-bootstrap.jar через абсолютный путь
java -javaagent:/home/sds/lib/sds-bootstrap.jar MyApplication

Третий шаг: теперь вы можете напрямую использовать @SdsDowngradeMethod в методах класса.

Обратите внимание: этот метод применим к любым методам класса, независимо от того, являются ли они private или public.

7.2 Использование аннотаций с помощью Spring AOP (Aspectj)

Первый шаг: проекту требуется зависимость sdss-aspectj.jar, например:

<dependency>
    <groupId>com.didiglobal.sds</groupId>
    <artifactId>sds-aspectj</artifactId>
    <version>1.0.1-SNAPSHOT</version>
</dependency>

Второй шаг: если вы используете Spring (включая Spring Boot), вам необходимо создать компонент SdsPointAspect Bean:

@Configuration
public class SdsConfiguration {
    @Bean
    public SdsPointAspect createSdsPointAspect() {
        return new SdsPointAspect();
    }
}

Третий шаг: теперь вы можете напрямую использовать @SdsDowngradeMethod в методах класса.

Обратите внимание: этот способ не работает для методов private.

Напоминание: не используйте методы Java Agent и Spring AOP одновременно!

8. Обнаружение понижения версии

Могу ли я узнать, был ли понижен уровень сервиса только из панели инструментов sdss-admin? Или клиент также может обнаружить понижение уровня сервиса, зарегистрировав слушателя следующим образом:

static {
    SdsDowngradeActionNotify.addDowngradeActionListener(new DowngradeActionListener() {

        @Override
        public void downgradeAction(String point, DowngradeActionType downgradeActionType, Date date) {
                System.out.println(point + "был понижен, тип понижения:" + downgradeActionType);
                System.out.println("Слушатель понижения уровня обычно используется для вывода журналов!");
            }
        });
    
    }
}

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

9. Часто используемые расширения

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

9.1 Поддержка Dubbo

Большинство внешних инструментов подключаются к Dubbo через фильтр, который инициализируется Dubbo с использованием SPI. Экземпляр SdsClient следует использовать как статический синглтон.

Мы предоставляем sdss-dubbo.jar для этой цели (обратите внимание, что если вы создаёте проект с использованием maven, бизнес-система может просто зависеть от sdss-dubbo.jar, потому что sdss-dubbo.jar внутренне зависит от sdss-client.jar), который содержит SdsProviderFilter и SdsConsumerFilter. Эти два фильтра предоставляют переопределяемые интерфейсы, которые позволяют бизнес-системе предоставлять возвращаемые значения или поведение после понижения уровня в соответствии со своими особенностями:

/**
 * Возвращает значение по умолчанию после понижения
 *
 * @return Значение не должно быть подклассом Throwable
*/
protected static Object returnDefaultValueAfterDowngrade() {
    return null;
}

/**
* После понижения напрямую генерирует исключение
*
* @return
*/
protected static Throwable throwThrowableAfterDowngrade() {
    return null;
}

10. Преимущества SDS

Цель SDS — создать простую, удобную и надёжную систему ограничения потока, отключения и понижения уровня обслуживания. Давайте вернёмся к концу 2015 года, когда нам срочно понадобился инструмент, который мог бы автоматически ограничивать поток, отключать и восстанавливать его, но после изучения рынка мы обнаружили, что Hystrix не соответствовал нашим потребностям. Hystrix использует RxJava, поэтому он слишком тяжёлый для нас, и, кроме того, основные способы ограничения потока Hystrix — это счётчик и пул потоков, которые не удовлетворяют нашим требованиям к ограничению потока в фиксированном временном окне (в то время мы использовали систему мониторинга с интервалом в одну минуту, поэтому мы надеемся, что сможем выполнить управление потоком в течение одной минуты). Кроме того, Hystrix разработан на основе модели Command, которая имеет высокую степень вторжения. Поскольку у нас есть чёткая цель, SDS1.0 был выпущен в начале 2016 года. Хотя функции были простыми, а API-дизайн не был идеальным, удобство использования было относительно плохим, и весь интерфейс консоли также не был ориентирован на человека. Теперь это кажется немного жалким. Поэтому в конце 2017 года мы начали рефакторинг, и в 2018 году появился SDS2.0, который значительно улучшил функциональность и удобство использования по сравнению с SDS1.0 и в настоящее время используется в двух раундах автомобилей (SDS1.0 всё ещё используется отделами, такими как Didi и Security). Чтобы внести свой вклад в общество, мы надеемся открыть исходный код SDS2.0. По сравнению с известным Hystrix, преимущества SDS в основном проявляются в более богатых функциях ограничения потока, включая количество доступа, параллелизм, количество ошибок, время ожидания и токены. В дополнение к этому, консоль управления SDS более мощная, чем Hystrix. По сравнению с Sentinel, открытым исходным кодом Alibaba в июле 2018 года, преимущества SDS в основном заключаются в простоте, лёгкости начала работы и поддержке готовых решений для понижения уровня, которые облегчают разработку планов аварийного восстановления. Слабые стороны SDS по сравнению с Sentinel в основном проявляются в отсутствии кластерного унифицированного ограничения потока и поддержке только Java.

11. Свяжитесь с нами и присоединяйтесь

Группа WeChat: у нас есть группа WeChat (группа разработчиков SDS), но срок действия QR-кода составляет 7 дней, поэтому добавьте WeChat ID sugarmq, devil_chpengzh, lansedemeng-2010, huangyiminghappy и BU_DONG_XIAO_BIN в качестве друзей (отметьте SDS), и мы добавим вас в группу.

Группа DingTalk: у нас также есть группа DingTalk (группа разработчиков SDS). Пожалуйста, используйте QR-код DingTalk для присоединения:

avatar