原生应用 “0” 代码改造，无侵入接入，纵享丝滑般上云体验！

腾讯云中间件
735 阅读9分钟

导读

您还在为代码改造而感到烦恼吗？您还在为云平台各种条条框框所限制而闷闷不乐吗？您还在为业务与云服务框架耦合耿耿于怀吗？同志们，福音来啦！最新版腾讯微服务平台 TSF 重磅推出原生应用接入方式，无需改造一行代码，无需重新编译，无需重新构建程序包，原生 Spring Cloud 应用直接上！

作者介绍

张培培

腾讯云微服务团队高级工程师

TSF Mesh研发及负责人

热衷于云原生和开源技术，在容器、Service Mesh、消息队列、区块链等领域拥有丰富经验，目前致力于Service Mesh 技术的落地和推广

背景介绍

Spring Cloud 提供了微服务系统架构的一站式解决方案，并利用 Spring Boot 的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控、分布式调用链等，通过 Spring Cloud 提供的一套简易的编程模型，我们可以在 Spring Boot 的基础上轻松地实现微服务项目的构建。

然而，这仅仅是帮助开发者开发微服务应用带来了便利，最终开发出的应用需要在生产环境运行起来，因此，我们还需要：

  1. 稳定的运行环境，如虚机环境或者容器环境，并能对微服务应用进行生命周期管理。

  2. 高可用的注册中心，Spring Cloud 虽然支持使用  Eureka、 Zookeeper 或 Consul 实现服务注册发现，但需要我们自行搭建并保证其高可用。

  3. 统一的控制平面对服务进行治理，Spring Cloud 整合了大量的服务治理组件，但没有一个统一的控制平面进行管理，这对大规模的微服务治理带来了不少的压力。

  4. 可视化的数据运营服务，如日志服务、监控服务、分布式调用链服务，如 Spring Cloud 通过引入 Sleuth 实现分布式调用链，并和 Zipkin、HTrace、ELK 兼容，但这些后端服务需要我们自行搭建并保证其稳定性。

也就是说，我们开发者开发完应用、构建好 Jar 包也只是第一步，要让应用稳定运行和持续运营，还需要一个微服务平台来满足上面的要求，这正是 TSF ——腾讯微服务平台 （Tencent Service Framework）的价值所在：

  1. TSF 提供了一站式应用生命周期管理服务。提供从应用部署到应用运行的全流程管理，包括创建、删除、部署、回滚、扩容、下线、启动和停止应用并支持版本回溯能力。

  2. TSF 提供了高效的服务注册发现能力。支持秒级的服务注册发现并提供本地注册信息缓存、服务实例注册发现异常告警、注册中心跨 AZ 区容灾等完善的高可用保障机制。

  3. TSF 提供了细粒度服务治理能力。支持服务和 API 多级服务治理能力，通过配置标签形式进行细粒度的流量控制，实现灰度发布、就近路由、熔断限流、服务容错、访问鉴权等功能。

  4. TSF 提供了立体化应用数据运营。提供完善应用性能指标监控和分布式调用链分析、服务依赖拓扑、日志服务工具，帮助您高效分析应用性能瓶颈及故障问题排查。

既然 TSF 满足一切运行要求，那对于一个原生的 Spring Cloud 应用，是否能直接接入 TSF 运行起来呢？

原有接入TSF方式

TSF 支持原生 Spring Cloud 微服务框架，但对于旧版 TSF（v1.27或之前版本），Spring Cloud 应用需要做些改造才能接入；

旧版 TSF 支持普通应用和 Mesh 应用两种接入方式。

对于普通应用接入，需要进行 SDK 依赖和注解代码的改造：

  • pom.xml中引入TSF对应Spring Cloud版本的SDK依赖

<parent>
        <groupId>com.tencent.tsf</groupId>
        <artifactId>spring-cloud-tsf-dependencies</artifactId>
        <version><!-- 调整为 SDK 最新版本号 --></version>
</parent>

<dependency>
    <groupId>com.tencent.tsf</groupId>
    <artifactId>spring-cloud-tsf-starter</artifactId>
    <version><!-- 调整为 SDK 最新版本号 --></version>
</dependency>

  • 向 Application 类中添加注解 @EnableTsf：

// 下面省略了无关的代码
import org.springframework.tsf.annotation.EnableTsf;
@SpringBootApplication
@EnableTsf
public class ProviderApplication {
    public static void main(String\[\] args) {
        SpringApplication.run(ProviderApplication.class, args);
    }
}

对于 Mesh 应用接入，以虚机部署为例，则需要按照 Mesh 方式构建程序包：

1. 添加spec.yaml 文件

apiVersion: v1
kind: Application
spec:
  services:
    - name: provider
      ports:
        - targetPort: 10881
          protocol: http
      healthCheck:
        path: /health

2. 添加 start.sh 启动脚本

!/bin/bash

already\_run=\`ps -ef|grep "spring-cloud-provider-1.0.jar"|grep -v grep|wc -l\`
if \[ ${already\_run} -ne 0 \];then
        echo "provider already Running!!!! Stop it first"
        exit -1
fi
nohup java -jar spring-cloud-provider-1.0.jar 1>stdout.log 2>&1 &

3. 添加 stop.sh 停止脚本

#!/bin/bash

pid=\`ps -ef|grep "spring-cloud-provider-1.0.jar"|grep -v grep|awk '{print $2}'\`
kill -SIGTERM $pid
echo "process ${pid} killed"

4. 添加 cmdline 进程执行命令文件

java -jar spring-cloud-provider-1.0.jar

可以看出，无论是普通应用接入还是 Mesh 应用接入，都需要做些改造才能接入 TSF，这样势必是带来一些问题：

  1. 虽然两种接入方式对于单个微服务的改造量不大，但对于大规模应用的项目改造量将是巨大的。

  2. 对于普通应用接入，引入了 TSF 的 SDK 依赖，而 TSF SDK 的依赖包与业务的依赖包及其造成版本冲突，也就是需要业务找到并修改对应的冲突包版本。

  3. 由于引入了 TSF 的 SDK 依赖，业务代码也即和 TSF 平台强耦合，这对不希望和云厂商平台耦合的用户来说非常的不友好。

那 TSF 有没有一种接入方式，既不需要引入 TSF 依赖、改造代码，也不需要重新构造程序包呢？

原生应用接入方式

新版TSF（v1.28）来啦！

推出第三种接入方式——原生应用接入，支持原生 Spring Cloud 应用真正的无侵入接入，无需改造一行代码，无需重新编译，无需重新构建程序包，现有应用 Jar 包直接部署接入 TSF ！

登录 TSF 控制台，部署原生 Spring Cloud 应用仅需简单 4 个步骤：

1. 创建资源，虚拟机集群或容器集群

图片

2. 创建应用，应用类型选择【原生应用】

图片

3. 导入原生 Spring Cloud 应用 Jar 包或者上传镜像包

图片

4. 创建部署组，部署原生 Spring Cloud 应用

图片

我们知道，Spring Cloud 提供了丰富的服务治理套件，那接入 TSF 后这些治理能力是否兼容呢？以下是 TSF 支持的原生治理能力，基本覆盖了常用的核心能力：

图片

除此之外，TSF还额外提供了以下几个主要能力：

  • 文件配置

  • 服务统计

  • 服务路由

  • 服务鉴权

  • 服务限流

实现原理

也许大家会好奇：原生应用不做任何改造就能享受上面丰富的服务治理能力，TSF 是如何做到的？

下面来简单介绍下 TSF 原生应用接入的基本原理！

下图是 Spring Cloud 两个微服务通过 Eureka 注册中心简单的调用过程，可以看出，服务治理的起点是注册中心，服务提供者先把自己注册到注册中心，服务消费者再从注册中心获取服务提供者的实例列表，而服务熔断、全链路灰度、路由、容错、负载均衡等治理能力都是在服务提供者的实例列表的基础上实现的，因此要在 TSF 中实现这些服务治理能力首先需要接入 TSF 的注册中心，而在不改变原应用服务注册和发现代码的前提下，如何实现呢？

图片

这里，我们引入了一个 registry-proxy（注册中心代理）组件，以 sidecar 模式部署在 Spring Cloud 应用侧，并将应用注册中心的地址配置为本地 registry-proxy 的地址，这样，应用和原注册中心的交互请求引到 registry-proxy 上来了，registry-proxy 可以接收发往注册中心的各个请求，再根据不同请求做以下处理：

  • 服务注册请求——代理注册到TSF注册中心

  • 服务发现请求——代理注册中心直接返回只包含服务提供者服务名的实例列表

  • 心跳上报请求——代理上报心跳到TSF注册中心

对于1和3很容易理解，2中代理注册中心为什么只返回服务名呢？

上面我们通过一个代理注册中心把 Spring Cloud 应用注册到 TSF 的注册中心，那下一步就是实现运行时的服务治理，这就是2中只返回服务名的原因，因为原生应用的服务治理底层是通过 TSF Mesh 来实现的，服务消费者通过服务名向服务提供者发起的请求会被劫持到部署在应用侧的 Mesh sidecar 里，这样 sidecar 便可对服务间的请求流量 “为所欲为”，即实现服务熔断、全链路灰度、路由、容错、负载均衡等治理能力。

最终，通过原生应用的方式接入到TSF后，服务间调用流程是这样的：

图片

由于原生应用的服务治理最终托管给了 TSF Mesh 来支持，因此对于接入的 Spring Cloud SDK 版本没有要求，E版、F版、G版可以尽情接入使用。

总结

Spring Cloud 微服务架构核心是开发端 SDK 框架和后端支撑服务如注册中心 Eureka，通过引入 SDK 依赖和相关服务治理注解，开发人员能快速实现一个微服务应用，但对于后端支撑服务，特别是要支撑生产环境大规模的微服务接入，将面临巨大挑战；而这恰恰是 TSF 微服务平台的价值所在，TSF 提供了强大的后端支撑服务能力，无论是注册中心、数据运营中心还是服务治理控制中心，都具备工业级别的高可用性。

但原先 TSF 提供的两种接入方式，对原生应用存在其他待优化的问题；因此，为降低 Spring Cloud 应用接入 TSF 的门槛，彻底摆脱对云平台框架的依赖，让用户与云厂商解耦，TSF 推出了原生应用接入方式，无需任何改造即可享用 TSF 各种强大的服务治理能力！

往期推荐

《拥抱 Agent，“0” 代码玩转 Trace 之 OpenTelemetry 系列第二弹！》

《超有料！万字详解腾讯微服务平台 TSF 的敏捷开发流程》

《【超详细】前端程序员只需六步，实现微服务架构转型初实践》

avatar
文章
阅读
粉丝