Skip to the content.

基础概念

本文主要介绍 TARS 平台中一些常见的基础概念, 弄清楚这些基础概念有助于对平台的使用, 这篇文档可以反复阅读, 如果第一次看不懂没有关系, 写完 helloworld, 再回来阅读文档会有不同的感受.

1. APP

APP 即应用名,标识一组服务的一个小集合, 开发者可以根据需要自己定义, 通常表示实现某个业务系统名称.

2. Server

Server 即服务名,提供服务的进程名称

3. Servant

Servant 即服务提供者, 提供了一个多个具体的接口(interface), 提供给客户端调用

Tars 采取这种三层结构, 尽可能的避免不同业务开发者开发的服务名称和 Servant 名称冲突

4. module

module 是 tars 协议文件中的关键字, 定义了协议的空间, 也对应了各语言名字空间(c++)或者包名(java, go)或模块(nodejs,php)

5. Tars 文件目录规范

Tars 文件是 TARS 服务的协议通信接口,尤其某 Tars Server 的客户端调用 Server 时都需要依赖该 Server 的 tars protocol 文件, 因此非常重要,在管理上我们推荐按照如下方式管理(当然你可以不采取该模式, 构建你自己合适的开发方式):

6. 服务端开发方式

任何 Tars 服务端和客户端的开发方式都基本一样:

正常情况下, 服务最终都通过 tarsweb 发布运行在 tars 平台上的各个节点服务器上, 但是在调试过程中希望在本机运行, 该如何处理?

服务启动实际上无非是一条命令行, 比如 c++服务是:

HelloServer --config=xxxxx.conf

这里配置 config 表示服务启动的配置文件, 在 tars 平台上是由 tarsnode 通过拉取模板配置生成的, 并拉起 HelloServer, 如果你想本地运行服务, 就必须本地具备这个配置文件.

注意:

注意这个配置文件不是业务配置, 而是服务框架的配置, 对应 tars 平台上的模板!

如何获取这个配置文件呢?

你可以先将服务发布到平台的某个节点上, 然后登陆节点服务器, 运行:

ps -efww | grep ${your server name}

你可以看到服务启动的命令行, 将对应的配置文件 copy 到本地, 并且打开配置文件, 修改配置文件里面对应 ip port 以及相关路径, 然后使用相同的命令行本地运行即可!

其他语言方式类似!

7. 客户端开发方式

完成服务端编写和启动后, 即可编写客户端, 通过引用 tars 文件生成的客户端代码, 并构建通信器, 使用通信器并根据 Servant 名称获取到对应的服务的代理对象, 使用代理对象完成通信.

注意:

Communicator *communicator = new Communicator();
HelloPrx helloPrx = communicator->stringToProxy<HelloPrx>("Test.HelloServer.HelloObj@tcp -h xxx -p yyy:tcp -h www -p zzz");
helloPrx->call();
Communicator *communicator = new Communicator();
communicator->setProperty("locator", "tars.tarsregistry.QueryObj@tcp -h xxxx -p 17890");
HelloPrx helloPrx = communicator->stringToProxy<HelloPrx>("Test.HelloServer.HelloObj");
helloPrx->call();

这种客户端调用方式, 虽然服务可以寻址和容灾, 但是没有上报信息, 如果需要上报信息还需要指定其他相关属性, 比如:

communicator->setProperty("stat", "tars.tarsstat.StatObj");
communicator->setProperty("property", "tars.tarspropery.PropertyObj");

当然你可以直接用配置文件来初始化通信器, 参考 web 平台模板配置中的 client 部分. 另外上报服务这里类同, 如果没有 locator 指定框架的主控地址, 你就需要自己指定上报的 ip port.

8 模板配置

web 平台上, 运维管理中有模板配置, 模板配置对于框架非常重要, 需要去理解模板配置的作用.

每一个部署在 TARS 框架上的服务, 最终其实被框架发布到对应的节点了(tarsnode), 那么 tarsnode 在拉起这个服务时如何知道服务绑定的端口, 启动的线程数等信息呢? 答案就是通过: 模板配置

tarsnode 会去平台拉取服务对应的模板(服务部署时配置好的), 然后根据模板生成服务对应的配置, 并用这个配置启动服务.

注意不同语言使用的模板配置文件不同, 可以参考后续各语言的文档.

强烈建议你不需要修改框架自带的模板, 因为后续框架升级可能会修改这些模板内容, 如果你需要修改, 你可以继承该模板, 让你的服务使用继承的模板

模板配置请参考文档: 模板配置

9 业务配置

上一节讲到模板配置, 模板配置实际是 rpc server 用到的公用配置, 它是 tarsnode 生成的. 但是对于业务服务而言, 一般都有自己的配置信息, 这种配置我们称之为业务配置.

业务配置一般都在 web 平台上配置中心来管理, 使用方式如下:

业务配置具体使用可以参见业务配置

10 日志系统

业务服务中通常也需要打印日志, 框架也提供了集中的日志中心.

通常日志分两类:

通过日志 api, 你可以将日志直接输出到远程的日志中心上, 即 tarslog 所在机器上(日志路径为: /usr/local/app/tars/remote_app_log)

所有语言的框架都提供了远程日志的 api.

另外在 web 平台上, 点击服务详情界面, 点击服务名称, 也可以快速查看到服务的本机日志.

11 开发调试发布

如果开发过程中, 每次都需要手工发布到 web 平台调试, 调试效率是非常低, 因此 Tars 平台提供了一个方式, 能够一键发布服务到 Tars 框架上.

使用方式如下:

curl http://${your-web-host}/api/upload_and_publish?ticket=${token} -Fsuse=@HelloServer.tgz -Fapplication=Test -Fmodule_name=HelloServer -Fcomment=dev

注意替换你的 token

c++版本的 cmake 已经内嵌了命令行在服务的 CMakeLists.txt 中, 比如用 cmake_tars_server.sh 创建服务之后, 只需要:

cd build
cmake .. -DTARS_WEB_HOST=${WEB_HOST} -DTARS_TOKEN=${TOKEN}
make HelloServer-tar
make HelloServer-upload

即可完成服务的上传和发布(提前需要在 web 平台配置好)

注意:

12 部署和扩容

通过使用TARS框架后, 你可以通过tarsweb来完成服务的部署和扩容, 注意: