Tars 迁移微服务选型

当前 Tars 框架面临的主要问题

1. 使用传统的云主机进行部署，不具备伸缩条件，成本高；隔离性差，当单个服务的 CPU、负载等出现问题时，极易引发问题扩散；
2. 熔断、限流等能力在框架层没有统一的实现，现在依靠 go 和 java 项目的各自配置，使用繁琐且容易出错；
3. CI / CD 流程过于粗暴，发布过程中不能做到服务真正的无损下线，发布时间长、无记录，底层库修改时需要花费大量人力进行服务发布；
4. 监控系统存在天然缺陷，只有 5 分钟维度的监控，有问题不能及时发现和定位，且迁移到弗吉尼亚后监控面板很多功能实质上处于无法使用的状态；
5. 告警系统在新版本 Tars 中独立组建，配置麻烦且使用低效，当前的告警实质上依赖 grafana 和腾讯云本身；
6. 链路追踪能力缺失，遇到超时等问题难以定位发生问题的位置（海外使用了自定义拦截器，但是未进行推广），链路追踪无宏观层面监控；
7. 使用 C++ 开发且社区不活跃，遇到问题既难以自己解决，也无法寻求帮助；
8. 日志不统一，有各种各样服务自定义的日志格式，加大了日志收集和查询的难度。

可选方案

更换为主流 RPC 框架，如 Dubbo、gRPC

现在主流的微服务都选取了 protobuf 协议，但是 protobuf 协议不兼容 tars 协议，主要体现在以下方面：

• 常量类型不支持，数字常量可以考虑转为枚举类型支持，字符串常量协议层面没有可以代替的实现
• 不同枚举类型中的枚举值名称不能相同
• 复杂类型如 map[string]map[string]int、vector<vector<int>> 、map[string]vector<int> 类型不支持，需要额外构造 message
• Protobuf 的入参和出参都只有一个
  

  message addAuthorMessageRequest {
    common.InParam inParam = 1;
    AuthorMessage message = 2;
  }
  
  message addAuthorMessageResponse {
    common.OutParam outParam = 3;
  }
  
  rpc addAuthorMessage(addAuthorMessageRequest) returns (addAuthorMessageResponse);

  void addAuthorMessage(common::InParam inParam, AuthorMessage message, out common::OutParam outParam);

Idea 系列的 Jce 插件中提供了将 tars 协议转为 protobuf 的能力。

我也自己实现了一个 tars2proto。

目前看区别在于：

1. Jce 插件中对 include 没有转换为 import，而是直接将 include 的结构生成在了当前 proto 结构中
2. Tag 映射关系
3. 常量支持
4. 字符串枚举支持
5. Jce 插件不支持复杂类型的自动生成。

Tars + K8sTars + Istio TCP 代理

K8sTars 的 Tarscli 通过一系列命令，实现了服务的注册、下线和健康检查等能力。

优势：无需修改代码，仅新增部分配置文件和运维工作。

1. 代码框架未更换，意味着现有框架如果有问题无法解决
2. TarsCli 开发于 4 年前，后续没有任何的更新
3. 发布慢的问题无法解决，由于 tars 未在各个语言实现平滑下线，每次发布都需要等待节点刷新服务列表后才可以终止流量。
4. 由于没有 tarsnode 的存在，tars 的服务列表中状态不正常。

1. 监控体系存在的问题依然需要解决。

Tars + Tars 协议 Sidecar

1. 代码框架未更换，意味着现有框架如果有问题无法解决
2. 需要定制 7 层 tars 协议 filter

使用 tRPC

已经验证过 tRPC 原生支持 tars.

待研究

1. 服务如何双向注册
2. 服务的发布机制
3. 脱离 123 平台需要额外做哪些工作