APP
APP即应用名,标识一组服务的一个小集合, 开发者可以根据需要自己定义, 通常表示实现某个业务系统名称。
-
在Tars系统中,应用名必须唯一, 例如:TestApp
-
通常应用名对应代码中的某个名字空间
-
tars 这个应用名是框架使用的, 业务服务请不要使用
Server
Server即服务名,提供服务的进程名称。
- Server名字根据业务服务功能命名, 它会在TARS web平台上左边服务树上展示
- 一个Server必须属于某个App, App下的Server名称都具备唯一性
- 一般命名为:XXServer,例如LogServer,TimerServer等
- 一个Server代表一个独立的程序, 绑定至少一个ip, 实现一组相关的接口
Servant
Servant即服务提供者, 提供了一个多个具体的接口(interface), 提供给客户端调用
- Servant对应服务代码中一个类, 继承于tars协议文件中的interface(内涵多个具体的函数), 由业务开发者实现
- 一个Servant必须属于某个Server, Server下的Servant名称都具备唯一性
- Servant需要一个名称, 比如: HelloObj, 当提供给客户端使用的, 全称是: App.Server.Servant, 比如: Test.HelloServer.HelloObj
- 客户端调用Server时, 只需要指定Servant的名称即可完成远程通信(如何实现后续会介绍)
Tars采取这种三层结构, 尽可能的避免不同业务开发者开发的服务名称和Servant名称冲突
module
module是tars协议文件中的关键字, 定义了协议的空间, 也对应了各语言名字空间(c++)或者包名(java, go)或模块(nodejs,php)
Tars文件目录规范
Tars文件是TARS服务的协议通信接口,尤其某Tars Server的客户端调用Server时都需要依赖该Server的tars protocol文件, 因此非常重要,在管理上我们推荐按照如下方式管理(当然你可以不采取改模式, 构建你自己合适的开放方式):
- tars文件原则上和相应的server放在一起;
- 每个server在开发机上建立/home/tarsproto/[namespace]/[server]子目录;
- 所有tars文件需要更新到/home/tarsproto下相应server的目录;
- 使用其他server的tars文件时,需要到/home/tarsproto中使用,不能copy到本目录下;
- 如此, 在相同服务器上开发服务时, 你只需要将tars文件release到该目录下, 就能方便其他调用方使用
- tars的接口原则上只能增加,不能减少或修改
- 各语言提供的Tars服务框架, 都提供了快速release tars文件到/home/tarsproto/[namespace]/[server]下的工具
服务端开发方式
任何Tars服务端和客户端的开发方式都基本一样:
- 确定APP, Server, Servant名称
- 编写tars文件, 定义服务对外提供的interface以及interface下面