腾讯微服务平台TSF-稳定、高性能的微服务技术中台，满足您对应用管理、微服务治理等多样性需求

腾讯微服务平台（Tencent Service Framework，TSF）是一个围绕应用和微服务的 PaaS 平台，提供一站式应用全生命周期管理能力和数据化运营支持，提供多维度应用和服务的监控数据，助力服务性能优化。提供基于 Spring Cloud 和 Service Mesh 两种微服务架构的商业化支持。

腾讯微服务平台 TSF 是一个围绕着应用和微服务的 PaaS 平台，提供应用全生命周期管理、数据化运营、立体化监控和服务治理等功能。TSF 拥抱 Spring Cloud 、Service Mesh 微服务框架，帮助企业客户解决传统集中式架构转型的困难，打造大规模高可用的分布式系统架构，实现业务、产品的快速落地。 TSF 以腾讯云中间件团队多款成熟的分布式产品为核心基础组件，提供秒级推送的分布式配置服务、链路追踪等高可用稳定性组件。此外，TSF 与腾讯云 API 网关和消息队列打通，让企业轻松构建大型分布式系统。

功能

腾讯微服务平台 TSF 提供多种强大功能，用于构建、部署和运维可扩展、高可用的微服务。

服务开发框架

兼容 Spring Cloud 开发框架
提供基于 Spring Cloud 的功能 SDK，覆盖服务注册发现、服务限流、服务鉴权、服务路由、调用链、API 上报、分布式配置等功能。
兼容 Istio 开发框架
提供完全兼容 Istio 的 Service Mesh 微服务平台能力，支持服务注册发现、服务限流、服务鉴权、服务路由、调用链、API 上报等功能。

服务治理

服务注册发现
支持服务注册到服务注册中心，服务通过注册中心发现其他服务。TSF 提供高可用服务注册中心，用户无需关心注册中心的运维。开发者无需关心注册中心地址，服务注册由 TSF 提供的 SDK 自动完成。
服务限流
支持服务级别和 API 级别的服务限流，通过标签来精准匹配目标API。通过限流功能保护微服务免受流量冲击。
服务路由
支持通过配置、权重标签的形式进行细粒度的流量控制，实现灰度发布、就近路由、部分账号内测、流量限制、访问权限控制等功能。
服务鉴权
服务鉴权解决微服务之间相互访问的权限解决方案。服务提供者通过配置中心下发的鉴权规则来判断是否处理服务消费者的请求。TSF 支持黑名单和白名单两种鉴权方式。
API 上报
支持服务 API 上报，查看服务提供的 API 列表和 API 详情。API 可用于服务鉴权、限流、路由等功能。

应用生命周期管理

虚拟机和容器部署应用
支持虚拟机和容器集群，用户可以选择使用虚拟机或者容器作为 IaaS 层资源。
滚动发布
支持立即更新和滚动发布两种发布模式，其中滚动更新确保流量平滑迁移到目标版本的服务上。
弹性伸缩
支持弹性伸缩功能，根据 CPU 利用率、内存利用率、请求量、响应时间动态调整服务实例数量，灵活应对流量高峰和低谷，降低突发故障和运营成本。
配置管理
支持分布式配置、文件配置、配置模板等多种配置工具，支持配置版本管理、配置发布、配置历史查询等功能，帮助开发者管理线上业务的配置信息。

数据化运营

调用链
支持采集调用链数据并生成调用链层次关系图，帮助开发者定位慢调用和失败调用。调用链查询用来查询和定位具体某一次调用的情况。使用者可以通过具体的服务、接口定位、IP 等来查询具体的调用过程，查找调用过程所需要的时间和运行情况。
服务依赖拓扑
服务依赖拓扑包含了查询服务之间相互依赖调用的拓扑关系，查询特定集群特定命名空间下服务之间调用的统计结果等功能。

监控和日志

应用监控
支持请求数、最大响应时间、平均响应时间、成功请求数、失败请求数的监控指标查看。
日志服务
支持日志规则创建、应用日志采集，存储和检索，支持实时日志查看。
操作记录
支持查看用户在 TSF 平台上进行的所有操作，便于回溯操作人和操作行为等信息。
腾讯微服务平台（Tencent Service Framework）是一个围绕着应用和微服务的 PaaS 平台，提供应用全生命周期管理、数据化运营、立体化监控和服务治理等功能。TSF 拥抱 Spring Cloud 、Service Mesh 微服务框架，帮助企业客户解决传统集中式架构转型的困难，打造大规模高可用的分布式系统架构，实现业务、产品的快速落地。
TSF 以腾讯云中间件团队多款成熟的分布式产品为核心基础组件，提供秒级推送的分布式配置服务、链路追踪等高可用稳定性组件。此外，TSF 与腾讯云 API 网关和消息队列打通，让企业轻松构建大型分布式系统。
相关产品
- TSF 应用运行在云服务器上。更多信息，请参阅云服务器产品文档。
- TSF 可以使用腾讯云微服务 API 网关。更多信息，请参阅 API 网关产品文档。
- TSF 可以打通腾讯云消息队列 CMQ。更多信息，请参阅消息队列 CMQ 产品文档。
- TSF 可以打通腾讯云消息队列 CKafka。更多信息，请参阅消息队列 CKafka 产品文档。
服务注册发现
TSF 服务注册发现包括三个角色：服务提供者、服务调用者和服务注册中心。
服务提供者和服务调用者将地址信息注册到服务注册中心，并从服务注册中心获取所有注册服务的实例列表，服务调用者使用服务提供者的实例地址进行调用。
应用生命周期管理
TSF 提供从创建应用到运行应用的全程管理，功能包括创建、删除、部署、回滚、扩容、下线、启动和停止应用。TSF 提供部署组来实现应用的版本控制功能。TSF 将每次操作记录下来，用户可以在应用的变更记录页面中查看和搜索变更记录。
分布式配置管理
配置管理包括应用配置、全局配置和文件配置。用户可以通过控制台进行分布式配置版本管理、发布配置到部署组或者命名空间范围内的实例。
细粒度服务治理
TSF 提供服务级和 API 级别的服务治理能力，支持通过控制台配置服务路由、服务限流、服务鉴权规则。在 TSF 控制台中，用户可以通过配置、权重标签的形式进行细粒度的流量控制，实现灰度发布、就近路由、部分账号内测、流量限制、访问权限控制等功能。
数据化运营
TSF 提供全面的监控和分布式调用链分析工具，帮助用户把握应用上线后的运行状况。
监控包括应用监控，应用监控的指标包括应用的 QPS、请求时间和请求出错率等。
分布式调用链分析包括调用链查询和调用链详情。用户可以根据时间范围和服务名等条件查询一组调用链。调用链详情显示了请求经过每个服务的层次关系和耗时情况等信息。
TSF 提供日志分析能力，自动获取用户的业务日志并支持在 TSF 控制台上进行日志查看、日志检索，支持日志关键词告警功能，并提供日志与调用链联动排查线上问题。
分布式事务
TSF 集成了分布式事务能力，支持 TCC 模式分布式事务管理功能。对于跨数据库、跨服务的分布式场景，用户可以通过控制台查看事务运行情况并进行超时事务处理，保证事务的一致性。

优势项	TSF 服务治理平台	自建服务治理平台
服务注册中心	平台提供高可用的注册中心集群，金融级别容灾	自行搭建和维护
调用链能力	符合国人习惯的交互方式，与日志服务联动	使用开源组件，英文界面
应用部署	成熟、灵活的部署方案，支持灰度发布等高级能力	自行开发部署模块
日志服务	提供采集、呈现、解析、检索的一站式能力，帮助开发者快速定位目标日志	基于 ELK 等开源组件搭建
配置管理	分布式配置，支持从环境、版本、应用三个维度进行管理，配置动态推送和历史推送回溯能力	自行搭建和维护
服务治理	支持细粒度的服务路由、限流、鉴权功能，控制台进行可视化配置	自行搭建和维护
分布式事务	提供分布式事务解决方案，经腾讯内部多产品实践验证	使用开源或自行开发
微服务 API 网关	微服务 API 网关提供微服务网关能力，支持配置鉴权、限流等策略	基于 Zuul 等组件开发
与腾讯云服务整合	与腾讯云服务深度整合	基于云 API 开发
售后服务	提供稳定及时的售后服务，强大的技术、运维团队支持	企业运维团队支持

构建分布式服务系统
单体应用转变为分布式系统后，实现系统间的可靠调用是关键问题之一，涉及到路由管理、序列化协议等技术细节。
TSF 提供了 RESTful 调用方式和自研的高性能 RPC 框架，能够构建高可用、高性能的分布式系统，TSF 系统地考虑了分布式服务发现、路由管理、安全、负载均衡等细节问题。同时 TSF 将在未来打通消息队列、API Gateway 等服务，满足用户多样化的需求。
应用发布和管理
相对于传统的应用发布需要运维人员登录到每一台服务器进行发布和部署，TSF 针对分布式系统的应用发布和管理，提供了简单易用的可视化控制台。用户通过控制台可以发布应用，包括创建、部署、启动应用，也支持查看应用的部署状态。除此之外，用户可以通过控制台管理应用，包括回滚应用、扩容、缩容和删除应用。
数据化运营
通过对日志埋点的收集和分析，可以得到一次请求在各个服务间的调用链关系，有助于梳理应用的请求入口与服务的调用来源、依赖关系。当遇到请求耗时较长的情况，可以通过调用链分析调用瓶颈，快速定位异常。
TSF 针对每个用户在每个地域有如下限制：

限制类型	限制说明	备注
程序包仓库存储容量	最多100GB	-
免费注册到注册中心的服务实例额度	20个	如需扩大额度，请参考产品价格
容器集群数量	最多5个	如须扩大额度，请提交工单给TKE 产品
日志存储天数	30天	-
单次日志查询的日志条数	最多10000条	-
配置项的单个版本的大小	最大65535个字节	-
虚拟机集群导入云主机的操作系统	CentOS 7.5 、Ubuntu 18.04 LTS	-

近期版本更新：

版本号	更新时间	版本说明
1.15.0	2019.8.14	新增 API 导出和调试、日志检索结果支持下载
1.14.1	2019.7.05	新增部署组健康度告警、开放云 API 文档。
1.14.0	2019.6.20	调用链支持下游组件，更新 Dubbo SDK。
1.13.0	2019.4.17	新增服务统计功能，新增独立监控页面，Mesh 应用支持使用域名调用。
1.12.0	2019.3.13	服务依赖拓扑支持查看服务监控，支持 Spring Cloud Finachley。
1.0.10	2018.11.14	新增容器应用弹性伸缩，更新服务鉴权、限流、路由等功能。
1.0.9	2018.8.13	新增服务路由、服务限流等功能。

1.15.0 版本说明

新特性

新增 API 导出和调试。

问题修复及优化

支持日志检索结果的下载。
修复路由和限流 SDK 缺陷。
容器部署组的实例异常状态下显示异常信息。

1.14.1 版本说明

新特性

支持部署组健康度告警。
开放云 API 文档。
部署组支持重启操作。

问题修复及优化

修复由于使用 TSF 集群关联的 VPC 无法删除问题。
提供虚拟机集群云服务器 agent 升级脚本。

1.14.0 版本说明

新特性

调用链支持 Redis、MySQL、MongoDB、消息队列。
更新 Dubbo SDK，支持 Dubbo 应用的服务注册、调用链、监控。

问题修复及优化

集群内云主机支持批量删除。
修复 Spring Cloud Finchley 版本 SDK 不支持 Spring Cloud Gateway 的问题。
修复删除服务没有关联删除鉴权、路由、限流规则的问题。

1.13.0 版本说明

新特性

新增服务统计功能，支持主调和被调视角查看服务指标统计信息。
新增独立监控页面。
Mesh 应用支持使用域名调用。

问题修复及优化

优化应用删除逻辑，只有删除应用关联的所有部署组才能删除应用。
优化日志配置项，日志路径支持目录通配符，日志配置项支持最多20个日志路径。
容器 stdout 日志支持滚动，避免日志过大导致磁盘空间不够的问题。

1.12.0 版本说明

新特性

服务依赖拓扑展示优化，可查看服务的监控情况。
程序包和镜像支持批量删除。
支持基于 Spring Cloud Finchley（Spring Boot 2.0）的 SDK。

问题修复及优化

修复问题：在 TKE 产品界面修改服务数据卷等配置，重新部署时会重置 TKE 上修改的配置信息。
优化日志采集占用机器 CPU 的利用率。
优化实时日志如果没有日志数据的提示文案。
实时日志展示最近15条历史日志。
优化 Mesh 应用没有成功注册时的异常提示，部署实例状态显示异常状态和信息。
优化容器部署组资源限制逻辑，由 limit 改为 request，计算集群可用资源时和集群详情页保持一致。
优化调用链查询条件，去掉集群筛选条件。
应用配置按照下发时间的先后顺序进行 merge （之前版本使用配置项名称来排序）。

1.0.10 版本说明

新特性

服务鉴权功能支持白名单和黑名单两种方式，支持创建多个鉴权规则。
服务路由功能将标签路由和权重路由功能结合。
服务限流支持全局限流和标签限流。
支持文件配置功能。
支持容器应用弹性伸缩。
支持 Spring Cloud 应用和 Mesh 应用的 API 上报。

问题修复及优化

命名空间支持绑定多个集群。
Mesh 应用支持本地服务描述文件，不再需要在控制台上创建服务绑定应用。
支持程序包下载功能。

1.0.9 版本说明

新特性

服务路由功能。服务路由功能支持将服务间调用的部分流量分配到特定版本、部署组上，同时支持从服务消费方发出的带有某些特定标签的流量分配到特定服务提供方的版本、部署组中。支持灰度发布、就近路由等等场景。
服务限流功能。服务限流功能支持在高负载的情况下限制服务提供者的访问流量，保证服务的高可用性。
配置模板功能。用户可以根据 Spring Cloud 中 Hystrix、Zuul、Ribbon 等组件在配置模板中集中配置。支持数组形式配置。
调用链设置标签及 medadata 功能。用户可以在代码中设置标签及 metadata，在查询调用链时能够追踪带有某些标签的调用关系以及查看调用链元数据。
支持查看实例详情页并查看类属性、环境变量、线程、HTTP Traces 等。
统一规则配置项。
支持查看日志配置详情页，支持日志按照规则解析。
支持设置云服务器部署组启动参数。
支持 war 包得上传以及部署。

问题修复及优化

程序包上传优化。优化了程序包上传速率，上传程序包速度提升了8倍以上。增加传输进度条，方便用户直观了解上传进度。
配置项集中优化并更新，支持回调。
删除集群、命名空间流程优化。
优化部署组生命周期显示状态。
Service Mesh 应用打印调用链中 Span 的接口支持显示 API 接口。
支持 stdout 实时日志设置起始时间。

云服务器加入容器集群后，项目属性为何变为"默认项目"？
由于加入到 TSF 容器集群中的云服务器 CVM 实例可能属于不同项目，TSF 将加入到容器集群中的云服务器 CVM 的项目属性统一修改为默认项目。如果需要集群内云服务器分布在不同的项目，请自行前往云服务器控制台迁移项目。
虚拟机集群内云主机的可用状态为何显示不可用？
虚拟机集群中的云服务器显示"不可用"状态是因为 agent 无法连接 TSF 后台服务器导致的，因此需要检查 agent 的可用状态。
首先检查云服务器的状态是否为"运行中"。如果云服务器的状态不是运行中，请确保云服务器为开机运行状态。
登录云服务器，执行ps aux | grep 'agent'命令查看是否有包含tsf-agent命名的进程。如果没有，请查看步骤3。
切换到/root目录下，查看是否有tsf_agent目录。

如果没有，需要将主机从集群中删除后，再重新导入。
如果有，进入/root/tsf_agent/ops目录下，先执行uninstall.sh，再执行install.sh命令。然后通过 ps 命令检查进程。

TSF 是否支持在同一台服务器上安装多个应用？

在 TSF 中，应用的部署有两种类型：

CVM 云服务器独占实例：在一台 CVM 云服务器上，仅部署单独一个应用。通常根据应用需要的资源配置来购买 CVM 云服务器。
容器实例：TSF 使用 Docker 容器在一台独立的 CVM 云服务器上创建多个 Docker 实例，允许在每一个 Docker 实例上部署一个应用。

TSF 应用实例状态为什么显示 Agent 异常？

TSF Agent 会定期上报心跳数据给 TSF 管理模块，如果 Agent 停止上报状态，则某段时间后该机器将会被判定为未知状态。通常而言，该问题是由于 Agent 停止导致。

用户可尝试在云服务器界面，重启该云服务器。

容器部署组执行部署操作时提示内存（或 CPU）不足？

请检查该部署组所在集群和命名空间中的节点的内存（或 CPU）的使用情况，确保在执行部署操作时填写的内存（或 CPU）数值小于剩余内存（或 CPU）资源。

用户可以在集群的节点列表页面中找到已分配 CPU 和已分配内存信息。

如何排查应用是否部署失败？

在应用详情页，单击部署组操作列的【查看日志】查看 stdout 日志，通过日志初步定位是否是业务程序本身问题。如果没有日志信息，进行步骤2。
单击【变更记录】，查看本次部署任务的 taskid。
登录虚拟机或容器，查看本次任务的日志信息/root/tsf-agent/agent/task/<taskid>，其中 taskid 是步骤2中的任务 ID。
用户可通过日志信息初步定位部署失败原因，如果无法排查，可提交工单反馈任务日志信息。

程序包无法上传如何解决？

当发现程序包无法上传时，请检查浏览器是否设置了代理。用户可尝试换一个浏览器或者切换网络重新进行上传。

在工程的配置文件中，是否需要填写服务注册中心地址？

对于本地开发调试的应用，在启动 Java 应用的启动参数中需要填写轻量级服务注册中心 consul 的 IP 和 Port。配置文件（如 application.yml）中则无需填写。
对于通过 TSF 平台部署的应用，既不需要在启动参数中设置注册中心的地址，也不需要在配置文件中设置注册中心地址。SDK 会通过环境变量获取注册中心的地址。

应用部署成功后，服务列表中为何没有出现服务？

请检查部署压缩包中是否包含了 spec.yaml ，且 spec.yaml 的格式是否正确。
如果不存在 spec.yaml 或者格式不对，TSF 无法将服务注册到服务注册中心。详情参考 TSF Mesh 开发指引。

服务实例显示离线状态如何解决？

在 Mesh 环境下，TSF Sidecar 会定期通过调用服务的健康检查接口获取服务健康状态，并将健康状态上报到服务注册中心。由于某些原因，例如用户健康检查接口信息配置错误、端口配置错误、或者服务实例出现访问失败，则会导致服务不健康。
您可以通过以下步骤进行排查：

1. 查看服务配置信息

服务配置信息错误
查看应用的软件包，获取服务配置信息（spec.yaml），检查服务名是否为期望暴露的服务名、端口号是否为服务真实监听的端口号、健康检查接口是否存在、检查健康接口格式是否正确（不含 ip:port，类似/health是符合的）。
服务配置文件格式错误
将 spec.yaml 内容，拷贝到 yamllint 中，校验 yaml 格式是否正确。如果格式正确，则继续检查字段名称，是否与下面示例的格式一致。
```
apiVersion: v1kind: Applicationmetadata:name: service1namespace: nsTesterspec:services:
- name: user
healthCheck:
path: /health
ports:
- targetPort: 8089
protocol: http
```

服务配置没有挂载到正确的位置

在容器环境下，排查业务是否在容器的启动脚本中，把 spec.yaml 和 apis 目录(可选)，拷贝到挂载路径/opt/tsf/app_config下面。
在虚拟机环境下，排查业务程序包根目录下面，是否存在 spec.yaml 以及 apis 目录（可选），如果没有，则需要修改。
通用排查方法：

检查 pilot-agent 加载配置文件的绝对目录。
输入：curl 127.0.0.1:15020/config/agent|grep appConfigDir，输出：appConfigDir: /data/demo/shopService代表 pilot-agent 会从/data/demo/shopService中加载 spec.yaml。
确认 appConfigDir 指向的目录存在 spec.yaml。

2. 查看健康检查返回

登录应用所在的容器或者虚拟机，通过调用本地的健康检查路径，查看返回码是否为200，如果不是200，证明服务存在健康问题。详情参考 TSF Mesh 开发指引。

curl -i -H 'Host: local-service' {ip}:{Port}/<healthCheck_path>

3. 通过运维接口查看 sidecar 相关信息

登录应用所在的容器或者虚拟机，调用 pilot-agent 的运维接口，查看 sidecar 容器的相关状态信息。

查看接口列表
调用GET 127.0.0.1:15020/help接口查看接口列表：

[root@TENCENT64 ~/pilot-agent/op]# curl 127.0.0.1:15020/helpadmin commands are:
GET /health: print out the health info for data-plane
GET /config_dump/{component}: print out the configuration of the component, component can be pilot-agent/envoy/mesh-dns
GET /help: print out list of admin commands
GET /config/agent: print out the pilot-agent configuration
GET /config/services: print out the services info
GET /config/global: print out the global mesh configuration
GET /config/envoy: print out the envoy startup configuration
GET /version: print out the pilot-agent versionGET /version/{component}: print out the version of the component, component can be pilot-agent/envoy/mesh-dns
GET /latest_error: print out the latest error info
GET /status: print out the status, result could be <INIT>, <CONFIG_READY>, <FLOW_TAKEOVER>, <SERVICE_REGISTERED>GET /epoch/{component}: print out the component restart epoch, component can be envoy/mesh-dns
POST /hot_restart/{component}: hot restart the component process, component can be envoy/mesh-dns
PUT /update: update the component
PUT /logging/{scope}/{level}: dynamic change logging level, scope can be healthz/admin/ads/default/model, level can be info/warn/error/none/debug

查看版本号
调用GET 127.0.0.1:15020/version接口查看版本号：

[root@TENCENT64 ~/pilot-agent/op]# curl 127.0.0.1:15020/version1.0.13.release-20190225_103608

查看 sidecar 健康状态
调用GET 127.0.0.1:15020/health接口查看 sidecar 健康状态：
```
[root@TENCENT64 ~/pilot-agent/op]# curl 127.0.0.1:15020/health{"envoy":{"status":"UP"},"mesh-dns":{"status":"UP"},"status":"UP"}
```
如果出现部件不健康的组件（status 不为 UP），或者接口调用失败，则需要通过通过提交工单联系后台运维人员处理。

4. 调用 clusters 接口

登录应用所在的容器或者虚拟机，调用 envoy 的 clusters 接口，查看本地 cluster（格式为 in#port#serviceName）是否存在或者健康状态是否 healthy。
输入：

curl http://127.0.0.1:15000/clusters

输出：

in#8080#reporttimeb::default_priority::max_connections::1024in#8080#reporttimeb::default_priority::max_pending_requests::1024in#8080#reporttimeb::default_priority::max_requests::1024in#8080#reporttimeb::default_priority::max_retries::3in#8080#reporttimeb::high_priority::max_connections::1024in#8080#reporttimeb::high_priority::max_pending_requests::1024in#8080#reporttimeb::high_priority::max_requests::1024in#8080#reporttimeb::high_priority::max_retries::3in#8080#reporttimeb::added_via_api::truein#8080#reporttimeb::9.77.7.132:8080::cx_active::0in#8080#reporttimeb::9.77.7.132:8080::cx_connect_fail::0in#8080#reporttimeb::9.77.7.132:8080::cx_total::4in#8080#reporttimeb::9.77.7.132:8080::rq_active::0in#8080#reporttimeb::9.77.7.132:8080::rq_error::0in#8080#reporttimeb::9.77.7.132:8080::rq_success::4in#8080#reporttimeb::9.77.7.132:8080::rq_timeout::0in#8080#reporttimeb::9.77.7.132:8080::rq_total::4in#8080#reporttimeb::9.77.7.132:8080::health_flags::healthyin#8080#reporttimeb::9.77.7.132:8080::weight::1in#8080#reporttimeb::9.77.7.132:8080::region::in#8080#reporttimeb::9.77.7.132:8080::zone::in#8080#reporttimeb::9.77.7.132:8080::sub_zone::in#8080#reporttimeb::9.77.7.132:8080::canary::falsein#8080#reporttimeb::9.77.7.132:8080::success_rate::-1

如果 cluster 不存在，则需要通过通过提交工单联系后台运维人员处理。
如果状态不为 healthy，则执行后续步骤。

5. 调用 config_dump 接口

登录应用所在的容器或者虚拟机，调用 envoy 的 clusters 接口，查看本地的路由配置信息：

curl http://127.0.0.1:15000/config_dump -o config.json

通过 vi 打开 config.json 文件，并查找 in#8080#reporttimeb（本地 cluster，格式为 in#port#serviceName），查看配置中的服务地址(address)、端口(port_value）是否正确。
健康检查信息 health_checks、熔断配置 circuit_breakers 是否正确。如果不正确，且确认服务没有被熔断，则需要通过提交工单联系后台运维人员处理。

"dynamic_active_clusters": [
{
 "version_info": "2018-10-17T11:31:50+08:00",
 "cluster": {
"name": "BlackHoleCluster",
"connect_timeout": "1s"
 },
 "last_updated": "2018-10-16T19:31:41.792Z"
},
{
 "version_info": "2018-10-17T11:31:50+08:00",
 "cluster": {
"name": "in#8080#reporttimeb",
"connect_timeout": "5s",
"hosts": [
 {
"socket_address": {
 "address": "9.77.7.132",
 "port_value": 8080
}
 }
],
"health_checks": [
 {
"timeout": "5s",
"interval": "10s",
"unhealthy_threshold": 2,
"healthy_threshold": 2,
"http_health_check": {
 "path": "/health"
}
 }
]

如何联系后台运维人员？

您可以通过提交工单的方式联系后台运维人员。
您需要提供以下信息，方便运维人员快速定位问题。

问题：B 服务注册失败，已初步定位，原因在于下发的配置与服务配置不相符。
服务节点信息：A 调用 B 服务，B 服务192.168.3.1，A 服务192.168.2.1。
服务类型信息：A 服务为 springcloud，B 服务为 Mesh。

为什么无法显示 stdout 日志？

对于使用容器部署的应用，在下述两种情况下 TSF 会采集 stdout 日志：

业务容器启动服务进程时不重定向 stdout
此时可以登录上容器所在的机器，通过kubectl logs或者docker logs观察程序自身有无输出 stdout
业务容器启动服务进程时将 stdout 重定向到/data/tsf_std/stdout/logs/sys_log.log
此时可以登录上容器所在的机器，通过kubectl exec或者docker exec进入到容器中，观察上述sys_log.log文件有无内容。

为什么无法显示自定义的文件日志？

检查日志配置项中的日志采集规则

确认日志配置项中的日志路径和应用程序在配置文件中的日志路径相同。
确认日志配置项中的日志解析格式和应用程序在配置文件中的日志解析格式相同。例如如果日志配置项为默认日志配置项（Spring Boot 日志格式），而应用程序实际使用 logback 和自定义的日志 pattern，那么 TSF 无法采集日志。用户需要创建一个 logback 格式的日志配置项，然后关联到部署组。

在日志配置项的详情页中，查看日志配置项是否已经发布到对应的部署组中。
日志配置项修改后，虚拟机部署的应用会自动使用修改后的日志配置项来采集日志，容器部署的应用需要重启部署组（先停止部署组，再启动部署组）后才会使用修改后的日志配置项来采集日志。

如果容器镜像的时区不对，则无法检索到日志，需要在 Dockerfile 中调整时区。

# GMT+8 for CentOS
RUN /bin/cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtimeRUN echo "Asia/Shanghai" > /etc/timezone

为什么实时日志一直加载不出来？

请确认日志配置项已正确配置。
实时日志会有15s时延，即显示从15秒前开始打印的日志。如果一直在加载中，可以确认下最近15s有没有日志打印，如果没有则会一直到有新的日志打印才会显示。

协作者为何无法推送镜像到主账号的镜像仓库？

主账号需要将协作者与 QcloudCCRFullAccess 策略关联，具体操作请参考协作者和子账号使用 TSF。

默认容器是 UTC 时区，和宿主机的时区不一致如何解决？

保证容器的时区和宿主机一致，避免调用链日志时间收集等有偏差。如果基础镜像时区是没调整过的，那么在编写 Dockerfile 时再调整时区，例如基础镜像是 centos，那么微服务 Dockerfile 增加以下配置，并重新 build 即可：

#GMT+8RUN /bin/cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtimeRUN echo "Asia/Shanghai" > /etc/timezone

协作者使用镜像仓库时，为何显示未开通仓库？

如果主账号未开通过镜像仓库，会提示如下图所示信息，此时需要主账号登录 TSF 控制台，开通镜像仓库。主账号开通镜像仓库后协作者/子账号才能继续使用镜像仓库。

协作者身份使用 TSF 发生4102无权限报错如何解决？

协作者在使用 TSF 前，需要主账号将协作者与tsf_PassRole策略关联，具体操作请参考准备工作。

创建策略时出现 resouce 字段格式错误如何解决？

请检查以下信息：

主账号 ID 需要填写在授权策略中。
在 CAM 控制台 > 角色界面查看是否存在 TSF_QCSRole 角色，如果没有，参考准备工作创建角色。
在填写主账号，不需要尖括号。

发生 role not exist 错误如何解决？

协作者或者子账号在使用 TSF 功能时提示 role not exist 错误，此时需要主账号或者具有 QcloudCamRoleFullAccess 权限的用户去创建 TSF_QCSRole，详情参考文档准备工作。

如何保证全局事务的正确执行？

TCC 以主事务函数作为入口，协调控制多个跨库/跨服务的子事务的执行流程，可以保证各个子事务之间的事务特性（一次性 Confirm 或者 Cancel 所有的子事务）。
由于 TCC 不能够保证每个子事务内部的事务性质，因此在使用 TCC 时，建议在每个子事务内部自己执行本地事务，以保证全局事务的正确执行。

业务需要处理什么类型的异常？

主事务函数中主要需要捕获两个异常：

TransactionCancelledException：表示事务失败 cancelled。
TransactionTimeoutException：表示事务超时。

运行时业务抛出的异常会被包装在以上两个异常中，您可以通过getCause()方法获取业务真正的运行时异常：

public class MainTransaction {

SubService subService;@TsfTcc(serviceName = "myTcc", type = TransactionType.ROOT, timeout_ms = 60000)public String beginTcc(MyParams params) throws Throwable {try{
subService.subTry(null,0,params);
} catch (TransactionCancelledException e) {//获取业务运行时真正的异常
Throwable t = e.getCause()return "request canceled."
} catch (TransactionTimeoutException e) {//获取业务运行时真正的异常
Throwable t = e.getCause()return "request timeout."
} catch (Throwable e) {//打印业务异常日志
return "request exception."
}
}
}

业务什么时候会进行回滚？

当前业务只有在子事务 Try 失败时会进行 cancel 操作，当进入 confirm 阶段之后，confirm 失败只会继续重试 confirm，直到超时为止。

Netty 版本冲突时如何处理？

1.10.0.TSF-RELEASE 版本的 SDK 依赖4.1.X 版本的 Netty，用户如果使用 TSF 的 SDK 会引入如下依赖：

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-consul-discovery</artifactId></dependency>

用户可以通过添加 exclusions 标签，避免引入4.0.x 版本的 Netty：

<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-consul-discovery</artifactId>
<exclusions>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-codec-http</artifactId>
</exclusion>
<exclusion>
<groupId>io.netty</groupId>
<artifactId>netty-transport-native-epoll</artifactId>
</exclusion>
</exclusions></dependency>

TSF 与 TKE 的关系是什么？

TKE （Tencent Kubernetes Engine) 是基于原生 Kubernetes 提供以容器为核心的、高度可扩展的高性能容器管理服务。TSF 是以微服务为核心的服务治理平台，用户可以使用云服务器或者容器来部署微服务，其中容器集群管理和容器应用部署使用了 TKE 提供的服务。

产品介绍

产品介绍

功能

服务开发框架

服务治理

数据化运营

相关产品

服务注册发现

应用生命周期管理

分布式配置管理

细粒度服务治理

数据化运营

分布式事务

构建分布式服务系统

应用发布和管理

数据化运营

1.15.0 版本说明

新特性

问题修复及优化

1.14.1 版本说明

新特性

问题修复及优化

1.14.0 版本说明

新特性

问题修复及优化

1.13.0 版本说明

新特性

问题修复及优化

1.12.0 版本说明

新特性

问题修复及优化

1.0.10 版本说明

新特性

问题修复及优化

1.0.9 版本说明

新特性

问题修复及优化

云服务器加入容器集群后，项目属性为何变为"默认项目"？

虚拟机集群内云主机的可用状态为何显示不可用？

TSF 是否支持在同一台服务器上安装多个应用？

TSF 应用实例状态为什么显示 Agent 异常？

容器部署组执行部署操作时提示内存（或 CPU）不足？

如何排查应用是否部署失败？

程序包无法上传如何解决？

在工程的配置文件中，是否需要填写服务注册中心地址？

应用部署成功后，服务列表中为何没有出现服务？

服务实例显示离线状态如何解决？

1. 查看服务配置信息

2. 查看健康检查返回

3. 通过运维接口查看 sidecar 相关信息

4. 调用 clusters 接口

5. 调用 config_dump 接口

如何联系后台运维人员？

为什么无法显示 stdout 日志？

为什么无法显示自定义的文件日志？

为什么实时日志一直加载不出来？

协作者为何无法推送镜像到主账号的镜像仓库？

默认容器是 UTC 时区，和宿主机的时区不一致如何解决？

协作者使用镜像仓库时，为何显示未开通仓库？

协作者身份使用 TSF 发生4102无权限报错如何解决？

创建策略时出现 resouce 字段格式错误如何解决？

发生 role not exist 错误如何解决？

如何保证全局事务的正确执行？

业务需要处理什么类型的异常？

业务什么时候会进行回滚？

Netty 版本冲突时如何处理？

TSF 与 TKE 的关系是什么？