TSF简单体验学习

腾讯分布式服务框架 TSF (Tencent Distributed Service Framework) 是一个围绕应用和微服务的 PaaS 平台，提供服务全生命周期管理能力和数据化运营支持，提供多维度应用、服务、机器的监控数据，助力服务性能优化；拥抱 Spring Cloud 开源社区。

概述

腾讯分布式服务框架 （Tencent Service Framework） 是一个围绕着应用和微服务的 PaaS 平台，提供应用全生命周期管理、数据化运营、立体化监控和服务治理等功能。TSF 拥抱 Spring Cloud 、Service Mesh 微服务框架，帮助企业客户解决传统集中式架构转型的困难，打造大规模高可用的分布式系统架构，实现业务、产品的快速落地。

TSF 以腾讯云中间件团队多款成熟的分布式产品为核心基础组件，提供秒级推送的分布式配置服务、链路追踪等高可用稳定性组件。此外，TSF 与腾讯云 API 网关和消息队列打通，让企业轻松构建大型分布式系统。

TSP概念关系

集群 是实例的集合。在同一个集群中，可以存在很多资源，而在实际的工作中，常常需要将这些资源进行隔离。具体可参考 集群。

命名空间 将集群的环境隔离开，构造彼此独立的环境，如开发环境、测试环境的隔离等等。同一命名空间下存在不同的部署组。具体可参考 命名空间。

部署组 也是实例的集合，范围比集群和命名空间更小。用户通过部署组来部署应用，同一部署组上的实例运行的应用相同。具体可参考 部署组。

使用对接

spring cloud应用对接

因为需要使用TSF SDK，所以需要maven设置tencent仓库。maven setting配置如下：
加入profile：

	
        qcloud-repo
        
            
                qcloud-central
                qcloud mirror central
                http://mirrors.cloud.tencent.com/nexus/repository/maven-public/
                
                    true
                
                
                    true
                
            
            
        
            
                qcloud-plugin-central
                http://mirrors.cloud.tencent.com/nexus/repository/maven-public/
                
                    true
                
                
                    true
                
            
        
    
  
  
  
    qcloud-repo
 

服务注册与发现
基于原生的spring-cloud-starter-consul-discovery方案实现，这里不进行叙述。
分布式配置
即配置中心，配置中心基于原生的spring-cloud-starter-consul-config，进行动态配置。这里不进行叙述，tsf基于spring-cloud-starter-consul-config方案实现一套管控端。
服务鉴权
TSF的服务鉴权，实现SDK包。maven如下：

    com.tencent.tsf
    spring-cloud-tsf-auth
    1.1.1-RELEASE

使用@EnableTsfAuth启动
TSF 提供了两种类型的鉴权能力，一种根据调用方服务名，一种根据调用方设置的 tag。在管控端进行配置鉴权。
其实原理是一样的，服务名作为一种特殊的key的tag。在服务调用时，客户端传输tag，服务端根据鉴权规则进行判断。
服务限流
TSF的服务限流，实现SDK包。maven如下：

    com.tencent.tsf
    spring-cloud-tsf-ratelimit
    1.1.1-RELEASE

使用@EnableTsfRateLimit启动
使用管控端写入到consul配置，服务端拉取配置信息，进行流控(令牌桶)。
应该还是内部版本，还未服务功能。

参数传递
TSF进行参数传递，主要机制使用tag。
使用场景：

• 标签信息 ：用于信息分类，使用场景包括：
  • 服务鉴权：被调方通过标签来决定是否提供服务。
  • 服务路由：通过标签来判断应该访问什么服务，可用于实现金丝雀发布等。
  • 调用链：可用于调用链的筛选和附带业务信息。
• 辅助信息 （CustomMetadata）：仅供展示，不支持筛选，不具备传递性。

什么是传递性？以调用关系 A => B => C，说明传递性的概念：

• 可传递（Transitive）：需要传递的标签，在整条链路都传递，即用户在 A 设置的标签，会传递到 B 再传递到 C。
• 不可传递：不需要传递的标签，即用户在 A 设置的标签，会传递到 B，但是不会传递到 C。

调用链
TSF直接与spring cloud的zipkin集成，提供集成包。

    com.tencent.tsf
    spring-cloud-tsf-sleuth
    1.1.0-RELEASE

调用链支持用户在代码中设置标签（Tag） 和自定义元数据（CustomMetada），分别用于调用链的筛选和附带业务信息。

服务路由
服务路由功能
TSF 配置服务路由功能支持以下三种配置方式：

• 按照权重方式配置路由规则。在需要配置服务路由的服务下面，用户可以选择配置流量的权重，将部分权重的请求流量分配到服务提供方的某个版本下或某个部署组下。
• 按照系统自带标签的方式进行配置路由规则。每一个 TSF上运行的服务都已经被预先设置好了某些标签，如发起请求的服务消费方所在的部署组、IP、服务发起方的版本号等等。用户可以选择这些标签，并配置标签值的特定规则，分配带有某些流量的标签到服务提供方的某个部署组上进行处理。在标签值的配置上，用户可以填写“包含、不包含”，“等于、不等于”，正则表达式等等灵活的规则。
• 按照用户自定义的标签进行配置路由规则。TSF提供了用户配置自定义标签的SDK，在实际的使用中，如果系统自带标签不能保证用户使用的场景，用户可以自定义标签内容，在SDK中进行配置，并在控制台上配置相同的标签，控制服务消费方提供的流量按照配置的方式流入服务提供方。
  
  
  

TSF Mesh

TSF Mesh即使用ServiceMesh的方案
TSF Mesh 可以代理使用虚拟机或者容器部署的应用。下面以容器为例说明 TSF Service Mesh 的实现原理。Sidecar 是 L7 层代理，和服务运行在同一个 Pod 中，与 Pod 共享网络和存储，其中 Sidecar 与服务的关系如下：

Sidecar 代理服务向注册中心注册服务相关信息，以便其他服务发现自身。
Sidecar 作为 Pod 内服务的 HTTP 代理，可以自动发现其他服务。
使用场景



使用方式：

1. 创建一个应用，暴露http协议
2. 创建应用时，设置为mesh应用
3. 此时在同集群同分组下，就能通过服务名的方式http访问该服务

Dubbo对接

从官方文档来看，提供的maven坐标不对，所以也没办法对接
但从maven扩展的dubbo组件来看，扩展其注册中心，协议层似乎没有扩展 应该无法使用service mesh，个人理解，不一定正确

个人简单试用理解

简单概括，TSF像一个孩子，简单但不成熟，或许以后会好起来。

微服务概念集成

TSF对为服务的概念集成，可以看出主要是对spring cloud进行集成，原生的consul注册中心和配置中心、扩展服务鉴权、服务限流和调用链(基于所谓的参数传递机制)，其中调用链基于zipkin。可以看出TSF微服物概念是在原生spring cloud之上使用扩展对接的方式加入了一些自身的东西。并对接各方案，实现管控端。同时为了满足dubbo客户，对dubbo又在进行封装，不过目前估计还在研发中，只能初步看到consul的扩展。如果将spring cloud微服物概念和dubbo打通，还是有些工作的。

Mesh集成

TSF对ServiceMesh的实现，目前做到的程度是针对HTTP服务(不限制应用层是基于什么实现的HTTP协议)，对其应用服务做集群-分组内部的映射。如场景：应用服务APP，如在非mesh场景，客户端消费需要指定IP和port，然后进行访问。但在mesh应用场景中，则客户端只需要按服务的方式访问，如：http://app/health、http://app/api1这种方式。
但很容易看出目前TSF Mesh只做到了简单的ip和服务域名映射，负载这种情况。还有很多问题没有解决：

1. 服务无法动态发现，应用服务启动后需要手动添加服务
2. 服务需要强制提供health探测接口，给予探测应用服务存活
3. 目前只是似DNS的方式实现域名到ip:port映射，各治理功能、监控和调用链等都还需在应用层实现
4. 仅限http协议，无法支持其他协议

配置中心

基于原生的spring cloud consul config，然后提供了管控端，没有深入去使用，不太好评论现在所做的程度。但可以看到，基于原生spring 体系使用问题不大。而且从管控端来看，也做到了一些集群、命名空间、部署组等概念划分和隔离。

参数传递

参数传递是TSF内部的概念，指在通讯过程中一些元数据进行传递。此机制用在了鉴权、调用链中。

调用链和鉴权

TSF中的鉴权，就是对参数传递中的tags，进行一些特定的tag判定，是否携带或者不能携带一些值。
调用链是使用zipkin方案进行扩展，且集成了参数传递，可以做到一些tags，用于筛选。从代码来看收集可能是基于日志的方式。

限流

TSF中的限流，基于提供了jar集成，简单能看出大概机制是基于consul config进行限流配置。各节点订阅刷新配置，使用令牌桶的方式限制流量。没看到使用分布式限流方案。

服务路由

服务路由提供三种路由，一种基于权重、一种基于服务自身携带信息(如：ip、版本、部署组等)、还一种基于自定义标签。使用起来较为复杂，没有尝试使用。

日志和指标监控

从云机器的tsf-agent来看，是有使用filebeat和metricbeat，可以看出日志和机器的监控可能使用到了ELK。应用监控可能使用了JMX和Redis。