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虽然也有文档，但相对较少，且通常与特定实现或框架相关，这在一定程度上限制了它们的通用性。
