这里只是简单介绍一下，引个路，具体介绍可以看官方文档。
先抄一段官方文档。
TARS 是 Linux 基金会的开源项目，它是基于名字服务使用 TARS 协议的高性能 RPC 开发框架，配套一体化的运营管理平台，并通过伸缩调度，实现运维半托管服务。该框架为用户提供了涉及到开发、运维、以及测试的一整套解决方案，帮助一个产品或者服务快速开发、部署、测试、上线。 它集可扩展协议编解码、高性能 RPC 通信框架、名字路由与发现、发布监控、日志统计、配置管理等于一体，通过它可以快速用微服务的方式构建自己的稳定可靠的分布式应用，并实现完整有效的服务治理。
对于tars的搭建，这里不打算介绍，官方文档有详细步骤。

框架

先给个整体框架图

这里介绍几个关键的组件

服务节点Node

服务节点可以认为是服务所实际运行的一个具体的操作系统实例，可以是物理主机或者虚拟主机、云主机。随着服务的种类扩展和规模扩大，服务节点可能成千上万甚至数以十万计。一个节点中可以有多个业务服务Server，Node服务节点会对业务服务节点进行统一管理，提供启停、发布、监控等功能，同时接收业务服务节点上报过来的心跳。

公共框架节点Framework

公共框架节点，数量不定，为了自身的容错容灾，一般也要求在在多个机房的多个服务器上进行部署，具体的节点数量，与服务节点的规模有关，比如，如果某些服务需要打较多的日志，就需要部署更多的日志服务节点。
介绍期中考两个

Web管理系统

在Web上可以看到服务运行的各种实时数据情况，以及对服务进行发布、启停、部署等操作。
用户登录成功后，会进入Tars管理系统。

注意如果是云服务器，记得开放3000端口。

路由+管理服务Registry

可以理解为DNS，提供服务节点的地址查询、发布、启停、管理等操作，以及对服务上报心跳的管理，通过它实现服务的注册与发现。

服务交互流程

这里直接抄官方文档了，写得比较详细。
框架服务在整个系统中运行时，服务之间的交互分：业务服务之间的交互、业务服务与框架基础服务之间的交互。

• 服务发布流程：在Web系统上传server的发布包到patch，上传成功后，在web上提交发布server请求，由registry服务传达到node，然后node拉取server的发布包到本地，拉起server服务。
• 管理命令流程：Web系统上的可以提交管理server服务命令请求，由registry服务传达到node服务，然后由node向server发送管理命令。
  心跳上报流程：server服务运行后，会定期上报心跳到node，node然后把服务心跳信息上报到registry服务，由registry进行统一管理。
• 信息上报流程：server服务运行后，会定期上报统计信息到stat，打印远程日志到log，定期上报属性信息到property、上报异常信息到notify、从config拉取服务配置信息。
  Client访问Server流程：client可以通过server的对象名Obj间接访问server，Client会从registry上拉取server的路由信息（如ip、port信息），然后根据具体的业务特性（同步或者异步，tcp或者udp方式）访问server(当然client也可以通过ip/port直接访问server)。

tars协议

Tars 语言是一种类 c++标识符的语言，用于生成具体的服务接口文件。Tars 文件是 Tars 框架中客户端和服务端的通信接口，通过 Tars 的映射实现远程对象调用。Tars 文件的扩展名必须以.tars 为扩展名。
对于结构定义，可以支持扩展字段，即可以增加字段而不影响原有结构的解析，可以在存储/协议等地方单独使用，大小写敏感。

第一列数字表示该字段的标识（tag），无论结构增减字段，该字段得值都不变，必须和响应的字段对应，Tag 的值必须要>=0 且<=255；
第二个字段，图上已经写出来了，require 表示该字段必选，optional 表示该字段可选。对于 optional 字段，可以有一个缺省值，缺省值在编码时默认不打包。
剩下的字段就不说明了。

负载均衡

tars实现了负载均衡，提供三种方式，根据不同的需求选择不同的方式。

关于架构，还有很多可以介绍的东西，比如容错、过载等，这些在官方文档中写得很清楚，就不再赘述了，再写下去，可能还是在抄官方文档。当然，如果想要详细了解，还需要自己对照源码。