运维与微服务结合?深度解析微服务框架Tars整体解决方案
内容导航
- 什么是Tars?
- Tars框架源码部署
- Tars服务部署管理
- Tars配置中心
- Tars服务发现
- Tars远程日志
- Tars状态监控
什么是Tars
Tars框架源码部署
部署环境
- Docker环境安装
- Mysql安装
- Linux/Mac源码部署
- Windows源码部署
- TarsDocker部署
- K8s Docker部署
- TarsNode部署
依赖环境
|
软件
|
软件要求
|
|
linux内核版本
|
2.6.18及以上版本(操作系统依赖)
|
|
gcc版本
|
4.8.2及以上版本、glibc-devel(C++语言框架依赖)
|
|
bison工具版本
|
2.5及以上版本(C++语言框架依赖)
|
|
flexl具版本
|
2.5及以上版本(C++语言框架依赖)
|
|
cmake版本
|
3.2及以上版本(C++语言框架依赖)
|
|
mysql版本
|
4.1.17及以上版本(框架运行依赖)
|
|
nvm版本
|
0.35.1及以上版本(web管理系统依赖,脚本安装过程中自动安装)
|
|
node版本
|
12.13.0及以上版本(web管理系统依赖,脚本安装过程中自动安装)
|
Tars服务部署管理
- 部署过程有生命周期完整的页面交互
- 零配置或配置模板化,页面配置化操作执行文件,部署服务
- 部署后可以在页面上进行验证,并在页面上查看服务的运行状态以及产生的日志,方便问题的排查上报
- 版本管理页面直观可见,可以进行版本的升降级
- VPN或公网网络互通后,可以实现远程部署
- 部署过程无需技术背景,操作简单
- 部署方案可以跨平台
服务发布架构实现
- tars patch 组件将war包上传到 patch 目录 (/usr/local/app/patch/tars.upload/)
- tars注册中心通知node拉取对应的包到本地
- 启动对应的服务
- 服务启动后web页面可以查看启动状态
- 服务启动后web页面可以通过流式日志查看服务的启动日志.
灰度发布
熔断策略
服务发布
-
运维管理
服务部署
-
模版管理
-
发布管理
-
服务管理
-
框架检查
Tars服务发布与传统服务发布对比
|
对比项
|
Tars服务发布
|
传统服务发布
|
|
服务发布
|
页面可视化,傻瓜式操作
|
ssh远程登录,上传文件,脚本启 动服务
|
|
服务升级
|
页面上传war包,选择war包发布
|
与服务发布冋样流程,但要考虑历史文件的备份
|
|
服务降级
|
页面选择对应的版,发布
|
如果有备份文件,还原服务包文件, 脚本启动,没有备份文件,需要源码回滚打包上传,再通过脚本启动
|
|
需要技能
|
不需要
|
一定的运维经验,服务器操作, shell脚本的编写
|
|
集群发布
|
选择多个节点,发布
|
需要将包copy到对应的机器,重新启动服务
|
Tars配置中心
- 对业务配置进行集中管理并且提供操作页面,使配置修改更容易,通知更及时,配置变更也更安全;
- 对配置变更进行历史记录,让配置可以轻松回退到前一版本。
- 配置拉取简单,服务只需调用配置服务的接口即可获取到配置文件。
- 能灵活管理配置文件,配置文件分为几个级别:应用配置、Set配置、服务配置和节点配置。
配置信息维护
- t_config_files表的主要信息:服务配置文件名称、配置文件类型、配置文件所属服务名,配置文件所属set分组,配置文件所属节点ip以及配置文件的索引id值以及该服务所在set分组信息。
- t_config_references表的主要信息:配置文件的索引id以及该id所引用的配置文件索引id。
服务配置
Tars服务发现
- 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的嵌套。
寻址方式
调用方式
- 同步调用:客户端发出调用请求后等待服务返回结果后再继续逻辑。
- 异步调用:客户端发出调用请求后继续其他业务逻辑,服务端返回结果又由回调处理类 处理结果。
- 单向调用:客户端发出调用请求后就结束调用,服务端不返回调用结果。
服务注册
- 简单易用:对开发者透明
- 高可用:几台注册中心坏掉不会导致整个服务瘫痪,注册服务整体持续可用
- 避免跨越机房调用:最好调用优先同一个机房的服务以减少网络延迟
- 跨语言:允许开发者使用多种编程语言构建微服务
- 负载均衡:负载均衡支持轮询、hash、权重等多种方式。
- 容错保护:名字服务排除和Client主动屏蔽。
客户端实现原理
服务端实现原理
Tars调用链
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
- 引入开源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统计信息
Tars特性监控
obj = property.create('name', [new property.POLICY.Count, new property.POLICY.Max]);
obj.report(value)
Tars服务监控
- 应用服务SDK会定期上报心跳。
- Node服务会定期检查SDK的心跳超时。
- Node服务会定期检测服务进程是否存在。
更多福利