Оглавление

• [1. Введение] (#main-chapter-1)
• [2. Концепция дизайна] (#main-chapter-2)
• [3. Общая архитектура] (#main-chapter-3)
• [4. Характеристики платформы] (#main-chapter-4)

1. Введение

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

Проект TARS был создан на основе многолетнего опыта использования внутренней микросервисной архитектуры TAF (Total Application Framework) компании Tencent. Название TARS происходит из фильма "Интерстеллар", где робот TARS имеет очень дружественный интерфейс взаимодействия, который позволяет любому человеку легко общаться с ним. Кроме того, он способен выполнять все порученные ему задачи с превосходной эффективностью в условиях космического пространства и на других планетах. Аналогично этому, TARS представляет собой фреймворк, объединяющий удобство использования, высокую производительность и управление сервисами, чтобы сделать разработку проще, сосредоточиться на бизнес-логике, а эксплуатацию — более эффективной.

Сегодня этот фреймворк используется внутри Tencent более чем в 100 проектах и на более чем 16 000 серверах.# 2. Концепция дизайна

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

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

3. Общая архитектура

3.1. Топология архитектуры

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

Сервисные узлы:

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

На каждом сервисном узле находится один Node-узел и N (N >= 0) бизнес-сервисных узлов. Узел Node управляет бизнес-сервисами, предоставляя возможности запуска/остановки, публикации, мониторинга и принимает отчеты о состоянии бизнес-сервисов.

Общие узлы фреймворка:

Кроме сервисных узлов все остальные узлы объединены в одну категорию.

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

Эти узлы можно разделить на следующие части:- Web-система управления: позволяет просматривать различные данные о работе сервисов в реальном времени, а также выполнять такие действия, как публикация, запуск/остановка, развертывание сервисов;

• Registry (маршрутизация + административные службы): предоставляет возможность поиска адресов сервисных узлов, публикации, запуска/остановки, управления, а также управления отчётами о состоянии сервисов, что позволяет регистрировать и находить сервисы;
• Patch (управление выпусками): предоставляет функцию публикации сервисов;
• Config (центр конфигураций): предоставляет функцию централизованного управления конфигурационными файлами сервисов;
• Log (удалённые логи): предоставляет функцию отправки логов сервисов на удалённый сервер;
• Stat (статистика вызовов): собирает информацию о различных вызовах, таких как общее количество трафика, среднее время выполнения, процент превышения времени и т. д., чтобы предотвращать сбои сервисов путём выдачи тревожных сообщений;
• Property (собственные свойства бизнеса): собирает информацию о собственных свойствах бизнеса, таких как использование памяти, размер очереди, скорость попадания в кэш и т. д., чтобы предотвращать сбои сервисов путём выдачи тревожных сообщений;
• Notify (информация о сбоях): собирает информацию о различных сбоях, таких как изменения состояния сервиса, ошибки доступа к базе данных и т. д., чтобы предотвратить сбои сервисов путем выдачи тревожных сообщений; Основные требования заключаются в том, что все узлы должны иметь взаимодействие друг с другом через сеть. По меньшей мере, каждый узел машины должен быть доступен для взаимодействия с общими узлами фреймворка.## 3.2. Диаграмма взаимодействия сервисов

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

Процесс публикации службы: Веб-система загружает пакет публикации сервера на patch. После успешной загрузки, на веб-панели отправляется запрос на публикацию сервера, который передается службой registry на узел. Затем узел загружает пакет публикации сервера локально и запускает службу сервера.

Процесс управления командами: На веб-панели можно отправлять запросы на управление службой сервера, которые передаются службой registry на узел. Затем узел отправляет команды управления на сервер.

Процесс отчета о состоянии сердца: После запуска службы сервера она регулярно отправляет отчет о состоянии сердца на узел, а затем узел отправляет информацию о состоянии службы на службу registry для централизованного управления.

Процесс отчета информации: После запуска службы сервера она регулярно отправляет отчеты о статистической информации на stat, выводит удалённые журналы на log, регулярно отправляет отчеты о свойствах на property, отчеты об ошибках на notify, а также получает конфигурационные данные услуг с config.Процесс доступа клиента к серверу: Клиент может получить доступ к серверу через объектное имя Obj сервера. Клиент получает информацию маршрутизации сервера (например, ip и port) с registry, а затем использует эту информацию для доступа к серверу в зависимости от конкретных характеристик бизнеса (синхронизация или асинхронность, tcp или udp).

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

Веб-система управления состоит из следующих основных функций:

• Управление бизнесом: включает уже развернутые службы, управление службами, управление публикациями, конфигурирование служб, мониторинг служб, мониторинг особенностей и т.д.;

• Управление эксплуатацией: включает развертывание служб, масштабирование, управление шаблонами и т.д.

3.4. Структурная диаграмма служб

Структурная диаграмма реализации клиентской и серверной части фреймворка представлена ниже:

Серверная часть:

NetThread: прием и отправка данных, управление соединениями, многопоточность (настраиваемая), использует epoll ET для триггеров, поддерживает tcp/udp;

BindAdapter: класс привязки порта, используется для управления информацией о привязке портов, соответствующих servent;

ServantHandle: бизнес-поток, распределяет вызовы объектов и интерфейсов Servant по имени объекта.AdminServant: объект административного порта;

ServantImp: базовый класс для обработки бизнеса, наследуемый от Servant (Servant — базовый класс для объектов интерфейса сервера). Клиентская часть:

NetThread: отправка и получение пакетов, управление соединениями, многопоточность (настраиваемая), использует epoll ET триггер для реализации, поддерживает tcp/udp;

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

ObjectProxy: агент удалённого объекта, отвечает за маршрутизацию, балансировку нагрузки и отказоустойчивость, поддерживает круговой метод/хэширование/вес;

ServantProxy: локальный агент для вызова удалённого объекта, поддерживает синхронный/асинхронный/односторонний вызов, протокол Tars и не-Tars;

AsyncThread: поток обработки ответных пакетов для асинхронных запросов;

Callback: базовый объект для обработки конкретных callback операций бизнеса;

4. Характеристики платформы

4.1. Протокол Tars

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

Поддерживаемые типы разделены на два типа: базовые и сложные.

Базовые типы включают: void, bool, byte, short, int, long, float, double, string, unsigned byte, unsigned short, unsigned int;

Сложные типы включают: enum, const, struct, vector, map, а также вложения struct, vector, map.

Например:

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

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

Синхронный вызов: Клиент отправляет запрос на вызов и ждет возврат результата от сервера до продолжения логики;

Асинхронный вызов: Клиент отправляет запрос на вызов и продолжает другую бизнес-логику, результат возвращаемого сервера обрабатывается классом обратного вызова;

Односторонний вызов: Клиент отправляет запрос на вызов и завершает его, сервер не возвращает результат вызова;## 4.3. Балансировка нагрузки Фреймворк использует службу имен для регистрации и обнаружения служб, клиенты обращаются к службе имен для получения списка адресов обслуживания, затем клиент выбирает подходящий метод балансировки нагрузки для вызова службы. Поддержка балансировки нагрузки включает различные методы, такие как циклический, хэш, весовые и другие.

4.4. Защита от сбоев

Защита от сбоев реализуется двумя способами: исключение через службу имён и активное исключение клиентом.

Исключение через службу имён:

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

Активное исключение клиентом:

Для более быстрого исключения неработающих узлов клиент использует информацию о возникающих исключениях при вызовах сервиса. Конкретная стратегия заключается в том, что если клиент сталкивается с последовательной ошибкой времени выполнения при вызове определенного сервера, или процент ошибок превышает определённый порог, клиент начинает исключать этот сервер, направляя трафик на работающие узлы. Для исключённых серверов производится попытка повторного подключения каждые определённые промежутки времени; если подключение успешное, то нормальный трафик будет восстановлен.## 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. Централизованное конфигурирование

Централизованное управление конфигурациями бизнеса и веб-интерфейсов для операций позволяет легче менять конфигурации, своевременно получать уведомления и безопаснее управлять изменениями конфигураций; история изменений позволяет легко вернуться к предыдущей версии конфигурации. Сервис получения конфигураций позволяет службе получить конфигурационные файлы путём вызова соответствующего API.Для гибкого управления конфигурационными файлами, последние разделены на несколько уровней: конфигурация приложения, конфигурация группы (Set), конфигурация сервиса и конфигурация узла.

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

Конфигурация группы (Set) представляет собой общую конфигурацию всех сервисов внутри одной группы (Set), которая дополняется на основе конфигурации приложения.

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

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

Дополнительная информация доступна в файле tars_config.md в каталоге docs.