腾讯云账号解封 腾讯云微服务平台TSF体验
话说那天我盯着TSF控制台首页整整三分钟，右上角那个「新建集群」按钮像极了初恋——看着心动，点又不敢点。毕竟上一次手抖点错「强制删除生产环境配置」，是靠备份脚本和同事的白眼双重抢救才活下来的。
所以这次，我决定把TSF（Tencent Service Framework）当个「新同事」来处：不预设好感，不盲目信任，先观察，再请教，最后一起搬砖。以下，是我在腾讯云TSF上从「Hello World」到「能扛住压测」的27小时实录——没有PPT式术语堆砌，只有截图没截全的报错、Ctrl+C/V后被改了三遍的YAML、以及一句被运维小哥笑着摇头说「你这配置，像极了我刚毕业时写的」的扎心点评。
一、开局别急着建集群，先搞清自己在哪儿
TSF不是开箱即用的咖啡机，它默认把你扔进「混合云迷宫」：K8s集群、虚拟机集群、容器服务TKE……选错入口，后面全是泪。我一开始直奔「容器集群」，吭哧吭哧配完镜像、端口、健康检查，结果部署时报错：no available node pool found。翻文档发现——哦，原来容器集群必须先在TKE里创建好节点池，TSF只负责“调度”，不负责“盖楼”。
建议新手直接选「虚拟机集群」，理由朴实：你有CVM就行，不用管什么Pod反亲和、污点容忍。我选了广州区一台4核8G的CVM，系统盘50G，挂载一块100G数据盘（后面日志和配置中心会吃空间），安全组放行8080、9411（Zipkin）、30000-32767（NodePort）。装完JDK8、OpenJDK11双版本（避免老项目跪），再执行TSF提供的curl -sSL https://xxx/install.sh | bash——注意！这个脚本会自动重启supervisord，如果之前跑着别的进程，记得提前备份配置。
二、Spring Boot接入？别抄Demo，抄它的pom.xml就行
官网Demo里那个@EnableTsf注解，我粘过去编译就红。查源码才发现：TSF SDK分两个坐标——tsf-spring-cloud-starter（适配Spring Cloud Edgware+）和tsf-spring-boot-starter（纯Boot系）。我项目用的是Spring Boot 2.3.12，却下了Edgware版，版本号对不上，连DiscoveryClient都注入失败。
最终方案：删掉所有TSF依赖，只留这一行：<dependency>
<groupId>com.tencent.tsf</groupId>
<artifactId>tsf-spring-boot-starter</artifactId>
<version>1.24.0.RELEASE</version>
</dependency>
然后application.yml加三行：tsf:
app-id: your-app-id
namespace-id: your-namespace-id
cluster-id: your-cluster-id
——ID全在TSF控制台「应用管理」→「命名空间」里复制，别手敲，大小写敏感，且中间带短横线，输错一个字符，启动日志里只会打一行discovery client init failed，绝口不提原因。
三、灰度发布？不是点两下就完事，是「流量切片+配置隔离+人工兜底」三件套
我以为灰度=「把10%流量切给v2.0」。结果TSF的灰度策略叫「按标签路由」。我给v2.0实例打标version=v2，再在控制台配规则：header[x-version]=="v2" → v2实例。测试时发现：Postman加Header一切正常，但前端调用始终走v1——因为Nginx没透传x-version头！
补救措施：在TSF网关里配「请求头透传规则」，或干脆改用「权重灰度」：v1占90%，v2占10%，不用改代码。但要注意——权重是「实例级」而非「请求级」，如果v2只有1台机器，而v1有10台，那实际流量比≈1:10，不是10%。我们后来加了个「灰度开关配置项」，用TSF配置中心动态控制，前端加个调试开关，真灰度前先切1%用户，看监控不报警再放大。
四、链路追踪？Zipkin界面好看，但得自己喂数据
TSF自带Zipkin UI，地址是http://tsf-gateway/zipkin。但打开后一片空白。查日志发现：应用没上报span。原因？TSF的trace starter默认只采集/actuator/**和/health路径。我们的业务接口是/api/v1/order，不在白名单里。
解决方案有两个：一是加配置spring.sleuth.web.skip-pattern=清空跳过正则；二是更推荐的方式——在TSF控制台「链路追踪」→「采样配置」里，新增一条规则：path=/api/**, sampling-rate=1.0。这样不用改代码，随时启停，还能按路径设不同采样率（比如支付路径100%，查询路径1%）。
五、熔断降级？别信「自动熔断」，先写好fallback
TSF集成Sentinel，但控制台里「熔断规则」默认是关闭的。打开后填QPS阈值、熔断时长，保存——你以为完事了？不。你的Feign Client必须显式声明fallback类，且fallback类里每个方法返回值要和原接口一致，否则Sentinel捕获异常后直接抛IllegalStateException，连日志都不打。
血泪教训：我们有个订单查询接口，fallback写了return new Order(null, "降级中", 0)，结果TSF监控里看到大量java.lang.NullPointerException。排查半天，发现是fallback里调用了另一个可能为空的对象字段。结论：fallback逻辑必须极度精简，最好只返回兜底字符串或缓存数据，别碰任何外部依赖。
六、最后说点掏心窝的
TSF不是银弹，它是把刀——切豆腐快，砍钢筋就得换姿势。它的强项在于：和腾讯云生态咬合紧密（CMQ、CLS、TSE一键对接）、企业级权限粒度细（能精确到「张三只能看dev命名空间的配置」）、故障自愈能力扎实（实例挂了自动拉起，配置更新秒级生效）。短板也很坦诚：文档案例偏理想化，真实环境常要组合技；社区活跃度不如Spring Cloud Alibaba；非Java项目支持较弱（Go/Python SDK文档少得可怜）。
所以我的建议是：新项目起步，直接上TSF，省去自建Nacos+Sentinel+SkyWalking的折腾；老项目迁移，先拿一个非核心模块试点，把「配置中心迁移」「链路打标」「降级预案」三件事跑通，再逐步铺开。别贪快，微服务不是比谁先上线，而是比谁先稳住。
腾讯云账号解封 写完这篇，我顺手把TSF控制台首页的「新建集群」按钮点了。这次没犹豫。因为我知道，背后不是黑盒，是一台台CVM、一段段YAML、一次次重试后记下的参数——它们共同组成了我对「可控的分布式」最朴素的理解：不神化平台，也不贬低自己；每一步踩实，才算真的落地。
