云原生虽已被公认是新一代云计算发展方向，但若从应用程序的开发、测试、运行以及最后部署到云环境中的过程看，实现云原生业务要打通许多技术。

微服务通常被看做是云原生的代表技术之一，在单体应用中，云原生基本发挥不出优势，故而有人说现代应用程序的趋势就是“微服务+云原生”，以及内含在其中的容器、敏捷与 DevOps 等技术组合。互联网海量和多变的业务，正要求多种功能的同时实现，同样是要集合各种技术。

8 月 1 日，线上举办的 CloudNative + Open Source Virtual Summit China 2020，TARS 基金会分论坛上发布了 K8STARS 项目，这是一个整合了 K8S 和微服务框架 TARS 功能的项目，对于 TARS 项目本身来说，弥补了其自身的自动扩伸缩等能力，增强了其云原生特性。

放到云原生中来看，微服务架构应用系统后期会面临许多挑战，比如持续集成、持续交付、持续部署、监控、认证、授权以及快速配置计算资源等等，而 Kubernetes 提供如资源的调度、弹性伸缩、自动化部署等能力，是许多微服务在实施应用时不可或缺的。

正如这几日 TARS 基金会分论坛上 Linux 基金会执行董事 Jim Zemlin 在开场时提到的：TARS 基金会致力于解决在使用微服务方面可能出现的问题，包括减少开发和服务治理的难度。而基金会中最主要的项目 TARS 也不仅仅只是一个 RPC 框架。

TARS 基金会成立于今年 3 月 10 日，是 Linux 基金会中微服务开源生态的代表。这次论坛上，TARS 基金会主席单致豪详细介绍了基金会目前的生态，并公布了近期加入 TARS 基金会的 4 个开源项目：测试相关的 TARS Benchmark 与 TARS JMeter，服务网关 TARS Gateway，以及重磅发布的云原生微服务治理方案 K8STARS。

其中 TARS Gateway 是一套基于 TARS 框架开发的通用 API 网关，请求使用 HTTP 协议，后端同时支持 TARS-tup&TARS-TARS 协议、TARS-json 协议、HTTP 协议。除了协议转发之外，还支持流量控制与黑白名单等功能；TARS JMeter 是一款针对 TARS 协议进行私有化定制的 JMeter 测试插件，它具有易用性强、支持分布式、支持复杂场景与数据可监控等特点；TARS Benchmark 是专门为 TARS 服务量身订做的无码压测工具，具备易用性、高性能、可伸缩、支持动态随机和数据实时反馈的特性。

下边具体说说 K8STARS。

K8STARS：基于 K8S 与 TARS 的云原生微服务治理方案

微服务架构已然成为云原生中最核心的技术之一，TARS 结合 Kubernetes 带来的优势突破或让 TARS 这个微服务框架在云原生生态中更上一层楼，也将让 TARS 基金会覆盖更宽广的领域。

先介绍一下 K8STARS，简单来讲，K8STARS 是便于将 TARS 服务运行在 Kubernetes 中的解决方案，它的主要特性包括：

• 保持 TARS 原生的开发框架能力
• 支持 TARS 的名字服务自动注册和配置删除
• 支持原有 TARS 服务平滑迁移到 Kubernetes 等容器平台
• 无侵入性设计，与运行环境无偶合关系

腾讯高级工程师、TARSGo 核心开发者利开园在分享中更具体地分析了 K8STARS 解决方案。简单来说，K8STARS 保留了 TARS 的名字服务、高性能 RPC 及服务治理功能，整合了 K8S 的资源调度等能力，使得 TARS 具有更多的云原生特性。

微服务的理念下，使用容器作为基础设施，能够实现快速部署、快速迭代。而随着容器化技术兴起，Kubernetes 可以说已经成为基于容器的 DevOps+微服务+容器的黄金标准。整合 K8S 成为许多微服务框架完善功能的一个大方向。

利开园总结，业务规模增长会带来四大挑战：

• 随着用户流量增长，需要分布式架构，以及更高性能的缓存等；
• 为了满足高性能的要求，需要更多的研发人员以及更好的协调，这就需要通用的通信协议、多语言开发框架等；
• 随着服务器数量的增长，还有庞大数量的集群需要管理，此时需要机房故障时的自动解决方案；
• 最后服务进程数量暴涨，处理好并发的服务也是一个难点。

TARS 的主要能力是高效率开发，如代码自动生成、多语言、名字服务等等；高质量运维，如服务可视化、无损变更、配置管理与容灾容错等。“然而，在面对业务规模增长带来的技术挑战时，TARS 也有需要增强的地方。”

“TARS 可以使开发者专注业务逻辑，而不需要关心底层，但是 TARS 过去是没有自动扩伸缩能力的。”利开园介绍：“TARS 需要用到 K8S 的自动调度和自动扩缩容的能力。”

不过 TARS 和 K8S 存在许多重合的能力，想要整合并不简单。同时 K8S 生态中，Istio 是最热门的微服务解决方案，此时是不是直接放弃 TARS 转向 Istio 更好？

▲中间部分为重合的能力

对比了 TARS 和 Istio 的优缺点之后，考虑到 TARS 服务迁移的成本，开发团队觉得有必要使用 TARS，将 TARS 改造成支持在 K8S 中调度的微服务解决方案。

▲选型中考虑的 TARS 与 Istio 的情况

具体怎么整合呢？TARS 比 K8S 多出的能力包括高性能 RPC 框架、日志监控、调用链以及指标监控等服务治理能力；二者重合的功能有服务部署、版本管理等。整合首先要对重合功能做出取舍，因为 K8S 支持自动调度，基于 Docker 镜像可有更好的版本管理实现；而在名字服务部分，TARS 支持网关流量，发现单点故障时可快速屏蔽问题，配置管理也更适合在生产环境中使用。

通过在 TARSregistry 增加了 3 个接口，用于 TARS 名字的自动注册/心跳上报和节点下线，同时提供一个 TarsCLI 命令行工具，用于分配端口/生成配置/上报心跳以及节点下线，最终整合出了 K8STARS 这一全新的解决方案，让 TARS 服务运行在 Kubernetes 上。

具体细节可以查看项目说明与源码：https://github.com/TarsCloud/K8STARS

从 TARS 到 TARS 基金会到云原生微服务开源生态

前边提到，本次分论坛较为全面地对外介绍了成立于今年 3 月的 TARS 基金会的情况，这也是其首次分享其生态相关信息。

作为基金会，发展的是生态而不是单一项目，TARS 基金会介绍其希望吸纳上下游的开源项目，以建立更好的微服务生态。包含但不限于基础设施、存储、开发框架、服务治理、DevOps 和基于任何编程语言的应用。具体来讲，目前基金会中已经有 30+ 项目，7 家成员组织，以及获得了覆盖游戏、视频直播、互联网工具、娱乐、交通、社交网络与金融等领域 100+ 家公司/企业的采用。

此外，分论坛还有来自不同公司不同业务的技术专家分享了 TARS 在其各自领域上的具体应用情况，比如自腾讯的陈德贤、阅文的马延波与虎牙的毛茂德分享了各自业务中采用 TARS 进行微服务架构改造的情况；同时，TarsJava 技术负责人俞慧涛分享了阅文 TARS 的海外最佳实践；Arm 企业级架构师、TARS 技术监督委员会成员 Tina Tsou 分享了如何通过 Arm 架构和 Ampere Computing 支持 TARS 平台上的云原生工作负载加速；来自 Apache APISIX 的 TARS 技术监督委员会成员温铭强调了 API 网关在云原生体系中的重要性；最后腾讯 CSIG 高级测试专家鲁珺聊到了如何实现微服务性能评测。

从周边项目、开发者与社区成员的发展情况，从项目演进，到硬件架构扩展，再到应用实践以及性能测试等方面，TARS 基金会分论坛在此次云原生峰会中为开发者呈现了一个正在快速发展中的云原生微服务开源生态。

最后，或者这张生态全景图可以很好地勾勒出 TARS 基金会未来的发展全貌，当然，生态还在动态演进，具体会如何发展，是留给 TARS 基金会这一新生组织的一大问题，也是关注云原生微服务开源生态的开发者的一大期待。

转自 https://www.oschina.net/news/117632/tars-foundation-in-cncf-summit-2020