Tseer: продукт и его особенности

Введение

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

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

У Tseer есть два способа доступа: через веб-интерфейс управления и API. Пользователи могут свободно выбирать подходящий способ в зависимости от своих потребностей. Через прокси-узлы и прокси-серверы Tseer предоставляет прозрачный доступ к обнаружению сервисов для часто обновляемых сервисов. Обучение просто и удобно, что делает его дружественным для администраторов сервисов.

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

Разработка

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

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

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

На основе этих проблем был разработан Tseer.

Архитектура

Структура Tseer состоит из трёх частей: Tseerserver, клиент (главный вызывающий) и серверный сервис (вызываемый).

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

• Клиент — узел, который вызывает другие сервисы и называется главным вызывающим. Tseer предлагает два метода для получения адреса вызываемого сервиса от Tseerserver: установка агента и вызов API.

• Сервер — сервис, который должен быть вызван и называется вызываемым. При подключении нового узла к Tseerserver требуется зарегистрировать его в кластере. Независимо от количества узлов в одном кластере, регистрируется только одно имя кластера. Главный вызывающий использует имя сервиса для вызова. Tseer возвращает адрес вызываемого сервиса на основе зарегистрированного имени. Когда требуется расширение кластера, новые узлы добавляются под существующим именем кластера. Администраторам не нужно управлять большим количеством информации о узлах в кластере.

Особенности

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

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

В Tseer при вызове главного вызывающего предлагаются четыре метода балансировки нагрузки для обеспечения равномерной нагрузки на все доступные узлы:

— циклический перебор; — случайный выбор; — статический вес; — согласованный хэш.

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

2. Отказоустойчивость

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

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

Для любого вызываемого узла агент Tseer/Api будет пытаться вызвать заблокированный узел каждые 30 секунд.

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

3. Оптимизация вызовов

Tseer предлагает три метода оптимизации вызовов: IDC группировка, Set группировка и All.

All предоставляет всем доступным адресам вызываемых узлов для главных вызывающих.

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

Для логических групп IDC Tseer определяет стратегию приоритета вызовов. Если некоторые логические группы недоступны, будут возвращены доступные адреса узлов вызываемых сервисов в соответствии со стратегией приоритета.

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

Правила вызова для Set группировки следующие:

1. главный вызывающий и вызываемый должны использовать одно и то же имя Set;
2. в пределах одного имени Set вызываемые сервисы в разных регионах имеют разные стратегии вызовов;
3. если главный вызывающий использует Set группировку, а вызываемый нет, то будет использоваться логика IDC группировки (при условии, что IDC группировка включена).

4. Два метода доступа

Доступ к Tseer может осуществляться двумя способами: через агент или API Tseer. Выбор зависит от наличия агента Tseer на хост-машине главного вызывающего.

Агент Tseer

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

Информация о вызове отправляется главному вызывающему после каждого вызова. Агент Tseer будет использовать эту информацию для удаления отказавших вызываемых сервисов из кэша.

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

API Tseer

Вместо агента Tseer на главном вызывающем, API Tseer напрямую обращается к Tseer server. Информация о вызываемом сервисе кэшируется, балансировка нагрузки и удаление отказавших сервисов выполняются в API Tseer.

API Tseer регулярно получает информацию с сервера Tseer и блокирует недоступные вызываемые сервисы.

При сбое Tseer server API Tseer вернёт кэшированную информацию главному вызывающему. При отсутствии кэша в памяти API Tseer восстановит его из файла на диске.