专栏名称: OSC开源社区
OSChina 开源中国 官方微信账号
目录
相关文章推荐
程序员小灰  ·  为何大多数程序员做不了独立开发者? ·  3 天前  
OSC开源社区  ·  微软Visual ... ·  4 天前  
OSC开源社区  ·  号称汽车上的Android、“装车量”超过2 ... ·  5 天前  
OSC开源社区  ·  MySQL亿级数据平滑迁移实战 ·  4 天前  
程序员的那些事  ·  娱乐圈大佬甩百度网盘链接,几十G资料首度曝光… ·  1 周前  
51好读  ›  专栏  ›  OSC开源社区

Tars:腾讯开源的高性能 RPC 开发框架 | 软件推介

OSC开源社区  · 公众号  · 程序员  · 2017-05-28 08:26

正文


授权协议:BSD

开发语言:Java、C/C++ 

操作系统:Linux

开发厂商:腾讯

链接:https://www.oschina.net/p/tars


 1. 介 绍 


Tars是基于名字服务使用Tars协议的高性能RPC开发框架,同时配套一体化的服务治理平台,帮助个人或者企业快速的以微服务的方式构建自己稳定可靠的分布式应用。


Tars是将腾讯内部使用的微服务架构TAF(Total Application Framework)多年的实践成果总结而成的开源项目。Tars这个名字来自星际穿越电影人机器人Tars, 电影中Tars有着非常友好的交互方式,任何初次接触它的人都可以轻松的和它进行交流,同时能在外太空、外星等复杂地形上,超预期的高效率的完成托付的所有任务。 拥有着类似设计理念的Tars也是一个兼顾易用性、高性能、服务治理的框架,目的是让开发更简单,聚焦业务逻辑,让运营更高效,一切尽在掌握。


目前该框架在腾讯内部,有100多个业务、1.6多万台服务器上运行使用。



 2. 设计思想 


Tars 的设计思路是采用微服务的思想对服务进行治理,同时对整个系统的各个模块进行抽象分层,将各个层次之间相互解耦或者松耦合,如下图:


最底的协议层,设计思路是将业务网络通信的协议进行统一,以IDL(接口定义语言)的方式,开发支持多平台、可扩展、协议代码自动生成的统一协议。在开发过程中,开发人员只需要关注通讯的协议字段的内容,不需要关注其实现的细节,大大减轻了开发服务时需要考虑的协议是否能跨平台使用、是否可能需要兼容、扩展等问题。


中间的公共库、通讯框架、平台层,设计思路是让业务开发更加聚焦业务逻辑的本身。因此,从使用者的角度出发,封装了大量日常开发过程中经常使用的公共库代码和远程过程调用,让开发使用更简单方便;从框架本身的角度出发,做到高稳定性、高可用性、高性能,这样才能让业务服务运营更加放心;从分布式平台的角度出发,解决服务运营过程中,遇到的容错、负载均衡、容量管理、就近接入、灰度发布等问题,让平台更加强大。


最上面的运营层,设计思路是让运维只需要关注日常的服务部署、发布、配置、监控、调度管理等操作。



3. 整体架构


➣ 3.1. 架构拓扑图



整体架构的拓扑图主要分为2个部分:服务节点与公共框架节点。


服务节点:

服务节点可以认为是服务所实际运行的一个具体的操作系统实例,可以是物理主机或者虚拟主机、云主机。随着服务的种类扩展和规模扩大,服务节点可能成千上万甚至数以十万计。 每台服务节点上均有一个Node服务节点和N(N>=0)个业务服务节点,Node服务节点会对业务服务节点进行统一管理,提供启停、发布、监控等功能,同时接收业务服务节点上报过来的心跳。


公共框架节点:

除了服务节点以外的服务,其他服务节点均归为一类。


公共框架节点,数量不定,为了自身的容错容灾,一般也要求在在多个机房的多个服务器上进行部署,具体的节点数量,与服务节点的规模有关,比如,如果某些服务需要打较多的日志,就需要部署更多的日志服务节点。


➣ 3.2. 服务交互流程图



框架服务在整个系统中运行时,服务之间的交互分:业务服务之间的交互、业务服务与框架基础服务之间的交互。



 3.3. web管理系统



 3.4. 服务结构图


框架核心的服务端与客户端实现结构图如下:





4. 平台特性


➣ 4.1. tars协议


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


例如:



➣ 4.2. 调用方式


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


同步调用:客户端发出调用请求后等待服务返回结果后再继续逻辑;


异步调用:客户端发出调用请求后继续其他业务逻辑,服务端返回结果又由回调处理类处理结果;


单向调用:客户端发出调用请求后就结束调用,服务端不返回调用结果。


➣ 4.3. 负载均衡


框架通过名字服务来实现服务的注册与发现,Client通过访问名字服务获取到被调服务的地址信息列表,Client再根据需要选择合适的负载均衡方式来调用服务,负载均衡支持轮询、hash、权重等多种方式。



➣ 4.4. 容错保护


容错保护通过两种方式实现:名字服务排除和Client主动屏蔽。


➣ 4.5. 过载保护


为了防止业务因为访问量突增或服务器故障造成系统整体的繁忙,进而导致全部服务的不可用,框架内部做相应设计来应对。实现请求队列,服务调用通过非阻塞方式实现异步系统,从而达到提升系统处理能力的目的。并且对队列的长度进行监控,当超过某个阀值,则拒绝新的请求。对请求设置超时时间,当请求包从队列里读取出来是判断请求是否超时,如果超时则不做处理。




➣ 4.6. 消息染色


框架提供了对某服务某接口的特定请求进行染色的能力,染色的消息可以透传到后面需要访问的所有服务上,对染色的请求,服务自动把日志上报到特定的染色日志服务器上,使用者只需在染色服务器上即可分析请求访问的路径,方便跟踪定位问题。 如下:



➣ 4.7. IDC分组


为了加快服务间的访问速度,建设跨地区、跨机房调用带来的网络资源消耗,减少网络故障带来的影响,框架提供了跨地区、跨机房,就近接入的功能。




➣ 4.8. SET分组


为了方便对业务服务部署管理进行标准化和容量化,框架提供了Set部署能力,set之间没有调用关系,互不干扰,故障隔离,提高运维效率和服务可用性。




➣ 4.9. 数据监控


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


1.提供了服务模块间调用信息统计上报的功能,方便用户查看服务的流量、延时、超时、异常等情况;


2.提供了用户自定义属性数据上报的功能,方便用户查看服务的某些纬度或者指标,比如内存使用情况、队列大小、cache命中率等;


3.提供了服务状态变更和异常信息上报的功能,方便用户查看服务的何时发布过、重启过、宕过以及遇到的异常致命错误等;


➣ 4.10. 集中配置


对业务配置进行集中管理并且操作web化,使配置修改更容易,通知更及时,配置变更也更安全;对配置变更进行历史记录,让配置可以轻松回退到前一版本。配置拉取服务化,服务只需调用配置服务的接口即可获取到配置文件。




推荐阅读

盘点那些评分最高的项目管理工具,不服来战!

Redis 单例、主从模式、sentinel 以及集群的配置方式及优缺点对比

Spring 思维导图,让 Spring 不再难懂(ioc 篇)

一名 40 岁“老”程序员的反思

“放码过来”邀您亮“项”,一不小心就火了!

点击“阅读原文”查看更多精彩内容