3 TarsUP协议
统一通信协议 TarsTup | TarsDocs (tarscloud.github.io)
TarsDocs/base at master · TarsCloud/TarsDocs (github.com) : 有关于tars的所有介绍
每一个rpc调用双方都约定一套数据序列化协议,gprc用的是protobuff,tarsgo是统一通信协议 TarsTup。
tup语法:TarsDocs/base/tars-protocol.md at master · TarsCloud/TarsDocs (github.com)
基本用法
既然是协议,就有一套成熟的标准,不断迭代、向前向后兼容–这就是大厂的硬实力,淦(但文档确实一般般):
-
基本数据
支持的数据类型:
- bool
- byte: 8位
- short: 最高支持到16位
- int: 32位
- long: 64位
- float: 32位,
float
在大多数现代编程语言和协议中通常都是指 IEEE 754 标准的单精度浮点数,占用 4 个字节。 - double:64位,
double
类型遵循 IEEE 754 标准的双精度浮点数格式,通常占用 8 个字节。 - string:不定长,
string
类型用于表示字符串数据。在 Tars 中,字符串是动态大小的,可以根据实际存储的内容变化其长度。存储时通常会先存储一个长度字段(可能是 32 位整数),然后是字符串本身的字节。 - unsigned byte:8位,
unsigned byte
表示无符号字节,范围从 0 到 255。这相当于在 C++ 或 Java 中的unsigned char
和go 的byte - unsigned short:32位,
unsigned short
是一个无符号的短整型数据,范围从 0 到 65535,占用 2 个字节。 - unsigned int:64位,
unsigned int
表示一个无符号的整型数据,范围从 0 到约 4.29 亿(2^32 - 1),占用 4 个字节。
以上数据类型,在各种语言大部分都有相对应的实现,这也可以使用tars作为多语言间通信的数据协议。
-
复杂数据类型: 自己可以定义的数据类型
有 枚举、常量、结构体、 序列 、 字典 具体可看TarsDocs/base/tars-protocol.md at master · TarsCloud/TarsDocs (github.com)
一个例子:
// 命名空间 module AiGo{ // 枚举 enum TE{ E1 = 1, E2, E3 }; // 常量 const int a = 1; const string s = "abc"; // 结构体 + vector + map struct Test{ 0 require string s; 1 optional int i = 23; 2 require vector<int> vi; 3 require map<int, string> m; }; // 具体的接口--》可以调用的服务 interface MathService{ // 具体可以调用的方法。 void add(int a, int b, out int c); int Test1(int a, Test test, out int c); // }; //嵌套 struct demo1{ 0 require Test test; // 嵌套结构体 1 require map<int , map<int, string>> doubleMap; // 双重Map 2 require vector<vector<vector<int>>> triVector; // 三重Vector }; };
转化成go语言版本:
tars2go -outdir=tars-protocol -module="github.com/ajwlforever/AiGo" .\demo.tars
生成这俩文件
demo.go
和MathService.tars.go
就可以直接用了,当然这俩文件全是抽象的实现,底层数据的实现。–》具体方法内逻辑实现要初始化并绑定具体的实现// 具体的实现 初始化 imp := new(InterfaceImp) err := imp.Init() .... // New servant app := new(AiGo.Demo1) // servant 绑定具体的实现 app.AddServantWithContext(imp, cfg.App+"."+cfg.Server+".InterfaceObj")
协议对比
既然是数据序列化协议,那就要做一个对比,为什么腾讯自己造了一个自己的。
常见的数据序列协议有 xml、json、protobuf
首先最大的区别是 xml、json都是文本格式的,空间占比大,但由于其良好的可读性,也是广泛应用于restful风格的接口返回中。
protobuf和tarsup都是基于二进制直接定义的,数据的编码与解码都是更高效的,但是这种编码解码都需要额外的支持,而restful适用于几乎一切平台。
尽管Protobuf和Tars在技术性能上有优势,JSON在易用性、灵活性和广泛支持等方面的优势使其成为大多数HTTP接口首选的数据格式。对于需要高性能和高效数据编码的内部系统或微服务间通信,Protobuf和Tars仍然是非常合适的选择
总的来说,为什么http接口首选json:
- 可读、性能好像也没那么不好,只是相对于二进制的会慢一点,who care,现代的Web服务架构和硬件已经能够很好地处理大量的JSON数据,性能损失可以通过其他手段(如缓存、数据压缩)来缓解。
- 复杂性:使用JSON作为数据格式,开发者可以利用标准的HTTP工具和库来处理数据,而无需依赖于特定的序列化和反序列化工具。
- 易用性:JSON作为一种文本格式,很容易处理各种编码和字符集的问题,这使得它在不同平台和编程环境之间具有很好的兼容性。而二进制格式可能需要处理字节顺序、对齐方式等底层细节,这在跨平台交互时可能导致问题。
- 开放性:JSON作为一种开放标准,在Web开发中有广泛的文档和最佳实践指导。而Protobuf、Tars虽然也有文档,但相对较少,且通常与特定实现或框架相关,这在一定程度上限制了它们的通用性。