运维与微服务结合？深度解析微服务框架 Tars 整体解决方案

2022 年 2 月 10 日
本文字数：4537 字
阅读完需：约 15 分钟

内容导航
什么是 Tars？
Tars 框架源码部署
Tars 服务部署管理
Tars 配置中心
Tars 服务发现
Tars 远程日志
Tars 状态监控

什么是 Tars

Tars 是一个支持多语言内嵌服务治理功能的框槛，能与 DevOps 比较好的协同开发。提供了包含开发、运维、以及测试的一整套解决方案。Tars 集可扩展协议编解码、高性能 RPC 通信框架、名字路由与发现、发布监控、日志统计、配置管理等于一体，通过 Tars 可快速用微服务的方式构建自己高可用的分布式应用，并实现完整有效的服务治理。总体来讲，Tars 是一个跨平台、跨语言的软件运行环境，是基于 service mesh 设计理念实现的开发框架。

Tars 框架源码部署

注：用 CentOS7 部署，CentOS6 需升级 glic

部署环境

Docker 环境安装
Mysql 安装
Linux/Mac 源码部署
Windows 源码部署
TarsDocker 部署
K8s Docker 部署
TarsNode 部署

依赖环境

Tars 服务部署管理

部署过程有生命周期完整的页面交互
零配置或配置模板化，页面配置化操作执行文件，部署服务
部署后可以在页面上进行验证，并在页面上查看服务的运行状态以及产生的日志，方便问题的排查上报
版本管理页面直观可见，可以进行版本的升降级
VPN 或公网网络互通后，可以实现远程部署
部署过程无需技术背景，操作简单
部署方案可以跨平台

服务发布架构实现

tars patch 组件将 war 包上传到 patch 目录 (/usr/local/app/patch/tars.upload/)
tars 注册中心通知 node 拉取对应的包到本地
启动对应的服务
服务启动后 web 页面可以查看启动状态
服务启动后 web 页面可以通过流式日志查看服务的启动日志.

灰度发布

Tars 支持灰度发布，具体可查看下图

熔断策略

当客户端和服务端需要交互时，可在注册中心拉取路由。客户端从注册中心拉取到注册信息之后可以根据内部对服务的判断决定请求什么服务。

服务发布

运维管理

服务部署

模版管理

发布管理

服务管理

框架检查

Tars 服务发布与传统服务发布对比

Tars 配置中心

配置中心提供服务配置文件的统一管理功能。是实时更新配置文件、push 配置文件到服务、服务主动 pull 配置文件的统一管理中心。主要包含以下优点：

对业务配置进行集中管理并且提供操作页面，使配置修改更容易，通知更及时，配置变更也更安全；
对配置变更进行历史记录，让配置可以轻松回退到前一版本。
配置拉取简单，服务只需调用配置服务的接口即可获取到配置文件。
能灵活管理配置文件，配置文件分为几个级别：应用配置、Set 配置、服务配置和节点配置。

配置信息维护

tars 框架通过两个数据表（存在 mysq I 中）来维护这些配置信息：t_config_file s 和 t_config_references。

t_config_files 表的主要信息：服务配置文件名称、配置文件类型、配置文件所属服务名，配置文件所属 set 分组，配置文件所属节点 ip 以及配置文件的索引 id 值以及该服务所在 set 分组信息。
t_config_references 表的主要信息：配置文件的索引 id 以及该 id 所引用的配置文件索引 id。

服务配置

tars web 管理系统上添加配置、添加引用文件、 push 配置文件到服务。配置文件会被推到相应的目录下。

服务代码中 pull 配置文件到本地。

Tars 服务发现

Tars 协议采用接口描述语言(Interface description language,缩写 IDL)来实现，它是一种二进制、可扩展、代码自动生成、支持平台的协议，使得在不同平台上运行的对象和用不同语言编写的程序可以用 RPC 远程调用的方式相互通信交流，主要应用在后台服务之间的网络传输协议，以及对象的序列化和反序列化等方面。注册中心主要涉及到三大角色: 服务提供者、服务消费者、注册中心。

Tars 通过名字服务来实现服务的注册与发现
Client 通过访问名字服务获取到被调服务的地址信息列表
Client 再根据需要选择合适的负载均衡方式来调用服务

数据结构

协议支持的类型分两种，基本类型和复杂类型。

基本类型包括：void、bool、byte、short、int、long、float、double、string、unsigned byte、unsigned short、unsigned int。
复杂类型包括：enum、const、struct、vector、map，以及 struct、vector、map 的嵌套。

寻址方式

自动寻址：客户端 Endpoint 注册表的缓存更新周期，主动方式（周期刷新一分钟，refreshEndpointInterval）自动寻址用的负载均衡算法（包含多种）

直接寻址：可以通过手动填写 IP port 实现直接寻址，调试特殊场景下使用

调用方式

通过 IDL 语言协议，可以定义服务提供的接口，并自动生成客户端和服务端的相关通信代码，服务端只需实现业务逻辑即可对外提供服务，客户端通过自动生成的代码即可调用服务，调用方式支持以下三种模式：

同步调用：客户端发出调用请求后等待服务返回结果后再继续逻辑。
异步调用：客户端发出调用请求后继续其他业务逻辑，服务端返回结果又由回调处理类处理结果。
单向调用：客户端发出调用请求后就结束调用，服务端不返回调用结果。

Tars 文件定义结构演示

服务注册

Tars 服务注册优点：

简单易用：对开发者透明
高可用：几台注册中心坏掉不会导致整个服务瘫痪，注册服务整体持续可用
避免跨越机房调用：最好调用优先同一个机房的服务以减少网络延迟
跨语言：允许开发者使用多种编程语言构建微服务
负载均衡：负载均衡支持轮询、hash、权重等多种方式。
容错保护：名字服务排除和 Client 主动屏蔽。

名字服务排除的策略：

业务服务主动上报心跳给名字服务，使名字服务知道服务部署的节点存活情况，当服务的某节点故障时，名字服务不在返回故障节点的地址给 Client，达到排除故障节点的目标。名字服务排除故障需要通过服务心跳和 Clien 地址列表拉取两个过程，故障排除时间在 1 分钟左右。

Client 主动屏蔽：

为了更及时的屏蔽故障节点，Client 根据调用被调服务的异常情况来判断是否有故障来更快进行故障屏蔽。具体策略是，当 client 调用某个 svr 出现调用连续超时，或者调用的超时比率超过一定百分比， client 会对此 svr 进行屏蔽，让流量分发到正常的节点上去。对屏蔽的 svr 节点，每隔一定时间进行重连，如果正常，则进行正常的流量分发。

页面上手动上传进行的注册，注册到了 mysql.也可以通过 Web API 实现自动上传和部署

服务注册过程如下图所示:

服务发现过程如下图所示：

客户端实现原理

服务端实现原理

Tars 调用链

在 Tars 管理平台上选中要开启调用链的服务，点击“编辑”

最终效果如下图所示：

点开单词调用链查看详细信息

Tars 远程日志

Tarslog 是 Tars 日志服务，基于 Logback 作为日志系统，用于将日志内容打到本地或远程服务器，并且支持服务内日志调用链路追踪以及日志染色。

Tarslog 提供了十分灵活的配置项，可以为用户提供更加强大的日志功能。

Tars 内置的远程日志功能是以 logback 插件的模式存在，只需将插件引入到 logback 配置文件即可，配置简单，并且可自定义日志打印到本地以及远程。

Tars 日志模块可通过 MDC 实现服务内日志链路跟踪以及自定义日志染色。MDC 内部持有一个 ThreadLocal 对象，其中存储了一个 Map，因此用户可以根据需要向其中添加键值对。

Tars 日志模块通过配置可支持高可用。

日志打印

流程如下图所示：

官网（https://github.com/TarsCloud/TarsJava）下载源码
通过 mvn package 命令将 TarsJava 下的 tars-plugins 打成 jar 包
将打好的 jar 包放入到工程中。
配置 logback 文件，添加 appender。如图配置
代码中通过 Logger logger = LoggerFactory. getLogger("root")获取 Iogger 对象。
通过 logger.debug("message")打印日志，此时日志会打印到第四步附图中 logserverObjname 配置的 Iogserver 中；

MDC 服务内日志链路跟踪

MDC 内部持有一个 ThreadLocal 对象，在单个线程处理的请求链路中，通过 MDC. put(“traceId", value)设置调用链路 ID。
在 logback 配置文件中利用 pattern 获取 traceld，如下图配置:。
此时单个请求链路中打印的所有日志已经包含第一步中 MDC 中 put 的 traceId 所对应的值。

MDC 日志染色

通过实现 ForegroundCompositeConverterBase<ILoggingEvent> 接口封装染色 conversionRule。如下图所示：

配置 logback.xml 文件，增加 conversionRule 标签，指向第一步封装的染色 conversionRule 类，并在输出远端日志的 Appender 中使用此染色规则。如下图所示：

logback 整合 Kafka

方式 1：手写 Appender

引入 Kafka jar 包，导入到项目中。
手写 Appender 实现日志发送到 Kafka。
配置 logback.xml。

方式 2：开源 jar

具体请参考资料：https://github.com/danielwegener/logback-kafka-appender

引入开源 jar 包，导入到项目中。

</dependency><groupld>com.github.danielwegener</groupld><artifactld>logback-kafka-appender</artifactld><version>0.2.0</version><scope>runtime</scope></dependency>

配置 logback.xml,配置 kafkaAppender,以及 kafka 信息(host, topic 等)。
把 kafkaAppender 放到日志输出。

<root level="lNFO"><appender-ref ref="kafkaAppender"/></root>

总结

目前远程日志服务不支持跨服务日志链路追踪，需要 zipkin 实现链路追踪。Tars 已经集成 zipkin）
可配置多台远程日志服务地址，实现咼可用。
可基于 Logback 做功能的横向扩展。

Tars 状态监控

为了更好反映和监控小到服务进程、大到业务的运行质量情况，框架支持以下数据上报的功能：

提供了服务模块间调用信息统计上报的功能。方便用户查看服务的流量、延时、超时、异常等情况。
提供了用户自定义属性数据上报的功能。方便用户查看服务的某些维度或者指标，比如内存使用情况、队列大小、cache 命中率等。
提供了服务状态变更和异常信息上报的功能。方便用户查看服务的何时发布过、重启过、宕过以及遇到的异常致命错误等。

Tars 统计信息

统计信息包含访问次数、耗时、异常和耗时。统计及聚合由各语言框架 SDK 提供，无论成功与否，框架 SDK 都将会上报。

上报统计信息是向 Tars 框架内的 tarsstat 上报耗时信息和其他信息。无需用户开发，只需在程序初始化期间正确设置相关信息后，就可以在框架内自动报告。

客户端调用上报接口后，会暂时将信息存储在内存中，当到达某个时间点时，会向 tarsstat 服务上报（默认为 1 分钟上报一次）。两个上报时间点之间的时间间隔称为统计间隔，在统计间隔中会执行诸如聚合和比较相同 key 的一些操作。

Tars 特性监控

特性监控上报的是服务脚本的自定义特性，它由特性名、特性值、以及统计方法构成，类似指标监控。每种语言 SDK 有默认的特性监控指标，比如 JAVA 默认包含 jvm.memory, jvm.gc 等。

也可以自定义拓展：

obj = property.create('name', [new property.POLICY.Count, new property.POLICY.Max]);obj.report(value)

Tars 服务监控

集群中所有机器都有 Node 服务用于管理应用，Node 服务其中一个重要功能为服务监控。Node 服务通过开启一个监控线程，负责定时（时间间隔可以配置）轮询监控 Node 所管理的所有服务的运行状态，并定时向主控上报服务的运行状态。

应用服务 SDK 会定期上报心跳。
Node 服务会定期检查 SDK 的心跳超时。
Node 服务会定期检测服务进程是否存在。

创作场景