Введение

Tars — это высокопроизводительный RPC-фреймворк для разработки микросервисов, который также включает в себя интегрированную платформу управления сервисами. Он помогает быстро и эффективно создавать надёжные распределённые приложения как для индивидуальных разработчиков, так и для компаний.

Tars основан на многолетнем опыте использования микросервисной архитектуры TAF (Total Application Framework) внутри компании Tencent. Название Tars происходит от робота TARS из фильма «Интерстеллар». Робот TARS обладает дружелюбным интерфейсом взаимодействия, и с ним легко общаться даже тем, кто впервые его видит. В сложных условиях, таких как космическое пространство или другие планеты, он способен выполнять задачи с высокой эффективностью.

Подобно роботу TARS, Tars также предлагает удобство использования, высокую производительность и управление сервисами. Его цель — упростить разработку и сосредоточить внимание на бизнес-логике, а также повысить эффективность эксплуатации.

В настоящее время фреймворк Tars используется внутри компании Tencent и работает на более чем 100 бизнес-приложениях и более чем 16 000 серверах.

Дизайн

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

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

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

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

Архитектура

Архитектура Tars состоит из двух основных компонентов: узлов сервисов и общих компонентов фреймворка.

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

Каждый узел сервиса включает в себя Node-узел и N (N ≥ 0) узлов бизнес-сервисов. Node-узлы управляют узлами бизнес-сервисов и предоставляют функции запуска, публикации, мониторинга и получения отчётов о состоянии.

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

К общим компонентам относятся:

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

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

Взаимодействие сервисов

Взаимодействие между сервисами в Tars включает обмен данными между бизнес-сервисами, взаимодействие между бизнес-сервисами и общими компонентами фреймворка, а также обмен информацией между клиентами и сервисами.

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

Команды управления сервисом отправляются через веб-систему на реестр, который передаёт их на соответствующий Node-узел. Затем Node-узел отправляет команды сервису.

Сервису периодически отправляют отчёты о сердцебиении на Node-узел, который, в свою очередь, передаёт эту информацию в реестр. Реестр управляет этой информацией централизованно.

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

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

Веб-система управления

Веб-система управления предоставляет следующие возможности:

• управление сервисами, включая уже развёрнутые сервисы и функции управления, публикации, конфигурации, мониторинга и отслеживания характеристик;
• эксплуатация, включая развёртывание сервисов, расширение ресурсов и управление шаблонами.

Структура сервисов

Основные компоненты сервера и клиента в Tars включают:

• NetThread, отвечающий за отправку и получение пакетов, управление соединениями и многопоточность;
• BindAdapter, управляющий информацией о портах, связанных с сервером;
• ServantHandle, распределяющий запросы между объектами Servant;
• AdminServant, управляющий портами администрирования;
• ServantImp, реализующий бизнес-логику;
• NetThread на клиенте, выполняющий аналогичные функции, что и на сервере;
• AdapterProxy, обеспечивающий связь с конкретным узлом сервера;
• ObjectProxy, маршрутизирующий запросы и обеспечивающий балансировку нагрузки и отказоустойчивость;
• ServantProxy, обрабатывающий вызовы удалённых объектов;
• AsyncThread, обрабатывающий ответы на асинхронные запросы;
• Callback, реализующий обработку конкретных бизнес-операций.

Протокол Tars

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

Типы данных, поддерживаемые протоколом Tars, делятся на базовые и сложные. Базовые типы включают void, bool, byte, short, int, long, float, double, string, unsigned byte, unsigned short и unsigned int. Сложные типы включают enum, const, struct, vector и map, а также вложенные структуры, векторы и карты.

Способы вызова

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

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

Балансировка нагрузки

Платформа Tars реализует регистрацию и обнаружение сервисов через систему имён. Клиент получает список адресов сервисов от системы имён и выбирает способ балансировки нагрузки в зависимости от своих потребностей. 4.4. Резервное копирование

Резервное копирование реализуется двумя способами: исключение по имени службы и активное экранирование со стороны клиента.

Исключение по имени службы:

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

Активное экранирование со стороны клиента:

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

4.5. Защита от перегрузки

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

4.6. Маркировка сообщений

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

4.7. Группировка IDC

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

Подробности см. в tars_idc_set.md в каталоге docs.

4.8. Группировка SET

С целью упрощения стандартизации и масштабирования управления развёртыванием бизнес-служб, структура предоставляет возможности развёртывания SET. Между SET нет вызовов, они не влияют друг на друга, сбои изолированы, что повышает эффективность эксплуатации и обслуживания и доступность служб.

Подробности см. в tars_idc_set.md в каталоге docs.

4.9. Мониторинг данных

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

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

4.10. Централизованное управление конфигурацией

Централизованное управление бизнес-конфигурацией и её веб-интерфейс упрощают изменение конфигурации и обеспечивают своевременное уведомление и безопасное изменение конфигурации. История изменений конфигурации позволяет легко вернуться к предыдущей версии. Извлечение конфигурации осуществляется через сервисы, и сервисам нужно только вызвать интерфейс конфигурации, чтобы получить файл конфигурации.

Конфигурационные файлы разделены на несколько уровней: конфигурация приложения, конфигурация SET, конфигурация службы и конфигурация узла.

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

Конфигурация SET — это общая конфигурация всех служб в конкретном наборе групп, дополняющая конфигурацию приложения.

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

Конфигурация узла — это индивидуальная конфигурация конкретного узла приложения, которая объединяется с конфигурацией службы для формирования конфигурации конкретного узла службы.

Подробные сведения см. в tars_config.md в каталоге docs.