TARS立刻要成立基金会了，这款微服务框架适合你么？

20世纪90年代中期开始，分布式架构开始流行起来，面向服务的架构(SOA)愈来愈占主导地位。在21世纪初，微服务开始出现，一系列基于微服务架构的框架涌现，而近日，为构建微服务开源生态， TARS项目也将成立基金会。本文邀请腾讯云高级工程师田甜老师带你们了解开源微服务框架现状，详细阐述TARS、gRPC、以及腾讯云Service Mesh的不一样优点和特色，但愿能与你们一同交流~

引言

目前开源界的微服务框架大致能够分为如下四个种类。

第一类是无服务治理的，这一类基本能够看作是一个RPC框架。RPC发展到如今已经有几十年的时间了，主要表明为gRPC、BRPC、Thrift，它们也都有对外开源的代码。

第二类是带治理功能，可是语言比较单一，主要的表明是以Java为主的Spring Cloud、dubbo等。

第三类就是Service Mesh，主要表明产品是Linkerd和ISTIO，这是将来的发展方向。

最后就是TARS，不只支持多语言，还附带一些服务治理相关的功能产品。

1、TARS 架构体系

1. TARS简介

TARS是腾讯从2008年到今天一直在使用的后台逻辑层的统一应用框架TAF（Total Application Framework），目前支持C++、Java、PHP、Nodejs、Go语言。该框架为用户提供了涉及到开发、运维、以及测试的一整套解决方案，帮助一个产品或者服务快速实现开发、部署、测试，以及上线。

它集可扩展协议编解码、高性能RPC通讯框架、名字路由与发现、发布监控、日志统计、配置管理等于一体。经过它能够快速用微服务的方式构建本身的稳定可靠的分布式应用，并实现完整有效的服务治理。

2. TARS总体架构

TARS的架构以下图所示：

Devops相关方面，主要有代码管理、代码编译和自动化测试等等，底层还有OSS的服务治理。支持协议方面，主要基于自身的TARS协议，另一些其余自定义的协议也能够支持。服务治理的功能较为丰富，包括你们经常使用的服务注册、负载均衡、熔断、服务配置等等，这些都是在咱们线上作分布式服务管理的时候要作的。

TARS支持五大编程语言，其中包括C++和JAVA、nodejs和PHP和GO，也能够扩展其它语言。

3. 服务治理

对于服务治理，其实最重要就在于客户端和服务端之间的调用。咱们的客户端调用服务端是经过registry 来实现的，registry 中文名字叫作主控。客户端在调用的时候会去 registry 作请求，后端有一个 SDK 管理全部的协议，这个 SDK 能够对服务进行监控统计，所有自动完成。

（1） 自动区域感知

调用 logsvr 的时候，用户请求主控拿到节点列表并直连。这里须要指出，基于路由的规则，咱们须要把网段注册成一个地区，从而实现自动区域感知。

这是由于在线上业务当中，会出现一些问题。若是一个服务部署到同一地区的不一样区域之后，它的跨机房时延在4毫秒左右。若是是跨城市、省份的话可能高达到40毫秒，因此若是咱们同机房有部署的话，就会尽可能访问本身机房，这样能够提升性能，减小访问耗时。

综上，常规的负载均衡方式面对跨地区或者跨机房部署的服务，会由于网络缘由形成延时增大，使用不一样服务名来解决该问题时也会带来繁重的运维工做，而经过 Registry 和开发框架配合实现自动区域感知能够自动完成相关的工做。

（2） SET模型

SET模型是腾讯运用比较普遍的体系，由于当容量大到必定程度以后，一个服务发布的过程当中也许能影响到全区的服务。例如手机QQ的用户基数上亿，一点微小的变更都会产生深远的影响，所以咱们设计了SET模型。

如上图所示，假设该模型有300万的容量。若是单个地区容量过大会致使整个容量过载，因此将它分红三组，6个服务，每一个服务自我调用。可是这种服务开发成本相对比较高，若是要再扩增100万容量的话，须要建更多组服务才能够实现。

经过框架处理能够很好解决上述问题，为了以示区别，咱们在服务A、B前加上标识Set。经过纵向割裂，将300万以100万/个SET的单位分红3组，每个SET负责100万的容量，将来业务容量超过了300万接近400万时就只须要加一个SET就能够了。该场景主要是防止故障扩散，若是其中一个场景在迭代的时候出现了问题，只会影响指定SET的100万的用户，不会影响到其余200万的客户。

（3）流量控制

关于流量控制，其实在分布式架构方面也会存在一些问题。好比说，咱们常常发布节点，若是按照节点一个一个发布的话，即便服务部署得很是多，但由于流量较大，单个节点存在的用户也会比较多。

这时能够经过权重设置作到无损发布，例如经过权重指定某一个节点的流量只有10%，以此来控制流量。在发布的时候，常常会出现重启致使流量丢失的现象。面对这种状况，咱们能够先把流量调为0，发布完成以后，再调回来，这样就能够实现部分按需流量的控制，这也是在大规模线上应用比较经常使用的解决方案。

（4）分布式跟踪

当有用户反馈说某项服务访问比较慢的时候，咱们就须要知道用户相应的用能耗时。这种状况下，若是只是经过相应的数据去排查的话，是比较困难的。

由于在一个微服务下面，一个请求可能会跳屡次，因此没法预测到一个服务具体走的跳数，这时候就须要经过分布式跟踪来进行链路追踪。TARS有一套比较完整的体系，从接入到存储均可以自我实现。

(5) 服务配置管理

关于服务配置管理，咱们分了四级，分别是应用级配置、SET配置、服务配置和节点配置。

作分布式架构，最难的点就是运维可视化。这样作不只能让部署和发布更加方便，还能将开发和运维分离，不须要开发接入，一些流程化操做能够寻求外包人员，这样也减轻了人力成本。

TARS的产品应用比较完善，在某些技术上甚至处于领先地位，目前应用在不少大规模应用上也不多出问题。

2、gRPC架构体系

gRPC主体是一个RPC框架，一样也定义了负载均衡策略。

gRPC主要基于Protocol Buffers 框架，Protocol Buffers 是Google出品的序列化的框架，与开发语言和平台都无关，具备良好的可拓展性，可用于数据存储和通信协议。

gRPC官方介绍虽然简单，但实际在线上应用时须要脚本和参数。因此咱们作了一个脚手架，经过这个参数生成代码。由于gRPC线上只提供了标准的接口，并不直接提供代码。不少服务治理的服务，好比日志、ACL这些全都得本身实现。

gRPC能够实现多数语言的代码客户端生成，可是若是想要使用的话还须要作出一些改造，完成相应协议的互转，最后还须要开发经常使用内部服务SDK来下降使用成本。

服务的实现主要依赖于gRPC拦截器的实现，经过拦截器能够实现远程日志、监控上报、链路追踪等服务。gRPC能够在RPC调用前触发注册的拦截器，在调用前能够执行远程日志上报等等功能，经过多种拦截器串行，实现一个拦截器链路，最终实现各类插件。

关于Protocol Buffers插件系统，它能够作到一些简单的加强。咱们在本身的项目中把Protocol Buffers做为一个描述语言，当接口完成时，经过Protocol Buffers的插件功能将开发文档转成swagger，这样的话与前端互通就会变得很是方便，这些代码和文档就能够一会儿自动生成。

关于gRPC的周边生态，它主要依赖于Protocol Buffers，拥有庞大的插件集合，能够转换出任何的语言，包含Tars协议。gRPC如今应用的场景也已经很是普遍，主要是在云原生方面。

gRPC也和TARS同样，存在着一些问题，就是它们须要用户改造过之后才能使用。这样的话就会产生用户的学习成本，须要把总体架构改形成符合RPC框架思路的架构，形成比较多的麻烦。

3、Service Mesh的探索

咱们知道腾讯游戏的数量很是繁多，架构每每并不统一。各个团队都跟着本身的思路走，想用什么就用什么，慢慢得各类框架和问题也随之出现。为了探索解决这一问题，咱们引入了一个新的思路：Service Mesh。

Service Mesh 是一个相对底层的架构，做为咱们微服务的底层。两大主要产品是linkerd和Istio，它们能够直接从底层作一些链路追踪方面的事情，经过应用下沉提升了系统的适用性。

以下图所示，左边展现的是TARS和gRPC，他们的主要思路在于无性能损耗的交用，把全部的东西都执行到RPC里面，侵入性较强。右边是Service Mesh的架构，Service Mesh会把业务的服务作得很薄，基本上没有什么业务逻辑，而把全部微服务治理的东西所有放到下层，从而作到整个服务的流量控制，这样就组成了一个个小方格，互相之间能够互联。

这样的方式能够将框架作得很是薄，甚至不要均可以。整个架构很是清晰，至关于单体调用经过Service Mesh能够直接变为分布式的架构。

咱们去年在王者荣耀里面也作了一些应用，最后发现这些架构很是方便。当咱们给王者荣耀作活动使用的时候，虽然流量很大，可是性能很是稳定。每一个服务下面都有一个Proxy，Proxy就是Sidecar，用于处理服务网格中全部服务的全部入站和出站流量。Proxy把全部的头转给Mixer，Mixer是负责提供策略控制和遥测收集的组件服务，这一块是作数据平面的一些操做。接着是Adapter，为Mixer提供扩展服务的独立服务，好比作一些远程负载均衡的流量控制。以这一套架构做为分布式体系的一部分，能大幅度下降许多单体应用的开发成本。

Pilot主要职责是向 Sidecar 发现服务、信息和各类流量管理和路由规则，Galley服务提供配置的校验、各类配置之间统筹，为 Istio 提供配置管理服务，Citadel用于密钥管理和证书管理，下发到Sidecar等负责通信转发的组件。

经过测试数据能够看到，Istio在打开Mixer状况下单边延迟增长1ms 左右，双边延迟增长2ms左右，对服务影响较小，关闭Mixer延迟能够更低。

若是以绝对数字来看的话，至关于增长了一倍的耗时。可是在咱们正式应用当中，大部分服务耗时都是在50毫秒左右，若是咱们只增长了1毫秒，其实影响并不大。可是若是对于一些底层存储应用，自己的耗时是比较低的，若是再用这套架构把它变成分布式架构就会很是困难，由于性能损耗会变得很是大。

将来腾讯云会在设置一个统一的Istio管理平台，在容器管理平台里面会提供Istio的服务网格技术，在上面一层能够经过一些控制平面，服务咱们上面的一些管控体系，经过Istio的应用管理平面来实现，底层能够访问咱们的外部存储的，这个就是咱们一套比较完整的应用架构。

下图所示的是 Service Mesh 和咱们微服务框架的对比，在语言支持方面，它是跟语言无关的的底层架构，因此具备很高的拓展性。将来咱们将会逐步完善总体生态建设，社区如今的活跃度也维持在较高水平。

最后给你们总结一下，咱们的传统框架将来还会存在，可是它的功能会愈来愈业务化，治理相关的一些功能会逐渐下沉，更加注重是业务化的功能。

若是在应用当中，你尚未配置一些框架的服务体系的话，那使用TARS是很是合适的。TARS使用的是完整的微服务体系，很是方便快捷。若是使用gRPC则须要本身建设周边的体系。咱们将来将会以Service Mesh为主，慢慢替代原有框架。若是你们还在作框架开发相关的业务，能够慢慢地抽出来往Service Mesh上面靠，由于框架开发将来会慢慢以业务开发为主，治理这一块将再也不是重点。

4、Q&A

Q：对于Service Mesh，Service Mesh至关于将全部的服务治理都单元化集成到某个应用中，那么每个单元的负载均衡或者是流量控制，是如何控制的呢？

A：负载均衡其实就是将流量转化成IP列表，分发给不一样的IP。这里须要经过Sidecar？由于Sidecar会知道你的流量往哪边走，目前是经过iptables劫持流量指向Sidecar。当你的服务经过Sidecar以后，Sidecar获取到目的地址，经过控制面板上的数据，搭配一些策略，而后作映射，把你相应的请求分发到多个节点中去从而实现均衡。

讲师简介

田甜，腾讯高级工程师，对分布式架构与容器化技术有深刻研究，具备丰富的分布式架构设计开发与项目实践经验。目前专一TARS-GO框架开发，是TARS-GO早期发起人和最核心开发成员之一，也是腾讯游戏数据研发工程师，致力于在数据服务场景中应用微服务架构。