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)

基本用法

既然是协议，就有一套成熟的标准，不断迭代、向前向后兼容–这就是大厂的硬实力，淦（但文档确实一般般）：

1. 基本数据

   支持的数据类型：

   • 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作为多语言间通信的数据协议。

2. 复杂数据类型： 自己可以定义的数据类型

   有 枚举、常量、结构体、 序列 、 字典 具体可看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 + mapstruct 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;  // 双重Map2 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：

1. 可读、性能好像也没那么不好，只是相对于二进制的会慢一点，who care，现代的Web服务架构和硬件已经能够很好地处理大量的JSON数据，性能损失可以通过其他手段（如缓存、数据压缩）来缓解。
2. 复杂性：使用JSON作为数据格式，开发者可以利用标准的HTTP工具和库来处理数据，而无需依赖于特定的序列化和反序列化工具。
3. 易用性：JSON作为一种文本格式，很容易处理各种编码和字符集的问题，这使得它在不同平台和编程环境之间具有很好的兼容性。而二进制格式可能需要处理字节顺序、对齐方式等底层细节，这在跨平台交互时可能导致问题。
4. 开放性：JSON作为一种开放标准，在Web开发中有广泛的文档和最佳实践指导。而Protobuf、Tars虽然也有文档，但相对较少，且通常与特定实现或框架相关，这在一定程度上限制了它们的通用性。