TARS предоставляет высокопроизводительные возможности RPC для SpringCloud.

Узкие места традиционного HTTP

Spring Cloud — отличное решение для микросервисов с открытым исходным кодом.Обычно оно использует интерфейс REST HTTP + json для предоставления внешних сервисов.Он прост, удобен в использовании и развертывании.Многие компании также создают свою собственную микросервисную архитектуру на основе Spring Cloud как инфраструктура. Однако по мере роста масштабов бизнеса и пользователей традиционные сервисы на основе HTTP постепенно обнаружат некоторые проблемы.

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

Во-вторых, это проблема стабильности.Когда служебный узел А должен зависеть от нескольких служб на бэкэнде, мы обнаружим, что, когда одна из зависимых служб зависает, это, вероятно, вызовет сбои на внешнем служебном узле А. или даже быть не в состоянии продолжать оказывать услуги, и когда проблемный узел не может быть вовремя заблокирован или восстановлен, это может вызвать лавину всей системы.

вопрос: Поскольку сам протокол HTTP не имеет состояния, при инициировании запроса необходимо дождаться ответа на предыдущий запрос, чтобы снова использовать соединение.Даже если используется конвейерный режим, запрос на соединение будет заблокирован ранее инициированным запрос.Если вы хотите увеличить параллелизм, необходимо установить большое количество соединений, а установление, обслуживание и уничтожение соединений будут потреблять системные ресурсы.

решить: Из-за характеристик протокола HTTP возвращаемые пакеты HTTP зависят от порядка запросов. Один запрос должен быть обработан по порядку перед обработкой следующего запроса. Если вы хотите обрабатывать запросы параллельно, вы можете создать новую ссылку, только установление нового соединения.Время, необходимое для соединения, а также ресурсы ЦП и памяти, необходимые для поддержания соединения. 

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

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

2. Решить проблему низкой производительности традиционного HTTP-протокола связи SpringCloud.

вопрос: HTTP + json сам по себе является хорошо читаемым текстовым протоколом, поэтому фактически передаваемые пакеты данных будут намного больше, чем двоичный протокол, а текстовый протокол более эффективен, чем двоичные данные, с точки зрения эффективности сериализации и десериализации данных. Намного ниже, поэтому производительность самого протокола HTTP невысока.

решить: Передача данных TARS использует протокол TARS для кодирования и декодирования.Протокол TARS является двоичным протоколом.По сравнению с обычными текстовыми протоколами, такими как JSON, двоичный протокол имеет два преимущества:

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

2. Размер сетевого пакета Поскольку все данные хранятся в двоичном формате, данные хранятся в битах, что сокращает трату пространства, поэтому сериализация данных может уменьшить занимаемое пространство. 

Протокол TARS использует файлы .tars для определения интерфейсов и интерфейсов данных, а предоставляемые инструменты могут переводить определения данных и интерфейсов в коды на различных языках. 

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

3. Решить проблему производительности традиционной HTTP-службы SpringCloud на основе модели синхронных потоков.

вопрос: Традиционные службы HTTP в основном основаны на модели синхронных потоков. Поскольку сам протокол HTTP не имеет состояния, он не поддерживает асинхронность на уровне протокола. Поэтому, когда мы инициируем HTTP-вызов на клиенте, вызывающий поток должен приостанавливаться и ждать вызываемый для ответа на запрос. , в это время ресурсы вызывающего потока тратятся впустую, поскольку ресурсы потока ограничены, а большое количество потоков приостановлено и ожидает, чтобы растратить вычислительные ресурсы вызывающей стороны.

решить: По сравнению с обычной схемой, использующей протокол HTTP, первая функция, предоставляемая TARS, — это метод вызова RPC для асинхронного длинного соединения:

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

Асинхронные возможности TARS в основном реализуются за счет асинхронности двух частей. Первая — это асинхронность первого сетевого пакета. Реализация TARS на сетевом уровне использует модель Reactor, а асинхронный сетевой ввод-вывод на основе событий реализуется через событие. IO предоставлено nio. Второй — асинхронность поточной модели.Давайте посмотрим, как TARS выполняет асинхронные вызовы поточной модели:

TARS в основном завершает асинхронный вызов через процесс, показанный на рисунке выше.Сначала вызывающий поток инициирует асинхронный вызов, вызывающий поток добавляет содержимое запроса в очередь отправки пула сетевых потоков, после чего поток продолжает выполняться. . Пул сетевых потоков реализован с использованием модели Reactor, а ввод-вывод событий реализуется через Selecter, предоставляемый nio, поэтому все сетевые потоки являются управляемым событиями асинхронным вводом-выводом После прослушивания события записи соответствующего соединения запрос будет отправлен. , и событие чтения будет прочитано после прослушивания события чтения.Ответ передается потоку обратного вызова для обработки ответа. Таким образом, все потоки избегают блокировки ввода-вывода и достигают более высокой эффективности использования.

4. Решить проблему стабильности сервера SpringCloud на основе модели синхронных потоков.

вопрос: Самая большая скрытая опасность модели синхронных потоков на стороне сервера микросервиса — это ожидание потоков ввода-вывода.Например, микросервис, основанный на модели синхронных потоков, опирается на следующие три интерфейса.Количество потоков в самом микросервисе равно 50. Затем, когда один из трех интерфейсов, который зависит от бэка, имеет высокую задержку, всего 50 обращений к проблемному интерфейсу достаточно, чтобы приостановить весь процесс микросервиса, потому что на данный момент нет потока, который может предоставлять услуги внешнему миру ( Конечно, вы можете установить тайм-аут, но установка тайм-аута может вылечить симптомы, а не основную причину). В то же время из-за IO-ожидания потока микросервиса для проблемного интерфейса в очереди микросервиса будет скапливаться большое количество запросов со слишком большим временем ожидания (возможно, истекло время ожидания).При восстановлении проблемного интерфейса , сервер будет потреблять ресурсы для обработки большого количества запросов.Запросы с истекшим сроком действия (время ожидания запроса истекает, и клиент больше не ждет) еще больше усугубляют проблему, даже приводя к системной лавине.

решить: TARS обеспечивает чистое асинхронное программирование и возможность защитить сервер от перегрузок.Сервер может обеспечить получение большого количества запросов и также может гарантировать нормальную эффективность обработки сервиса.Во-вторых, потому что вызывающая сторона использует длинные соединения и асинхронные вызовов, это позволяет избежать большого количества новых конструкций.Расход ресурсов, вызванный подключением и блокировкой, повышает общую стабильность сервиса.

Кроме того, если сервер получает избыточные запросы, это часто приводит к конкуренции потоков на сервере, что делает вычислительную мощность сервера ниже нормального уровня обработки.В TARS очередь используется для защиты от перегрузок. Давайте посмотрим на поточную модель TARS:

После того, как сетевой поток получит запрос, TARS сначала добавит запрос в очередь запросов, а рабочий поток получит запрос из очереди запросов для обработки.Если за короткий промежуток времени поступает большое количество запросов, они кэшироваться только в очереди запросов и не влияет на пул рабочих потоков. Если пул рабочих потоков получает запрос из очереди и обнаруживает, что время ожидания истекло, он напрямую отбрасывает запрос, чтобы избежать обработки недействительных запросов.

Взгляните на реальный сценарий использования с помощью приведенного выше решения TARS.

сцена первая. Синхронный вызов, двойная производительность

Обычно просто или просто преобразовать службу и изменить исходный интерфейс HTTP для использования TARS. Давайте сравним разницу в производительности между вызовом TARS и HTTP-вызовом в сценарии синхронного вызова. Здесь количество потоков на стороне сервера равно 100 потоков.Обработка предназначена для простых эхо-сервисов. Давайте сравним данные TPS для разных методов RPC, разных клиентских потоков и разных размеров пакетов на одной и той же машине:

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

Сцена вторая. Асинхронные вызовы, чтобы избежать блокировки и повысить производительность

Если у нас есть такое вызывающее отношение в Spring Cloud, служба A должна вызывать службу B, а служба B должна зависеть от службы C, что требует гораздо больше времени обработки, чем служба B. Например, в обычном бизнес-сценарии, если интерфейсу API необходимо вызвать службу генерации заказов, а службе генерации заказов нужно только сгенерировать идентификатор заказа, сумма расчета будет относительно небольшой, но она также должна полагаться на заказ. служба записи, которая должна быть связана с инвентаризацией. Модификация и запись заказа требуют обработки ряда транзакций, а общее время занимает намного больше, чем генерация идентификаторов заказа. Поэтому большое количество потоков ресурсов службы заказов потрачено впустую на ожидание службы написания заказа. В этом случае вы можете использовать TARS для преобразования службы заказов и службы записи, чтобы использовать асинхронные вызовы службы записи для улучшения использования ресурсов, а также использовать возможности асинхронного RPC, предоставляемые TARS, для выполнения глубокого преобразования:

Обычно, если используется синхронный вызов, поскольку B должен дождаться ответа от службы C, ему необходимо потратить несколько раз свое собственное время обработки, чтобы дождаться возврата результата службой C, а поток блокируется и тратится впустую. ресурсы потока. В этом случае мы можем оставить службу A без изменений и предоставить REST-интерфейс, а службу B трансформировать с помощью асинхронных вызовов. Как показано ниже:

Мы моделируем вышеописанный процесс с помощью простого кода.При добавлении логики службы C он вернет результат через Sleep 10s после получения запроса.Служба C имеет 10 потоков обработки.В начале используются синхронные вызовы между B и C для достижения максимального параллелизма. Служба эффективности B также должна обеспечивать 10 потоков, чтобы иметь возможность достичь максимальной эффективности параллельного выполнения TPS, равной 1. На этом этапе мы используем асинхронные вызовы для преобразования службы B:

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

Чтобы проверить вышеописанную ситуацию, мы указываем, что служба C по умолчанию использует 100 потоков, а процесс обработки службы — это 10-секундный сон, чтобы имитировать относительно трудоемкую службу ресурсов. Сервис B — это общий сервис, который зависит от ресурсного сервиса C, то есть возвращает результат C. В тесте сервис B вызывает сервис C синхронным и асинхронным способами и записывает ситуацию с сервисом B в разных потоках, корректируя количество потоков.Максимальная пропускная способность, которая может быть обеспечена:

Поскольку максимальное значение TPS, которое может предоставить служба C, равно 10, видно, что асинхронный вызов с использованием TARS может полностью использовать ресурсную службу C за счет использования небольшого количества потоков, поскольку это позволяет избежать блокировки и тем самым избежать пустой траты ресурсов.

В приведенном выше преобразовании внешний HTTP-интерфейс не требует модификации, его можно модифицировать только в тех местах, где требуется повысить производительность RPC и использовать асинхронные вызовы внутри, а сервис можно плавно постепенно модернизировать. И поскольку все они реализованы загрузкой Spring, вам нужно только изменить интерфейс, а весь остальной бизнес-код можно внедрить с помощью Spring.

напиши в конце

Мы внедрили в TARS поддержку обнаружения сервисов Eureka с помощью подключаемых модулей и предоставили стартовые пакеты загрузки Spring и соответствующие аннотации, которые позволяют быстро разрабатывать сервисы с помощью методов разработки, соответствующих привычкам разработчиков Spring Cloud. Интеграция Spring Cloud посредством обнаружения и разработки сервисов позволяет разработчикам быстро внедрить возможности TARS RPC во всю среду Spring Cloud по низкой цене.

Добро пожаловать на Github-адрес проекта TARS: https://github.com/Tencent/Tars.

Попробуйте последнюю версию TARS на SpringCloud!