云原生基础设施TCS技术总结与回顾

01

TCS 是云原生时代的基础设施

TCS(Tencent Cloud-native Suite）即腾讯专有云敏捷版 PaaS 平台，提供云原生平台与腾讯自研 PaaS 产品（如 Credis、TDSQL、TSF ）等。同时，TCS 也是腾讯公有云、腾讯专有云TCE以及腾讯 SaaS 产品的通用底座，为腾讯各个云产品在各个场景的输出和交付提供统一的底座。

TCS 云原生基础设施是 TCS/TCE 解决方案中的基础设施与容器平台层，为腾讯的各种云产品私有化输出提供向上屏蔽底层 IaaS 差异的云原生计算、存储、网络等能力。在这最近的两年时间，TCS 经历了几个版本的迭代，保持着高速的技术发展和演进，为众多腾讯产品的私有化项目的中标、成功落地提供技术支撑。

本文将总结 TCS 云原生基础设施在这几个版本迭代中我们所面临的各个技术方向的用户故事、技术方案和成果、实际项目中取得成绩，以及对后续的技术思考。

02

技术图谱总览

● TCS2.0 云原生基础设施

● TCS2.3.0 云原生基础设施

03

技术总结回顾

3.1  容器网络 TCS-CNI

● 用户与技术故事

在 TCS2.0(TCE3.8.0) 版本中，TCS 只提供 flannel(IPIP Overlay) 容器网络能力。在竞争日益激烈的云原生容器领域，flannel 容器网络方案无法为 TCS 容器平台提供强有力的竞争力。

TCS2.1.0 版本立项时，我们期望容器网络技术方案可以是一个持续演进的方案，我们观察到日益火爆的 eBPF 技术以及 eBPF 技术在容器网络的成功项目 cilium 符合我们的需求。在 TCS2.1.0 版本中，我们基于社区的 cilium 深度改造和优化，提供 IPIP 和 BGP 两种网络模式，集成进 TCS 成为高内核(4.14+) 的默认容器网络方案。同时我们自研 IPAM 模块，为 TCS 容器网络提供自动 CIDR 扩容、 IP 保持、指定 IP 等功能。

随着 cilium 在 TCS2.1.0 版本 release，我们接收到了客户更多的关于容器网络的需求，如更丰富的 Underlay 容器网络方案、单集群多容器网络方案、单 Pod 多网卡、RDMA 需求、组播需求等。我们将容器网络方案继续向前演进，基于 multus 形成统一的容器网络扩展框架，集成开箱即用的 cilium、IPIP、VLAN、BGP、RMDA、sriov、host-gw 等容器网络插件，并配合统一的 IPAM 管控和网络规划声明，形成最终的 TCS-CNI 容器网络方案。

TCS-CNI 为 TCS 容器平台和 PaaS/SaaS 产品提供功能丰富、高性能、可扩展、稳定可靠的容器网络，也支撑了 TCS 上层产品如 KubeVM、TCS-Edge 对于容器网络的诉求。在 TCS2.3.0 迭代三版本中，TCS-CNI 已支持在产品页面自行规划客户期望的各种网络类型，可以使用产品页面自助地用上 TCS 提供的强大的容器网络功能。

TCS-CNI 架构图：

● 项目与技术成果

在腾讯公有云迁移到 TCS 底座项目中，TCS-CNI 为腾讯公有云 IaaS 产品管控应用提供 VLAN 容器网络以及 TGW(Tencent Gateway) VIP 直通容器的功能，实现高性能的容器网络与低损耗的负载均衡数据链路。

在诸多需求 Underlay 容器网络的项目中，TCS-CNI 为各个客户按需实施 Overlay、BGP、VLAN、RDMA 等容器网络方案，或者自由组合的混跑容器网络方案，为客户提供 IaaS 无关的高性能容器网络。

在某大型商业银行私有化 CVM(Cloud Virtual Machine，腾讯弹性计算服务) 输出项目中，TCS-CNI 的 IPAM 模块统一为容器和 CVM 实例提供统一的 IP 管理与分配能力。

● 未来展望

TCS-CNI 当前对于 IPv6 的支持较弱，我们会在后续的版本中补齐 IPv6 的能力。在技术先进性方面，我们将持续在 eBPF 领域的投入，优化 TCS 容器数据面的链路，以及利用 eBPF 的能力扩展可观测、安全领域（NetworkPolicy）的 TCS 网络增值产品。

3.2  L4 负载均衡 TCS-LB

● 用户与技术故事

在 TCS2.0(TCE3.8.0) 版本中，TCS 本身没有负载均衡模块，只提供在 TCE 场景下对接 TGW 的方案（tgw-cloud-provider），即根据 K8s Service 规则自动的对接 TGW 控制面 API 建立转发规则，数据面由 TGW 提供。

随着诸多 SaaS/PaaS 云产品使用 TCS2.1.0 作为底座单独或者组合输出，云产品业务方对我们提出了云原生 L4 负载均衡的需求。由于 TGW 有诸多的依赖，并且本身占用较大资源，而 TCS 本身要实现最终 8C16Gi 的资源小型化目标，因此我们必须得探索一个可 “小” 的云原生 L4 负载均衡方案。在 TCS2.1.0 版本立项时，我们选定 keepalived/LVS 承载数据面功能，并自研了一套基于 K8s API 的控制面组件，最终形成 keepalived-manager 方案。

随着 keepalived-manager 在 TCS2.1.0 版本成功落地，并在一些 TCS 项目和配合云产品集成 TCS 取得较好效果，云产品业务方对我们的 L4 负载均衡提出了更高的要求。keepalived-manager 当时面对最棘手的新需求是如何使用 “小” 的资源去支持 “大” 的多 AZ 高可用 VIP 问题，以及 keepalived-manager 单主工作的模式如何突破单机的性能限制去实现高吞吐的需求。

经过我们的分析和评估，keepalived-manager 可能已经不能继续支撑我们向前走，我们关注到了和 TCS-CNI 同源的 eBPF 技术方案 -- XDP。经过我们调研和学习 Google Maglev、Facebook Katran 以及 Cilium 等开源项目或者论文，我们决定基于 XDP 自研一款基于云原生的负载均衡模块 -- TCS-LoadBalancer(TCS-LB，内部工程代号 director)。TCS-LB 长于云原生服务于云原生：不需要适配可以移植到任何 Linux 发行版和硬件，并基于 K8s 提供简单、可控、可观测的运维能力。TCS-LB 为 TCS 本身，以及 SaaS、PaaS 产品提供可“大”可“小”的负载均衡能力：“小”体现在可以混部在 8C16Gi 的 TCS Master 上提供高性能的数据转发能力，“大”体现在可以提供 AZ（Available Zone） 容灾的高可用能力以及水平扩展的高性能能力。

TCS-LB 在 TCS2.2.1 版本完成初步的能力，并与 TCS2.3.0 版本完成正式 release，成为 TCS2.3.0 默认的负载均衡模块。

TCS-LB 架构与流量图：

TCS-LB 是站在一些技术产品的巨人肩膀上的自研模块：

● 项目与技术成果

在某省级核酸健康码中，TCS 的 keepalived-manager 提供稳定可靠的 L4 负载均衡能力，承接所有核酸码流量负载到核酸 APP 容器。

在某智能汽车私有化 COS（Cloud Object Storage，腾讯对象存储产品） 输出项目中，TCS-LB 可水平扩展的能力为 COS 提供高吞吐的 L4 负载均衡能力，当前客户提供持续稳定的 20GB 吞吐流量，预计 2023 年将会扩容到 100GB 吞吐能力。

在诸多 TCS PaaS 项目中，TCS-LB 为 Credis/TDMQ 等云产品提供高性能以及 AZ 高可用的负载均衡 VIP 能力。

● 未来展望

TCS-LB 当前不支持 IPv6，和 TCS-CNI 一样，在下个版本我们需要补齐 TCS-LB IPv6 的能力，做到 TCS 底座全模块 IPv6（双栈）的能力，以提升 TCS 在等保测评和技术领先性上的优势。同时，TCS-LB 也要逐步优化与 TCS-CNI 的数据面链路，将公有云 TCS 底座实践的 VIP 与 Underlay 网络 Pod 直通的能力移植回 TCS-LB。

3.3  轻量虚拟机 KubeVM

● 用户与技术故事

在诸多客户将应用转型容器化的过程中，难免有一些应用暂时无法使用容器化部署，因此我们经常接收到基于容器调度的轻量虚拟机的需求。在我们 TCE 内部，也遇到了用轻量虚拟机去解决 TCE 小型化的需求：使用容器底座同资源池的机器，调度和生成轻量虚拟机来部署 TCE 暂时无法容器化的管控和支撑。

在 TCS2.2.1 版本，我们 release 了 TCS KubeVM 轻量级虚拟机资源调度与交付模块。TCS KubeVM 使用开源 Kubevirt 技术深度整合 TCS 其他插件与能力，包括存储插件 LocalPV CSI、网络插件 TCS-CNI、GPU 插件等，提供在 TCS 之上开箱即用的生产和管理虚拟机的功能。

在 TCS2.3.0 版本，KubeVM 逐步走向更稳定和更易用，重要的特性包括集成 TencentOS 虚拟化三套件，TCS-Edge 边缘节点 VM workload 管理、提供虚拟机生命周期管理、镜像管理、GPU 支持、虚拟机登录、快照与冷迁、监控告警、支持等能力。

TCS KubeVM 作为一种基于容器编排的虚拟机交付方案，它使得虚拟机业务和容器业务可以经过统一的 Kubernetes 编排调度运行在同一个集群，在实现管控资源损耗更小的同时，使用同个资源池和超卖策略可以提高资源利用率的目的。基于 KubeVM 的特性，我们实现了 TCE3.10.0 小型化架构，以及基于 KubeVM 的 TCS PaaS 版架构：

● 项目与技术成果

TCE3.10.0 小型化项目中，我们使用 KubeVM 技术统一容器与 VM 的资源池和并统一控制资源分配与超卖，达成 TCE 小型化的架构目标。

在一些客户没有 IaaS 的项目中，KubeVM 为 TCS PaaS/SaaS 产品部署提供轻量虚拟化能力，已达成节省资源与实现隔离等要求。

● 未来展望

KubeVM 当前版本还是更着重实现功能，以及打造稳定性和可运维性上，在产品能力上的建设还较薄弱，我们期望在下个版本补齐产品能力上的短板。同时，我们也需要将各个 TCE 小型化项目、基于 KubeVM 的 TCS 项目在各个客户环境完成顺利交付，在实践和落地的过程中，将 KubeVM 产品打磨的更加稳定与易用。

3.4  边缘计算 TCS-Edge

● 用户与技术故事

随着云原生技术的火热，并将云原生技术延展到 IoT 边缘设备上，许多客户以及 PaaS/SaaS 产品业务方对我们 TCS 提出了 Edge 能力的需求。

在 TCS2.3.0 版本，TCS-Edge 完成 release。TCS-Edge 基于腾讯云开源边缘计算框架 SuperEdge 实现的边缘计算私有化交付方案，实现 TCS 从云到边缘的云原生能力延伸，实现从中心云管理边缘资源以及边缘工作负载的能力。

TCS-Edge + KubeVM 提供的边缘节点管理 VM 工作负载功能是 TCS-Edge 一大特色，可以为各个边缘站点提供轻量的虚拟机服务。

TCS-Edge 架构图：

● 项目与技术成果

在某交通站点云边一体项目中，TCS-Edge + KubeVM 的组合将为各个交通站点的边缘节点提供轻量虚拟机工作负载能力。

在某头部新能源公司私有化 TI(TencentCloud TI Platform，腾讯全栈式人工智能开发服务平台) 输出项目中，TCS-Edge + IECP(腾讯云物联网边缘计算平台) + TI 为客户的边缘节点提供节点管理与 GPU 计算能力。

● 未来展望

在后续的 TCS 版本中， TCS-Edge 会提供更完备的产品化能力，包括单集群多架构、边缘节点池（NodeUnit/NodeGroup） 及边缘工作负载产品化能力等。同时，我们期望将更多 TCS 的扩展功能和模块可以延伸到 Edge 边端，如 TCS-LB、SSM 容器化中间件等，更加提升 TCS-Edge 的产品竞争力。

3.5  容器本地存储 LocalPV

● 用户与技术故事

容器本地存储 LocalPV 为容器平台提供本地盘容量调度和 quota 限制的存储卷能力，TCS 作为最底层的底座以及 IaaS 无关的容器平台，LocalPV 是 TCS 不可或缺能力，许多支撑组件以及云产品管控，都构建在 LocalPV 之上。在 TCE3.8.0 与 TCS2.0 版本中，TCS 提供的 LocalPV 已经具备了本地卷 quota 的能力以及部分容量调度的能力。在 TCS2.1.0 和 TCS2.3.0 演进中，我们规划并实现了诸多云产品的诉求。

在 TCS2.3.0 版本 release 后，我们对 LocalPV 提供了更强大和完备的功能，如更准确的容量感知、单 Pod 使用多 LocalPV、机器多本地盘调度、以及基于 xfs reflink 的备份(实现 CoW)和恢复的能力。TCS2.3.0 提供的 LocalPV 能力是一些开源本地卷项目以及友商竞品所不具备的，在为 TCE/TCS 接入的云产品提供稳定可靠的本地卷能力的同时，也为 TCS 容器平台本身提供强有力的竞争力。

LocalPV 备份与恢复：

● 项目与技术成果

云巢（腾讯数据库 PaaS 产品）私有化项目中，云巢使用 TCS LocalPV 的备份与恢复能力达成数据库实例的备份与故障快速恢复能力。

● 未来展望

TCS2.3.0 LocalPV 的 quota 基于 loopdevice 实现，性能有一些损耗。对于 TCE/TCS 云产品、KubeVM 日益严苛的要求，我们已在开发基于 prjquota 的 quota 方案，期待早日上线提供性能更好的 LocalPV 能力。

3.6  容器平台与调度增强

● 用户与技术故事

TCE3.8.0/TCS2.0 版本中，TCS 使用 Kubernetes 1.16 构建容器平台与底座。在 TCE3.10.0/TCS2.3.0 版本中，TCS 平滑升级到 Kubernetes 1.18 以满足更多的插件兼容性并修复诸多潜在的 CVE 与 Bug。

TCS2.3.0 容器平台和调度能力也做了许多扩展，如 NodePort 静态端口、NodePort 黑名单、IP 保持与指定调度、资源保持（适用于 KubeVM 以及有状态 Pod 场景）、Topo 感知与指定调度、qGPU 调度能力等。这些容器平台与调度能力的增强为 TCE/TCS 云产品提供更强的容器平台能力，也为 TCS 容器平台本身提供更强的竞争力。

● 未来展望

每个 TCS/TCE 大版本的迭代，我们都期望可以升级 Kubernetes 版本，以保持 TCS 本身的云原生技术和社区最新版本接轨，保持技术先进性。我们正积极与 TKE 团队合作共建，将 TCS 容器平台与调度能力的增强功能合入 TKE 发行版，并基于 TKE 发行版研发后续 TCS 容器平台能力。

3.7  集群管理与 DIOH

● 用户与技术故事

TCE3.8.0/TCS2.0 版本中，TCS 的部署（Global 集群）基于 tke-installer 加上脚本部署 TCS Addon 组件的模式。该方式扩展性和可维护性较差，一些管控组件启动参数或者镜像的变更可能需要重新打包整个 tke-installer，并且无法客户现场实现自动化的管控组件升级。同时，参差不齐的 Addon 部署脚本导致部署成功率非常低下。

在 TCS2.2.0 版本启动时，我们立项了 DIOH 项目，DIOH 是 "deploy in one hour" 的缩写，提供 TCS 所有组件统一、高质量的部署方案，达成 “我们可以自动化、高质量的去任何客户家里交付任何组件的任何 commit 版本” 的目标。DIOH 的领域涵盖研发效能、自动化部署测试和集群管理等领域。

在 DIOH 项目中，我们统一了 TCS 底座组件包格式，组件 Owner 需要统一提供 Chart 模板、容器镜像 Dockerfile、以及 rpm 模板。基于统一的组件包，我们研发了新的 TCS 集群管理方案(cluster-operator/node-operator) ，相比于老版本方案只控制部署阶段的定义并让组件 Owner 提供部署脚本，新的 cluster-operator/node-operator 方案强调标准化所有的生命周期控制：统一的包格式以及安装、升级控制，有助于提升集群部署、升级的健壮性，也更容易在研发态的自动化流水线去新建 TCS 集群或者更新组件，最终运行 e2e 测试以提升 TCS/TCE 组件质量。

TCS2.3.0 版本 release 时，我们基于新版本的集群管理和 DIOH 方案为各个项目提供自动化、高效的集群管理以及子集群管理能力，同时也提供丰富的配置去满足客户不同高可用和特性需求。

DIOH 集群管理架构图：

DIOH 集群管理 API：

● 未来展望

我们正与 TKE 产品团队共建下一代 ClusterAPI（ClusterAPI v2），TCS 与 TKE 的集群管理与控制方案在后续版本逐步走向融合与统一，为各个腾讯云产品提供向上统一的 API，方便集成与接入。

3.8  多集群负载

● 用户与技术故事

在 TCS2.1.0 版本中，TCS 支持了多集群能力。我们清楚的知道，多集群能力并不是用户真正的最终需求，用户的最终需求应该是需要把应用调度和部署到多个集群中，实现多集群的容灾能力。

在 TCS2.3.0 版本中，我们集成了 clusternet 实现多集群的应用调度与资源下发能力。同时，我们基于 TCS-CNI 的路由宣告与服务发现框架，实现了多集群应用互通与服务发现能力 -- ClusterMesh。相比于 cilium 社区的 ClusterMesh，TCS 实现的 ClusterMesh 更加轻量，并且不依赖 cilium 体系可以在低版本内核中运行，实现内核与 CNI 插件无关的多集群服务发现能力。

用户在 TCS2.3.0 版本中，可以使用 TCS 提供的 clusternet 与 ClusterMesh 功能，轻松的实现多集群应用的发布，并且让多集群的应用实现跨集群的容灾能力。

TCS 集成 clusternet:

多集群应用架构图与 ClusterMesh 实现：

● 未来展望

当前 TCS 提供的多集群资源下发与应用调度是黑屏能力，在下个版本我们会实现该方面能力的产品化。

3.9  云原生装机 DCOS 与 Igniter

● 用户与技术故事

TCE3.8.0 版本中，DCOS 产品的技术架构复杂并且职责和其他 TCE OSP 产品不清晰，并且技术架构的复杂度带来产品的可运维性与可扩展性差。在 TCE3.10.0 版本中，我们逐步开始做 DCOS 产品整体架构的调整与优化，我们将服务器监控能力后端统一到云哨平台，后续也会将服务器资产管理能力后端统一到 CMDB，并向上都做 API 的兼容。做完重构后的 DCOS 定位更聚焦在 “云原生装机平台” 的定位，在装机并发性能上有大量的提升，同时 DCOS 本身也越来越轻量，在 TCS2.3.0 版本中，DCOS 可以搭配 TCS 单独输出。

Igniter 是 TCS 团队自研的裸机装机系统，相较于老版本装机系统，其解决了装机 IP 不足问题、支持多装机工具并存、提供多元配置化装机。同时，Igniter 在架构上同 DHCP 解藕，允许 DHCP 独立高可用部署，对带外 IP 提供更强的运维和管理能力。在 TCS2.3.0/TCE3.10.0 版本中，我们和基础技术服务与交付团队共建，集成了 Igniter + auto_install_os 解决方案，为各个客户环境的开区装机提供快速、敏捷的批量装机能力。

DCOS 架构与流程图：

● 项目与技术成果

在 TCE 交付项目以及 TCS 面向物理机交付的一些项目，使用 Igniter + auto_install_os 实现客户现场开区装机，大大提升了开区交付效率。同时，TCS 的 DCOS 模块为 CVM(vstation) 提供 CVM IP 管理、CMDB 自动注册等能力。

● 未来展望

在下个版本中，我们落地 Igniter 与 DCOS 的下一代架构 “云原生装机平台”，除了架构本身更简单、运维更方便之外，还实现了 Igniter 与 DHCP 的高可用能力。同时，在在产品能力上，我们会提供多网卡、IPv6 支持等功能。在机型适配上，我们会持续加大力度支持星星海机型的适配，也会引入和适配特殊机型，如银杉智能网卡机型，以提升 TCE 的产品竞争力。

3.10  高可用架构

● 用户与技术故事

TCE3.8.0 版本中，整个 TCS 的多 AZ 高可用依赖于云产品 TGW VIP 多 AZ 高可用能力，因此在不具备 ECMP VIP 能力的 TCS2.0/TCS2.1.0 版本中，TCS 不具备多 AZ 高可用能力。随着 TCS 更多云产品的接入，TCS 急需对齐该部分能力去满足云产品单独或者组合输出时，仅用 TCS 底座资源就可以满足多 AZ 高可用的能力。

在 TCS2.3.0 版本中，借助 BGP 模式 TCS-LB 模块可水平扩容的能力，TCS 为接入的云产品提供了自动 failover 的 AZ 高可用能力。

在一些客户环境交付评审时，我们发现一些客户无法提供 BGP/OSPF 动态路由实现 ECMP 能力的机房，但是却要求 TCS 以及 TCS 云产品提供 AZ 高可用能力。在 TCS2.3.0 版本后期，我们引入了一种新的多 AZ 架构，使用多个 AZ 内的多个 VIP，基于 DNS 去实现 AZ 高可用能力，为没有 ECMP 能力的客户提供 AZ 高可用能力。

基于 BGP 模式 TCS-LB 的高可用架构：

无 ECMP 的高可用架构：

● 项目与技术成果

在一些客户要求多 AZ 高可用的 TCS PaaS/SaaS 项目中，BGP 模式 TCS-LB 为各个云产品以及 TCS 平台提供多 AZ 能力，并在客户测试与实际容灾场景中取得理想的成绩。

在一些客户要求多 AZ 高可用但是又无法提供动态路由能力的项目中，TCS 使用无 ECMP 的高可用架构方案为各个云产品提供提供多 VIP 切换的 AZ 高可用能力。

● 未来展望

TCS 在明年会结合 TSF 或者协助客户去达成异地多活的能力，帮助更多的云产品在客户环境达成 “金融级” 的高可用容灾能力。

3.11  小型化架构与资源调优

● 用户与技术故事

TCE3.8.0 架构下，交付一套 TCE 需要较多的 TCE 管控资源，如最小 IaaS 产品集合的交付需要起步 17 台底座和支撑机器，在应标或交付较少售卖资源的项目时，管控资源的用量经常被挑战。

TCE3.10.0 版本上，我们做了小型化架构。小型化架构的目标除了 “小” 之外（目标最小 IaaS 产品集合 5 台管控起步），更重要的是我们期望它是后续版本标准化的架构，并且做到历史版本的平滑升级。TCE 小型化架构作为标准化的架构体现在：可以使用 TCE 小型化架构交付单 AZ、多 AZ、多 Region 等各种规模、容灾需求的场景；而做到历史版本的平滑升级，TCE 小型化架构需要尽可能将底座与支撑的形态和历史版本保持统一，尽可能地做到架构变动对云产品无感知。

TCE 小型化架构落地与实现也面临着架构调整带来的复杂性与难度，我们采用多步走的策略。第一阶段，我们将底座容器、支撑、UnderlayCVM（部署 TCE 管控的 CVM）资源做了合池，再将合池之后的资源做统一超卖与分配。当然，原先的中间件支撑与 CVM 模式部署的管控依旧无法容器化，合池之后由 TCS 底座的 KubeVM 提供轻量的 VM。当前第一阶段已完成，我们实现了最小 IaaS 产品集合的交付起步 10 台底座的目标，并且验证了双 AZ 高可用能力与全量云产品。

第一阶段小型化架构（最小 IaaS 产品集合）：

● 未来展望

我们正在完成小型化第二阶段的目标，做到最小 IaaS 产品集合的交付起步 5 台。第二阶段使用的技术手段包括更精细化的资源监控与分配、优化同类型冗余支撑、简化架构、云产品本身容器化与资源优化等。

3.12  国产化适配与调优

● 用户与技术故事

TCE/TCS 的愿景是做成硬件架构和操作系统无关的产品，我们积极的适配各种国产化硬件。

TCS2.3.0 以及 TCE3.10.0 的底座已完成适配常见的国产化架构机型，如飞腾、鲲鹏、海光均已完成适配。在国产操作系统方面，TCS 完成了麒麟、TencentOS 各版本的适配。

对于国产化硬件来说，多核工作模式在不绑核、或者错误绑核的情况下普遍表现较差，因此，想要达到较理想的用户体感，最重要还是在国产化硬件上做软件的性能调优。我们在各个国产化机型适配中总结了 CPU/Numa 邦核的经验，目前正在沉淀到产品化能力中，接入 TCS 的产品可以开箱即用 TCS 平台提供的 CPU 精细化调度能力。

TCS CPU 精细化调度架构：

● 项目与技术成果

在某大型政务专有云项目 PoC 技术竞标中，TCS 与 TDSQL 在飞腾-S2500 国产化硬件上不断探索与优化性能，将客户提供的测试应用优化到极致性能，在与友商竞争中以两倍 QPS 的性能指标获得全胜，帮助 TCE 顺利中标该项目。

04

结语

TCS2.3.0 云原生基础设施技术与产品做了非常多的演进，很多技术和产品都是“从 0 到 1”完成的建设。我们期望在后续的版本上，投入更多的精力在产品易用性和稳定性上的打磨，让 TCS 云原生基础设施相关产品在产品和稳定性上赢得用户的口碑和影响力。同时，我们也会投入更多精力去建设易交付、易运维的 TCS 云原生基础设施产品，节省交付于运维成本。在 TCS 云原生基础设施自身技术演进方面，我们将持续保持对技术的热情，将更多的先进和可靠的技术集成到 TCS，保持 TCS 的产品竞争力。