Overview of Tars: A High‑Performance RPC Framework and Service Governance Platform

Tars is a high‑performance RPC development framework based on a name service using the Tars protocol, accompanied by an integrated service governance platform that enables individuals and enterprises to quickly build stable, reliable distributed applications using microservices.

Design Philosophy

Tars adopts a microservice‑oriented design, abstracting system modules into layered components to achieve loose coupling. The architecture separates the protocol layer, common libraries and communication framework, and the operation layer, each focusing on specific responsibilities.

Overall Architecture

Architecture Topology

The topology consists of two main parts: service nodes and common framework nodes.

Service Nodes: Physical, virtual, or cloud hosts where services run. Each node hosts a Node service and multiple business service instances, with the Node managing lifecycle, deployment, monitoring, and heartbeat collection.

Common Framework Nodes: Shared services such as the Web management system, Registry (service discovery), Patch (deployment), Config (configuration center), Log (remote logging), Stat (call statistics), Property (custom metrics), and Notify (exception alerts). These nodes are deployed across multiple data centers for fault tolerance.

Features

Tars Protocol

The Tars protocol uses an Interface Description Language (IDL) to define services, generating binary, extensible, cross‑platform code for RPC communication. It supports basic types (void, bool, int, etc.) and complex types (enum, struct, vector, map) with nesting.

Invocation Modes

Three call modes are supported: synchronous (client waits for response), asynchronous (client proceeds while a callback handles the response), and one‑way (client sends request without expecting a reply).

Load Balancing

Clients obtain service address lists from the name service and can select load‑balancing strategies such as round‑robin, hash, or weighted distribution.

Fault Tolerance

Fault tolerance is achieved via name‑service exclusion (removing failed nodes from address lists based on heartbeat) and client‑side shielding (blocking nodes that exhibit high timeout rates).

Overload Protection

Requests are queued and processed asynchronously; the queue length is monitored, and excess requests are rejected. Requests exceeding a timeout threshold are discarded.

Message Coloring

Specific requests can be “colored” so that all downstream services tag logs accordingly, enabling end‑to‑end tracing of particular flows.

IDC Grouping

Supports cross‑region and cross‑data‑center near‑site access to reduce latency and network consumption.

SET Grouping

Provides isolated deployment groups (sets) without inter‑set calls, enhancing fault isolation and operational efficiency.

Data Monitoring

Offers comprehensive metrics reporting, including service call statistics, custom attribute data, and service state/exception logs, with visual dashboards for traffic, latency, error rates, and resource usage.

Centralized Configuration

Configuration files are managed centrally via a web interface, supporting hierarchical levels: application, set, service, and node configurations, with versioning and rollback capabilities.

Project Address

Open‑source repository: https://gitee.com/TarsCloud/Tars