Coder-Codex-Gemini (CCG)

Docker 推出了一个全新的平台，旨在简化从本地开发到生产级云环境的迁移过程。

Docker Kanvas的推出标志着这家容器先驱企业在战略方向上的重大转变。它不再仅仅是一个容器引擎，而是蜕变为面向现代工程团队的综合部署协调器。该工具现在已通过Docker Hub以扩展的形式提供，它采用人们熟悉的 Docker Compose 语法，弥合了本地工作站与复杂云基础设施之间的鸿沟。

该平台的核心理念在于，保持软件工程师现有的工作流程不变，同时由系统管理 Kubernetes 部署的复杂性。平台在后台处理云资源配置的繁琐细节，减轻了开发人员的认知负担。传统上，从本地 Compose 文件迁移至可投入生产环境的 Kubernetes 集群需要大量的手动操作，通常涉及创建复杂的 YAML 清单文件和定制部署脚本。

Kanvas 通过将应用程序架构直接转换为适合云原生环境的部署工件来自动化这一迁移过程。这一转变标志着 Docker 迈入基础设施即代码（IaC）领域的新时代。该工具是与Layer5合作开发的，可以为 Terraform 和 Pulumi 等平台生成配置，能够在各种云提供商之间保持部署的一致性，同时将源代码逻辑保存在开源GitHub存储库中。

在 Docker 官方博客上，贡献者 Aabid Sofi 和 Ajeet Singh Raina 特别说明了这一转变对开发社区的重要意义。他们指出，该平台实现了从简单 Compose 文件到全托管工作负载的无缝衔接，彰显了基础设施可视化管理的便捷性。他们解释说，该工具的目标是，无论目标环境是托管的 Kubernetes 服务还是无服务器平台，都能保持 Docker 生命周期的简洁性。

虽然 Kanvas 提供的自动化功能为已经投资于 Docker 生态系统的团队带来了明显的好处，但它进入了一个竞争激烈的市场，其中已经有若干成熟的替代方案。目前，众多企业依赖Helm或Kustomize管理 Kubernetes 部署，虽然这些工具可以实现高度的定制化，但往往伴随着比较陡峭的学习曲线。此外，诸如Okteto或Garden这样的内部开发平台则长期致力于解决开发环境与生产环境之间的差异问题，通过提供更贴近生产环境的远程开发环境来实现这一目标。

该平台还能生成应用架构的详细图解，帮助进行调试和架构审查。这种可视化功能基于特定的架构框架构建，可追踪分布式系统中微服务之间的依赖关系。通过清晰地呈现服务交互图谱，该系统能帮助团队在服务进入生产环境前识别潜在的瓶颈或安全配置错误。随着行业不断地向平台工程转型，能够抽象化基础设施复杂性的工具正变得日益重要。Docker 的最新举措表明，他们将长期致力于通过标准化来简化面向普通开发人员的云原生技术栈。

https://www.infoq.com/news/2026/01/docker-kanvas-cloud-deployment/

太平洋时间 2026 年 1 月 6 日——西门子与英伟达宣布大幅拓展双方战略合作，将 AI 引入现实世界。双方将共同开发工业 AI 与物理 AI 解决方案，为各行各业及其工作流带来 AI 驱动的创新，并加速彼此的运营发展。

为支持开发工作，英伟达将提供 AI 基础设施、仿真库、模型、框架与蓝图；西门子将投入数百名工业 AI 专家及领先的硬件与软件资源。

西门子股份公司总裁兼首席执行官 Roland Busch 表示：“我们正在共同打造工业 AI 操作系统——重新定义物理世界的设计、建造与运行方式，以推动 AI 规模化应用并在现实世界产生影响。通过结合英伟达在加速计算与 AI 平台方面的先进经验，与西门子在硬件、软件、工业 AI 与数据方面的优势，我们正赋能客户以更全面的数字孪生更快地开发产品，实现实时调整生产，并加速从芯片到 AI 工厂的各项技术发展。”

英伟达创始人兼首席执行官黄仁勋表示：“生成式 AI 与加速计算正引发一场新的工业革命，使数字孪生从被动仿真跃迁为物理世界的主动智能。我们与西门子的合作将全球领先的工业软件与英伟达的全栈 AI 平台融合，弥合从想法到现实的鸿沟，助力各行业在软件中模拟复杂系统，并在物理世界中无缝的实现自动化与运营。”

加速全工业生命周期

那么，两大巨头的合作的具体计划是什么？

西门子与英伟达将携手打造贯穿产品与生产全生命周期的 AI 加速工业解决方案，实现更快的创新、持续优化以及更具韧性、可持续性的制造。双方计划自 2026 年起，以德国埃尔朗根的西门子电子工厂为最初蓝图，打造全球首批完全由 AI 驱动、具备自适应能力的制造基地。

借助由软件定义自动化与工业运营软件构成的“AI 大脑”，并结合 NVIDIA Omniverse™ 库与英伟达 AI 基础设施，工厂能够持续分析其数字孪生，在虚拟环境中测试改进，并将经验证的洞察转化为车间的实际操作变更。

这将使从设计到部署的决策过程更快、更可靠，在提高生产力的同时缩短调试时间并降低风险。双方计划将这些能力扩展至关键垂直领域，富士康、HD 现代、凯傲集团（KION Group）与百事公司等客户已在评估部分相关功能。

随着合作关系的深化，西门子将完成其仿真产品组合的全面 GPU 加速，并扩展对 NVIDIA CUDA-X™ 库与 AI 物理模型的支持，使客户能够更快运行规模更大、更精确的仿真。在此基础上，双方将进一步推进生成式仿真，利用 NVIDIA PhysicsNeMo™ 与开源模型，构建具备自主能力的数字孪生，实现实时工程设计与自主优化。

通过将工业 AI 的操作逻辑应用于半导体与 AI 工厂，西门子与 NVIDIA 将加速 AI 变革的核心引擎。以半导体设计为起点，并基于英伟达对西门子工具的广泛使用，西门子将把 NVIDIA CUDA-X 库、PhysicsNeMo 与 GPU 加速能力集成到其 EDA 产品组合中，重点关注验证、布局与工艺优化等关键环节，目标在核心工作流中实现 2～10 倍的性能提升。

此次合作还将引入布局指导、调试支持和电路优化等 AI 辅助功能，在满足严苛可制造性要求的同时，大幅提升工程生产力。这些能力将共同推动 AI 原生引擎的设计、验证、可制造性以及数字孪生方法，缩短设计周期、提升良率并交付更可靠的成果。

西门子与英伟达还将联合打造可复用的新一代 AI 工厂蓝图，加速工业 AI 变革，并为双方的 AI 加速工业产品组合提供高性能基础。

该蓝图将平衡新一代高密度计算在供电、散热与自动化的需求，同时确保技术在速度与效率上的优异表现，实现从规划设计到部署运营的全生命周期优化。

这一合作将英伟达的 AI 平台路线图、AI 基础设施专业知识、合作伙伴生态，以及基于 NVIDIA Omniverse 库的加速仿真能力，与西门子在电力基础设施、电气化、电网集成、自动化与数字孪生领域的优势相结合。双方致力于加速全球工业级 AI 基础设施的部署，提升能效并增强韧性。

今天这篇博客文章由 Streamfold 的 Mike Heffner 和 Ray Jenkins 撰写。他们是 Rotel 的维护者，该项目是一个用 Rust 编写的开源工具，致力于实现高性能、资源高效的 OpenTelemetry 数据采集。

TLDR;

大规模系统中的效率至关重要：哪怕是资源消耗的小幅下降，也可能带来显著的成本节约和效率提升。

OTel + ClickHouse 的基准测试：我们构建了一套数据管道，用于评估将流式追踪数据写入 ClickHouse 的性能。

Rotel 实现了 4 倍性能提升：我们展示了如何将 OTel Collector 每核每秒处理 13.7 万个追踪跨度 (trace span) 提升到 Rotel 的 46.2 万个，并详细说明了多项关键的性能优化。

工具和资源：文末提供了我们在基准测试中所用的工具清单。

引言

在 PB 级规模下运营一个可观测性平台，需要持续关注资源利用效率。即便是每核性能或内存使用上的细微改进，也能大幅降低基础设施开销。

本文源自我们在丹佛举办的一场 ClickHouse 技术见面会的演讲。在会上，我们分享了我们对 Rotel 的开发工作。Rotel 是一个面向大规模系统的高性能 OpenTelemetry 数据平面 (data plane)。

得益于其高压缩比和良好的成本效益，ClickHouse 越来越多地被用于大规模的 OpenTelemetry 负载中。而在这些系统中，OTel Collector 往往是整条数据管道中成本最高的部分。

最近，ClickHouse 发布了一篇关于大规模系统中效率重要性的文章（https://clickhouse.com/blog/scaling-observability-beyond-100pb-wide-events-replacing-otel），并介绍了他们在内部平台 LogHouse 上运行 OTel 的实际经验。

其中有个细节引起了我们的注意：

“OTel Collector：使用超过 800 个 CPU 核传输每秒 200 万条日志。”

按每核每秒约 2500 条日志计算，对于典型的日志行来说，这意味着一个 8 核服务器每秒仅能传输约 10MB，远远低于现代硬件的处理能力。而 ClickHouse 每核每秒最多可处理超过 1.25 万条 OTel 事件，吞吐能力是前者的五倍以上。因此，当前的瓶颈在数据采集端，而非存储端。尽管我们无法复现 ClickHouse 内部的 LogHouse 平台，但我们认为，对现代 OpenTelemetry 数据管道进行基准测试仍具有重要意义。因此，我们希望借此次演讲探讨一个核心问题：将追踪数据发送到 ClickHouse 时，不同的 OpenTelemetry 数据平面表现如何？

本文将逐步介绍我们构建的基准测试流程，比较 OpenTelemetry Collector 和 Rotel 的性能。我们搭建了一套合成的追踪数据管道，先通过 Kafka 传输追踪跨度，再写入 ClickHouse。在 OTel Collector 达到 110 万跨度/秒的基准测试后，我们展示了通过以下几项优化如何让 Rotel 在相同硬件上实现最高 370 万跨度/秒的处理能力：实现 JSON 的二进制序列化、分析 Tokio 任务调度性能 (perf analysis of Tokio task management)、以及引入改进的 LZ4 压缩算法。

文末我们还列出了用于此次基准测试的框架和工具。

基准测试框架

在进入测试结果之前，我们先介绍一下评估 OpenTelemetry Collector 和 Rotel 所采用的测试方法。如果你感兴趣，也可以直接跳转到结果部分，链接见这里。

追踪数据管道

我们此次基准测试的重点是将追踪跨度 (trace span) 写入 ClickHouse，因为在大型系统中，追踪数据增长极快。我们参考了一个高度可靠的流处理管道进行建模，选用 Kafka 作为日志流层。测试目标是模拟这样一种场景：大量边缘采集器将数据发送至 Kafka 流，由少数几个核心采集器批量写入 ClickHouse。在这个管道中，Rotel 和 OTel Collector 使用相同的 Kafka Protobuf 编码，因此两者可以互换使用。

评估方法

我们希望找出在固定硬件条件下，单个采集器能够稳定支持的最大吞吐量，重点关注的是采集效率，而非系统扩容能力。测试的关键是观察单节点在不降级的前提下可以被“压榨”到什么程度，同时也控制在我们的评估预算范围内。我们选择网关采集器作为测试核心组件，因为它直接将数据输出至 ClickHouse，而后者在处理大批量数据插入时效率最高。为实现更高的批处理效率，部署少量、但能力更强的网关采集器是理想方案，因此我们专注对该组件进行优化与测量。

饱和识别

我们通过两个关键信号来判断采集器是否已达到处理极限：

• 内存激增：当下游系统产生反压时，采集器会将数据缓存于内存中，导致内存快速增长；

• Kafka 消费延迟：如果采集器处理速度赶不上 Kafka 流的速度，其消费延迟会不断增加，即“上次读取的消息时间”与“当前时间”的间隔在变大。

测试配置

每项测试我们都将数据管道运行在接近饱和的边缘状态，持续 15 分钟，记录以下两个关键指标：

• 每秒处理的追踪跨度数，由负载生成器记录；

• 向 ClickHouse 写入的数据吞吐量（MB/s），由 AWS Cloudwatch 监控采集。

带宽这一指标有助于统一比较不同环境下的处理能力，因为追踪跨度在实际场景中大小差异可能很大。在测试配置中，边缘采集器会将数据打包优化后发送至 Kafka，这样可以减少消息总数，同时提高单条消息的体积。

测试过程中，我们也记录了 Rotel 与 ClickHouse 的平均 CPU 使用率。

OpenTelemetry 的 ClickHouse 数据模式

本次测试使用的 ClickHouse 表结构同时兼容 OpenTelemetry Collector 与 Rotel。这一数据模式是官方推荐的方案之一，适用于 ClickHouse 与 ClickStack 可观测性平台，支持 OTel 的指标、日志与追踪数据。

OTel 的数据模型高度依赖键值属性（key/value attributes）来描述基础设施与应用环境中的关键特征，有助于进一步分析。最初在 ClickHouse 中，这类字段采用 Map 类型存储。但近期，OTel Collector 引入了支持 JSON 列类型（JSON column type）的新特性，使得原有结构可以转换为 JSON 格式。虽然这会给 ClickHouse 带来更高的 CPU 压力，但查询表达能力也因此大大增强。我们的测试选择启用这一新特性。你可以在这里查看我们使用的完整 ClickHouse 追踪数据结构（https://gist.github.com/mheffner/dc332a61f3b9ba1d03fd7c7d5c1b7fbb）。

我们的测试配置中还使用了 ClickHouse 的 Null 表引擎，这是一项关键优化手段。Null 引擎可以接受写入请求但不进行实际存储，因此能帮助我们剥离磁盘 I/O 的影响，专注评估写入吞吐能力与数据结构正确性。在完成峰值吞吐的测试后，我们会进一步评估 ClickHouse 如何处理真实的磁盘写入负载。

负载生成器

我们尝试使用 telemetrygen CLI 工具生成数据，但它难以达到所需的数据量。因此我们改用之前内部构建的负载生成器，该工具最初用于测试 OpenTelemetry 与其他遥测管道。该项目可在 Github 的 otel-loadgen 仓库中找到。它还具备验证端到端数据传输等增强功能，我们将在后续文章中进一步介绍。

我们构造的每个追踪包含约 100 个跨度，涵盖丰富的属性与元数据。和所有合成测试一样，这些数据并不完全等同于真实生产环境中的流量。

测试硬件

所有基准测试均在 AWS EC2 实例上执行。数据管道的每一层组件部署在独立的实例中，所有实例均位于同一可用区，以确保测试结果的一致性与准确性。

为了最大化磁盘吞吐能力，我们将 Kafka 和 ClickHouse 的数据卷直接挂载在实例自带的 NVMe 本地磁盘上。所有测试均使用 Amazon Linux 2023 操作系统，通过 Docker Compose 编排运行各个组件。

本次基准测试的目标是评估单台网关采集器主机所能承载的最高吞吐量。我们最终选择的测试机器为 m8i.2xlarge 实例，配备 8 核 CPU 和 32GB 内存。随着测试规模扩大，数据管道中的其他节点进行了扩容，但网关采集器始终保持不变，便于横向对比。

测试 OpenTelemetry Collector

测试从 OpenTelemetry Collector 开始，它在测试中既作为边缘采集器，也作为网关采集器。

测试配置

你可以在这里查看 Docker Compose 的配置文件（https://github.com/streamfold/rotel-clickhouse-benchmark/blob/main/docker-compose-otelcoll.yml）。

测试结果如下：

在运行单个 Collector 实例时，我们在处理速率达到约 70 万个追踪跨度每秒（约 40 MB/s）时遇到了性能瓶颈。此后内存占用开始持续上升，尽管此时 CPU 利用率尚不足 50%。

OTel 的 Kafka 接收器采用单个 goroutine（轻量线程）处理消息，这很可能成为吞吐量的限制瓶颈。我们尝试了若干 Kafka 参数调整，包括消息大小限制等，但都未能显著提升性能。于是我们转向横向扩展方案，在同一主机上启动第二个 Collector 实例（通过 Docker Compose 的 scale: 2 设置）。

当两个 Collector 实例各自消费一半 Kafka 分区后，系统最大稳定吞吐量达到 110 万追踪跨度每秒（69 MB/s）。一旦超过这个阈值，发送队列开始堆积，内存使用迅速上升。当队列完全填满后，Kafka 接收器仍然会继续读取消息，但会直接丢弃数据。这意味着表面上 Kafka 消费延迟没有上升，但实际上我们已经在丢失追踪数据！

测试期间，网关采集器的 CPU 峰值使用率超过 83%，成为主要瓶颈。而 ClickHouse 的 CPU 使用率维持在 23% 左右。

测试 Rotel

测试配置

你可以在这里查看 Rotel 的 Docker Compose 配置（https://github.com/streamfold/rotel-clickhouse-benchmark/blob/main/docker-compose-rotel.yml）。

测试结果如下：

Rotel 同样使用一个接收循环从 Kafka 拉取数据，与 OTel Collector 架构类似。这使我们初步判断存在串行处理瓶颈。果然，当我们在主机上运行两个 Rotel 实例并充分利用 CPU 后，吞吐量大幅提升。

在两个 Rotel 实例并行运行时，我们实现了每秒 145 万个追踪跨度（76 MB/s）的最大吞吐能力，较 OTel Collector 提升约 1.3 倍。继续提升负载后，我们观察到 Kafka 消费延迟开始缓慢上升，说明消费速率已逼近极限。

此时，网关采集器 CPU 使用率达到 91.3%，成为新的瓶颈；ClickHouse CPU 使用率也升至 60.4%。

我们随后继续挖掘进一步的优化空间，将注意力转向了如何更高效地处理 JSON 列类型的数据传输。

优化 RowBinary 格式下的 JSON 编码

在 Rotel 中，我们基于官方的 Rust ClickHouse 库 clickhouse-rs 进行了改造。该库使用的是 RowBinary 格式——一种面向行的二进制序列化协议，通过 HTTP 与 ClickHouse 进行数据读写。相比之下，OTel Collector 所使用的 Go 驱动和 ClickHouse 内部组件则采用面向列的原生协议。

在处理 JSON 列时，clickhouse-rs 的默认做法是：先将 JSON 内容转为字符串后再发送。虽然 ClickHouse 本身不会以原样字符串存储 JSON 列，但这一“字符串化”过程是为了传输而必须进行的。不过，这样做在高并发情况下代价很大：客户端需要序列化 JSON，服务端则需重新解析，还必须扫描键名和字符串值以转义引号、反斜杠等字符。尤其当字符串体量较大时，这一过程非常耗资源。

在 ClickHouse Slack 社区的帮助下，我们发现其实可以将 JSON 列直接编码为 RowBinary 原生格式。这种方式下，JSON 会被序列化为一系列键值对，每个键为字符串，紧跟一个表示值类型的标签，再跟上该值的原始二进制内容。这种结构可以跳过整个 JSON 的序列化解析过程，从而实现更高效的结构化数据传输。

比如，考虑下面这样一个简单的 JSON 对象：

{  "a": 42,  "b": "dog",  "c": 98}

RowBinary 格式下的编码方式如下：

首先，它会将键值对的数量以变长整数（varint）编码，例如上例中是 03 对；然后逐个对键值对编码。每个键会先写入一个表示字符串长度的 varint（如 01），再写入字符串本身，接着是对应值的编码。如果值的类型在 JSON 声明中已知（如上例中的键 a 是整数 42），那么会直接用固定类型编码，如 2a 00 00 00 00 00 00 00。如果类型未声明，则使用动态类型编码方式，例如键 c 用 0a 表示 Int64 类型，后跟值 98（62 00 00 00 00 00 00 00）。最后，键 b 表示字符串类型（15），跟上字符串长度 03 和字符串内容 “dog”。

相比传统的 JSON 传输方式，这种方法在客户端和服务端两端都能显著减少序列化和解析的资源消耗。虽然 clickhouse-rs 库目前尚未原生支持这种编码方式，但我们计划参与贡献该功能的开发。

重新测试

在将 Rotel 升级为使用上述优化编码后，我们重新进行了性能测试，以评估实际效果。结果显示，虽然总体吞吐量依然维持在之前的峰值——每秒 145 万个跨度未变，但 ClickHouse 服务器的 CPU 使用率下降了约 10%，网关采集器的 CPU 占用也略有减少。这种改善在多次测试中均表现稳定，说明服务端解析负担确实得到了缓解。

需要说明的是，此次测试中使用的合成负载并未包含大量长字符串，同时每个跨度的属性数量也与真实生产环境可能有所不同。因此，虽然客户端的改进不明显，但我们相信，在处理属性字段较多、字符串数据较大的实际业务场景中，这种更快的 JSON 序列化路径将带来更明显的性能收益。

用一个意想不到的技巧将吞吐量翻倍（定位并解决内存分配器锁争用）

在这轮测试中，为了充分利用网关采集器主机的 8 个 vCPU 并将事件吞吐量提升至每秒 145 万条写入 ClickHouse，我们必须同时运行两个 Rotel 实例。Rotel 的 Kafka 接收器逻辑原本运行在一个 Tokio 异步任务中，其处理流程简化如下：

这种实现方式存在两个主要问题：

1. 整个处理流程是串行执行的，缺乏并行能力；

2. 数据反序列化（unmarshaling）是一项高度依赖 CPU 的操作，容易阻塞 Tokio 的执行线程。

Tokio 是 Rust 语言的异步运行时，采用协作式调度模型。这要求任务在运行过程中需主动在 `.await` 或其他让出点交还执行权给调度器。网络上已有大量文章探讨该机制的重要性以及忽视它可能带来的严重性能问题。通俗来说，一个 tokio 任务应尽可能靠近 `.await` 点，业界建议任务在两个 `.await` 之间的执行时间应控制在 10 到 100 微秒以内。

在 Rotel 的 exporter 模块中，我们使用了一个专用线程池来处理诸如数据序列化与压缩等 CPU 密集型任务。而在 Kafka 接收流程中，rust-rdkafka 库会将解压缩工作分派至后台线程，在调用 `recv()` 之前完成。但最初我们依然将数据的反序列化逻辑保留在 Tokio 异步任务中。随着分析深入，我们确认反序列化过程极其耗费 CPU，因此决定将其改为异步提交到与 exporter 共用的线程池中，以避免阻塞主线程。

经过这一重构后，Kafka 接收器的主处理循环结构如下：

loop {  select! {    message = recv() => {        unmarshaling_futures.push(spawn_blocking(unmarshal(message)))         },    unmarshaled_res = unmarshaling_futures.next() => {        send_to_pipeline(unmarshaled_res)    }  }}

我们随后在网关采集器上使用单个 Rotel 实例重新运行测试，并将负载生成器设置为此前的最大值——每秒 145 万个 trace span。结果系统依旧稳定运行。但让我们颇为意外的是：CPU 使用率相比优化前下降了约 40%！

原先我们之所以要运行两个 Rotel 实例，是因为单个实例未能充分利用主机资源，Kafka 接收模块存在明显的串行处理瓶颈。而此次重构将反序列化逻辑迁移至专用线程池后，这一限制被有效解除。我们预期，在这种并行架构下，单实例就能实现与双实例相同的吞吐性能，并维持类似的资源利用率。

在看到 CPU 占用大幅下降后，我们继续提升负载压力。最终，我们成功将吞吐量从每秒 145 万条提升至 360 万条 trace span，实现翻倍增长！

当处理速率达到每秒 360 万条时，CPU 占用再次达到约 93%，系统达到新一轮饱和。

在验证性能大幅提升后，我们开始着手分析背后 CPU 效率提升的具体原因。为此，我们借助 Linux 的 Perf 工具以及 flame graph（火焰图），对优化前后的 Rotel 构建版本进行了性能剖析，从而定位 CPU 时间的实际开销位置。

使用 Flamegraph 剖析 Rotel 的 Kafka 接收器

我们针对 Rotel Kafka 接收器的旧版本与新版本重新运行了一轮测试，并捕获了 flamegraph（火焰图）用于性能分析。起初乍一看，两者并未显现出明显差异。你是否能发现其中关键？在两个版本中，我们都观察到：将追踪数据准备并导出至 ClickHouse 占据了主要运行时间，此外，接收器中的消息反序列化操作（在 prost::message::Message::decode 函数中执行）也消耗了相当多的资源。这类负载会创建大量生命周期极短的对象，因此系统在内存分配与释放上耗费了大量时间。

旧版本：

新版本：

使用 Linux Perf 评估接收器优化前后的变化

通过运行 perf stat，我们发现两个版本在底层表现上差异巨大。

perf stat -c cycles,instructions,cache-misses,cache-references,context-switches,cpu-migrations 

旧版本

295612663445 cycles 264853636815 instructions # 0.90 insn per cycle 615670230 cache-misses 1867733351 cache-references 1224819 context-switches 1230 cpu-migrations 50.296446757 seconds time elapsed

新版本：

150590256805 cycles 287007890213 instructions # 1.91 insn per cycle 598469068 cache-misses 1163669589 cache-references 37675 context-switches 43 cpu-migrations 43.716966122 seconds time elapsed

新版本平均每周期执行 1.9 条指令，每秒仅发生 862 次上下文切换。尽管这在指令级并行性（ILP）方面不算极致表现，但相较之下已经有明显进步。而旧版本平均仅能达到 0.9 条指令/周期，且上下文切换次数竟高达每秒 24,350 次 —— 新版本将此指标降低了约 32.5 倍！说明旧版本几乎无法并行处理，线程频繁被挂起与唤醒，调度开销巨大。

此外，CPU 迁移数据也显示出改进：新版本平均仅有 1 次迁移/秒，表明线程在相同 CPU 核上保持良好的缓存亲和性，而旧版本则高达 24.5 次/秒。这些迹象显示，旧版本中调度器难以保持线程驻留在固定核心上。

新版本具备更优秀的并行处理特性，使得我们可以进一步扩大吞吐负载。而这一切的背后，仅仅是我们将部分任务拆分至独立线程处理。

我们原先推测旧版本性能瓶颈可能源于 Tokio 执行线程被阻塞，导致运行时不得不频繁轮询、空转，甚至尝试工作窃取。但 perf report 的深入分析为我们揭示了更具体的问题。

深入分析 perf report 结果

通过 perf record 捕获更详细的运行数据后，我们对比了优化前后的性能差异。

在新版本中，大部分计算时间用于压缩数据、将 OTLP 转换为 ClickHouse 所需的数据行结构、以及内存分配与释放等正常开销，整体运行表现健康。

但旧版本的问题非常突出：15% 的运行时间用于释放内存，而压缩和构造数据的时间仅占 9.75%，相比之下新版本达到了 20%。同时，我们发现大量 CPU 时间耗费在如下底层函数中：_raw_spin_unlock_irqrestore、finish_task_switch.isra.0、__lll_lock_wait_private 与 __lll_lock_wake_private。

开启子调用视图后，我们发现这些锁操作多数出现在内存释放阶段。

这些函数具体负责什么？

• _raw_spin_unlock_irqrestore 是 Linux 内核中的函数，用于释放自旋锁并恢复中断状态。当任务即将被抢占时会调用它，以便调度器执行上下文切换；

• finish_task_switch.isra.0 是编译器优化后的上下文切换清理函数，负责完成切换后的调度收尾；

• __lll_lock_wait_private 和 __lll_lock_wake_private 是 glibc 内部函数，用于 mutex 互斥锁等同步机制的实现。

值得注意的是，这些锁相关的函数在释放内存时频繁出现，暗示我们的旧版本在这一过程中产生了严重的锁争用。

回过头来看旧版本的 flamegraph，这一问题其实非常明显。理想情况下，如果我们能使用类似差分 flamegraph（differential flamegraph）工具对比两个版本图谱，可能会更快定位瓶颈点（此处也再次呼吁出现更多易用的 flamegraph 工具）。不过幸运的是，我们还是通过 perf stat 和 perf record 快速找到了问题根因 —— 并不是 Kafka 接收器的串行处理导致瓶颈，而是 ClickHouse exporter 中的序列化函数（TransformPayload）在进行 marshaling 操作时产生了锁争用。

Glibc 多线程内存分配机制下的锁争用问题

从测试数据来看，我们已能清楚解释为何在优化后，系统的 CPU 使用率大幅下降而吞吐能力却反而提升。原先的版本确实消耗了大量计算资源，但主要耗在了无效的系统开销上 —— 本质上，它的大量 CPU 时间都被花在释放内存时的自旋锁等待中。

为了理解这种情况，我们需要简单了解 glibc 默认内存分配器的工作方式。系统将内存划分为多个“arena”（内存区域），每个 arena 都通过一个互斥锁（mutex）来保障内存的分配与释放线程安全。为了减少锁争用，不同线程会尝试创建独立的 arena，随着线程池规模扩大，arena 数量也会同步增长。

但关键在于，如果某段内存在 A 线程上分配，最终却在 B 线程上释放，B 线程就必须锁住 A 所属的 arena，这很容易造成其他线程等待，从而产生锁争用。

在旧版本中，我们在 Kafka 接收器的反序列化（unmarshaling）过程中，于 Tokio 的 I/O 执行线程上分配处理 trace 数据所需的内存。这类异步任务调度在线程数受限的 Tokio executor 上 —— 网关采集器上仅有 8 个线程，刚好一核一个。之后，这段内存在 ClickHouse exporter 的数据序列化过程中被释放，而这部分逻辑则运行在一个大规模阻塞线程池上（包含几十甚至上百个线程）。线程之间频繁切换导致 arena 访问被频繁锁定，进而引发了锁争用问题。

新版本中，我们将反序列化阶段的内存分配也迁移到了与释放操作相同的阻塞线程池中，解决了跨线程释放的问题。随着管道内数据量增加，线程池自动扩展，arena 的数量也随之增加，锁争用的风险被大幅降低。

验证 arena 锁争用：Jemalloc 的对比测试

一位审阅本文的工程师提问：“如果换成 jemalloc 分配器，会出现同样的问题吗？”Jemalloc 是一个专为多线程环境优化的内存分配器，目标之一就是减少锁争用。我们曾在早期测试中尝试过 jemalloc，但当时未见显著性能收益。然而，随着 ClickHouse exporter 的负载提升，以及 Kafka 接收器架构的变化，内存分配压力大幅增加，这促使我们重新测试旧版和新版在 jemalloc 下的表现。

我们将旧版本切换为使用 jemalloc 后，CPU 使用率从 93% 降至 40%，与我们将反序列化迁移至共享线程池后的效果几乎一致，进一步印证了锁争用才是核心瓶颈。

尽管 jemalloc 能缓解 CPU 压力，但在满负载条件下，Kafka 消费延迟却有所增加。加上 jemalloc 当前已不再活跃维护，我们决定不将其设为默认分配器。不过，未来我们可能会引入 feature flag，让用户根据需求自由选择 jemalloc、mimalloc 等自定义内存分配器。

额外提升：开启快速 LZ4 压缩优化

Rotel 采用 ClickHouse 官方推荐的 LZ4 压缩配置来减少网络传输数据量。我们使用的是 lz4_flex crate —— 与 clickhouse-rs 相同的依赖库，但我们是直接引用的。在引入相关压缩支持时，我们忽略了 Cargo.toml 中的功能标志配置。

Lz4-flex 同时提供安全（safe）和非安全（unsafe）两种实现版本，其中 unsafe 版本的性能更优（关于 Rust 中的 unsafe，请参考官方文档（https://doc.rust-lang.org/book/ch20-01-unsafe-rust.html））。默认情况下，需要显式启用 unsafe 特性才能使用高性能实现。

clickhouse-rs 默认启用了 unsafe 模式，而我们最初未启用此选项。启用之后，我们观察到网关采集器的吞吐能力由每秒 360 万条 trace span 提升至 370 万条，网络压缩输入达到了 209 MB/s。

与此同时，网关采集器的 CPU 使用率也进一步小幅下降。

完整的端到端性能评估

在对 Rotel 进行了多轮性能优化，并基于 ClickHouse 的 Null 表引擎完成初步测试后，我们成功将单实例的吞吐能力从最初的每秒 110 万条 trace span 提升至 370 万条，相当于每核每秒处理 46.25 万条。这比最早测试 OTel Collector 所获得的吞吐性能提升了超过 4 倍。

我们随后将评估重点转向了整个链路的最后一环 —— 数据写入 ClickHouse 并真正持久化至磁盘。在扩展 ClickHouse 写入能力时，通常需要从写入性能与查询效率两个维度优化数据表结构。本次测试我们仍采用默认的 OTel 数据模式，因此主要通过选择具备足够写入能力的实例来支撑高负载。

为应对大规模写入负载，我们将 ClickHouse 部署在更高性能的 AWS 实例上，并通过 4 块本地存储构建 RAID0，以确保不会受到磁盘带宽瓶颈限制。

在测试期间，我们关闭了 Rotel 的异步写入功能，并将批处理规模大幅提升至 --batch-max-size=102400，以提升整体写入效率。通过设置 --clickhouse-exporter-async-inserts=false，我们成功维持了每秒 370 万条 trace span 的网关采集器吞吐量。

此时 ClickHouse 的 CPU 占用率约为 50%，压缩后的写入流量达到 210MB/s。

Visual inspection 

可视化效果上，我们在 ClickHouse 中成功查询到了超过 30 亿条追踪数据，验证了端到端链路的可用性。

总结

极限规模下，效率至关重要

ClickHouse 内部 LogHouse 平台所运行的 PB 级可观测性场景表明，效率不再是优化选项，而是生存必要条件。他们将管道吞吐能力提升了 20 倍，同时仅使用之前 10% 的资源。如果仍按原有路径扩展，运维成本将变得无法承受。Netflix 与 OpenAI 等大型技术公司也达成了类似共识 —— 当数据量达到如此规模时，效率的优劣将直接影响业务运转。

本项目的目标正是在这一背景下，推动 OpenTelemetry 数据采集效率提升，并推出 Rotel。

近 4 倍的吞吐性能提升

通过本次工作，我们将 Rotel 打造为一款高吞吐量的 OpenTelemetry 流式采集工具。在相同硬件环境下，Rotel 的处理能力几乎是 OpenTelemetry Collector 的 4 倍。这种差异在大规模场景下可以带来显著的资源节省。Rotel 原生支持 OpenTelemetry 的 trace、metric 和 log 类型。本篇文章聚焦追踪数据，未来我们还将扩展基准测试到日志与指标场景。

我们也希望了解，在海量数据处理场景下，用户最看重哪些功能特性。如果你有宝贵经验或希望分享你的扩展实践，欢迎加入我们的 Discord 社区（https://rotel.dev/discord），或在 GitHub 上（https://github.com/streamfold/rotel）提交贡献。

后续方向

以下是我们在完成本次测试后，计划进一步探索的几个方向：

深入探讨 Kafka 的可靠传输机制

本文仅简单提及了 Rotel 的消息可靠性设计。Rotel 支持端到端消息确认机制，确保从 Kafka 中读取数据时实现“至少一次（at-least-once）”语义，避免依赖 Kafka 默认的自动提交机制可能导致的数据丢失。为此我们对数据管道做了多处修改，并进行了严格测试，以确保在避免重复的同时不丢失任何数据。未来我们计划单独撰文，深入介绍其设计与验证方法。

评估 ClickHouse 原生通信协议

Rotel 当前通过 clickhouse-rs 实现与 ClickHouse 的集成，采用基于 HTTP 的 RowBinary 协议。相比之下，OTel Collector 使用 Go 实现的 ClickHouse 驱动，采用的是 ClickHouse 的原生协议。该协议也是 ClickHouse 节点之间通信所用方式，基准测试显示其性能比 RowBinary 高出约 20%。ClickHouse 还新增了对 Apache Arrow Flight 的支持，后者基于内存格式 Arrow 实现高效传输。我们计划评估是否可将 RowBinary 替换为这些列式协议，以进一步提升 Rotel 吞吐性能。

进一步分析 tokio 中的阻塞任务影响

类似反序列化这类阻塞操作对 tokio 的运行时性能影响显著。在本次评估中我们首次直观感受到其影响，因此希望在其他处理路径中继续探讨类似瓶颈。目前我们已知 Rotel 的 OTLP 接收器在处理连接时会在异步任务中直接执行较重的 Protobuf 反序列化操作，该处理逻辑由 tonic crate 承担。我们计划分析如何将其拆分为独立任务。初步通过 perf 工具观察，预计该处存在巨大优化潜力。

优化内存分配路径

虽然 Rust 本身没有垃圾回收机制，但高频率的内存分配与释放在高负载场景中依然会成为瓶颈。Rotel 在处理短生命周期对象时存在大量内存分配行为。如果我们采用内存重用池（freelist）的方式跳过分配器，将常用缓冲区复用，有望显著减少开销。当然，这类机制的实现难度较高，若不慎也可能导致内存占用飙升。我们可能需要深入修改 tonic crate 才能实现该优化。

我们特别感谢 Sujay Jayakar、Ben Sigelman、Rick Branson、Vlad Seliverstov、Rory Crispin 和 Achille Roussel 对本文早期版本的审阅与反馈。

附录

评估过程中考虑但未纳入的项目

在设计本次基准测试框架时，我们曾希望纳入更多支持 OpenTelemetry 的数据平面工具。但实际测试中发现，它们与我们所设定的测试流程并不兼容。我们之所以选择分布式追踪作为测试对象，是因为它是推动 OTel 被广泛采用的关键场景之一，且在大规模系统中数据增长迅速。然而，日志与指标则属于传统监控领域，很多工具对 trace 类型的遥测数据仍缺乏完善支持。因此虽然未在本次测试中覆盖这些工具，我们仍计划未来开展日志与指标方面的基准评估。

Vector

Vector 是一款专为构建高性能遥测数据管道设计的轻量级工具。它支持广泛的数据源和输出目标，能很好地融入多种系统中。该项目目前由 DataDog 主导开发，并被用于其 observability pipelines 产品。

不过，Vector 对 OpenTelemetry 的支持还处于早期阶段，目前尚无法与多种目标系统对接。尤其在 trace 数据方面，其内部数据模型起初并不支持追踪结构，因此目前对 OTel trace 的支持较为有限。由于 Kafka 和 ClickHouse 的输出插件对 trace 数据尚不兼容，我们未能将其纳入此次测试。

例如，我们曾尝试：

• 从 OpenTelemetry source 向 Kafka sink 发送 trace 数据（https://github.com/vectordotdev/vector/discussions/21018）；

• 在 ClickHouse 中存储 trace span（https://github.com/vectordotdev/vector/issues/17307#issuecomment-1641075239）。

Fluent Bit

Fluent Bit 是一个以性能为重点、由 C 编写的 Fluentd 替代方案。它提供了对 OpenTelemetry 的输入与输出支持，包括日志、指标与追踪数据。Fluent Bit 支持 Kafka 输入输出，因此理论上可用于构建可靠的数据流管道。

然而我们测试发现，当前版本中，在将 OpenTelemetry 作为输入的同时通过 Kafka 或 HTTP 输出 trace 与 metric 数据，尚不完全支持。这一限制使其暂时无法参与本次评估。

简化 OTel 与 ClickHouse 的迁移操作

根据 ClickHouse 官方文档建议，用户应在部署前手动创建表结构，而不是依赖导出器自动建表。但由于这些迁移脚本通常打包在 OTel exporter 中，缺乏独立部署方式，因此部署过程并不直观。

为了解决这个问题，我们在 Rotel 中将表结构管理逻辑拆分为一个独立的命令行工具 —— clickhouse-ddl，用于便捷地部署数据模式（schema）。该工具可创建与 Rotel 和 OTel Collector 完全兼容的表结构。

我们将该工具封装为一个 Docker 镜像，用户只需运行一条命令即可快速创建用于接收 OTel trace 数据的表。例如，下面是一个用于创建 trace span 表结构的命令示例：

docker run streamfold/rotel-clickhouse-ddl create \    --endpoint https:    

此外，也可以像我们在本篇文章中所做的那样，使用 Null 表引擎来创建 schema，以便进行基准测试：

docker run streamfold/rotel-clickhouse-ddl create \    --endpoint https:        

参考资料

• 基准测试框架: https://github.com/streamfold/rotel-clickhouse-benchmark  

• Rotel 项目主页: https://rotel.dev  

• OTel 负载生成器: https://github.com/streamfold/otel-loadgen

/END/

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出 &图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com。

“通过双方团队的紧密协作，不仅实现了现有软件在 TencentOS 上的稳定运行，还为后续的系统升级和扩展奠定了良好的基础，顺利推进了我们的融合创新转型工作。”

——华泰保险集团运维管理负责人 程迅

华泰保险集团股份有限公司（以下简称“华泰保险”）成立于 1996 年，是一家集财险、寿险、资产管理、基金管理于一体的综合性金融保险集团。近年来，华泰保险把云原生与 AI 战略转型作为企业数字化转型的重点战略方向，与腾讯云建立了深度战略技术合作。基于腾讯专有云 TCE 平台，华泰保险构筑了以 TencentOS 为统一底层，集容器服务、大数据平台、AI 能力与安全体系于一体的全栈云平台，实现了从基础设施到应用平台的全面云化升级。

背景：云内操作系统改造前因与后果‍

在华泰保险全集团多业务上云进程中，需完成存量 400 余套业务系统与 3000 余台虚拟机的迁移工作。底层平台涉及上千台操作系统实例，其中 90%以上基于 CentOS Linux 构建。随着 CentOS 7 于 2024 年停止服务，系统面临的安全漏洞风险成为华泰保险云化转型中的首要挑战。

在此背景下，如何实现从现有 CentOS 的安全平滑迁移，保障业务连续性与系统稳定性并有效控制迁移成本与潜在风险，成为本次转型的核心任务，主要存在以下三大技术与管理难点：

• 操作系统停服带来的安全威胁：CentOS 7 停止更新后，未修复的漏洞可能引发严重安全风险，对系统持续运维构成严峻挑战；

• 多厂商协同下的运维效率提升：华泰保险原有系统依赖多家供应商的软件支持，一旦出现故障，跨厂商协调过程复杂，严重影响问题定位与解决效率；

• 存量业务系统与国产化操作系统的适配复杂度：大量既有软件组件在迁移过程中需重新适配国产 OS 环境，技术兼容性与稳定性保障任务艰巨。

技术选型：TencentOS 的全栈价值

在平台选型服务器操作系统阶段，华泰保险团队通过多轮测试评估，最终选择 TencentOS 作为国产操作系统的核心替代方案，其技术价值主要体现在以下方面。

安全与稳定性保障——金融业务的生命线

1、全生命周期漏洞管理：操作系统漏洞可能会带来严重的安全风险，这一直是运维中的难题。通过腾讯云 TCE 平台主机安全能力与 TencentOS 深度集成，实现系统漏洞的全量扫描、修复与可视化管控，建立起覆盖全量的漏洞管理机制，及时发现并修复漏洞，保障了系统安全，显著降低运维复杂度。

2、金融级数据安全与合规：TencentOS 提供符合金融行业要求的安全加固机制，与现有安全运维体系有效协同，提升整体防护水平。

3、一站式服务体系：

• 问题快速响应：在日常运维中，腾讯云团队提供 7x24 小时的快速响应与高效闭环支持，与华泰保险形成了紧密协同，确保了系统平稳运行，减轻运维压力；

• 一站式服务：对于华泰保险来说，另一个难题是多厂商运维的沟通成本问题。华泰之前使用的软件来自多个厂商，一旦出现问题，沟通协调起来非常繁琐，效率很低。但采用 TencentOS 后，从 OS 到应用都是腾讯产品，提供了一站式服务，大大减少了多厂商之间的沟通成本，提高了运维效率。

华泰保险集团运维管理负责人 程迅

“采用 TencentOS 后，从 OS 到应用都是腾讯产品，提供了一站式服务，大大减少了多厂商之间的沟通成本，提高了运维效率。”

——华泰保险集团运维管理负责人 程迅

国产生态全栈兼容——从芯片到云

1、硬件层面：TencentOS 全面支持海光、鲲鹏、飞腾等主流国产 CPU，具备“一云多芯”架构能力。

2、软件生态：在软件生态方面，通过“OS+”生态模式，协同主流安全厂商完成业务系统与工具的深度适配，腾讯协助解决了多项业务系统与工具的适配难题。

迁移成果： 从 CentOS 到 TencentOS 实现平滑过渡与性能提升

通过全面采用 TencentOS 作为其全栈操作系统，华泰保险构建了安全、稳定、高效的 IT 基础设施体系，具体成果包括：

1、 核心迁移指标

• 实现操作系统层面零故障迁移；

• 漏洞修复及时率达到 100%；

• 系统整体性能提升约 10%；

• 系统稳定性达到 99.999%的金融级要求。

2、技术价值体现

• 标准化接口：有效降低了多安全产品与操作系统的集成复杂度，提升了系统整体稳定性与兼容性；

• 内核级扩展能力：可根据华泰保险的实际业务场景与各类安全产品特性进行灵活定制，支撑复杂业务需求；

• 多场景预兼容 ：通过与生态伙伴开展多场景预兼容测试与优化，TencentOS 保障了安全产品在各类业务环境中能够快速部署、稳定运行。

未来规划——面向云原生与 AI 场景的深度优化

未来， 华泰保险将继续以 TencentOS 作为全栈技术基座，重点在三个方向深化合作：

• 资源优化：依托 TencentOS 的 qGPU 虚拟化与调度能力，逐步推进算力资源的精细化管理与动态分配，在控制成本的同时为 AI 场景的规模化应用预留弹性扩展空间；

• 性能提升：基于 TDSQL 与 TencentOS 的全栈融合架构，持续优化提升系统整体吞吐与响应效率；

• AI 基础支撑：TencentOS 作为全栈体系的统一基座，将围绕智能客服、风控建模等业务场景，共同推进 AI 推理加速框架的落地与应用创新。

“我们选型时做了大量测试对比，TencentOS 在兼容性、稳定性和服务支持上都表现最好。当然，我们在选择之前也做过大量的调研和验证，TencentOS 凭借其强大的生态兼容性以及卓越的技术服务能力，满足中粮信托的选型标准，成为最终选择。”

——中粮信托基础设施运维经理 南昕

中粮信托有限责任公司（简称“中粮信托”）成立于 2009 年 7 月，是经原中国银监会批准设立的非银行金融机构，公司聚焦农业金融和乡村振兴领域，通过不断创新金融模式，逐步发展为行业内先进企业。

 

数字化中心作为中粮信托唯一的科技职能部门，近些年围绕业务“3+1+3”的发展战略，制定了数字化的发展战略，中粮信托围绕国产化进程的改造做了很多战略上的部署和调整，操作系统是其中一个重要的方面。

国产化操作系统改造中的业务需求与挑战

在信托行业，科技从业人员数量远远低于银行的体量，在操作系统国产化替代过程中要求尽可能选择能够提升整体迁移效率以及辅助迁移的方案或服务，对自动化迁移的能力、备份、回滚、全流程自动化、降低迁移成本等方面有着极高的要求。对于后期的安全与运维需求，同样要兼容现有公司内部安全运维基线，能够满足信息安全需求，实现运维系统、监控系统的统一管理，技术选型关键技术清单要求如下：

1. 7×24 小时业务不间断

CentOS 于 2024 年 6 月全面停服，意味着系统的安全漏洞无法修复，技术中断后核心的交易平台和系统也会面临一些病毒的攻击和数据泄露的巨大风险。金融行业大部分系统都是交易类的系统，对业务连续性有比较高的要求，中粮信托内部的普惠金融系统、财富系统等，都要求业务连续 7×24 小时不间断。

2. 兼容性要求较高

进行操作系统的替换，中粮信托主要面临着技术适配、迁移窗口的难题。要考虑迁移效率和业务影响的平衡，内部整体架构的兼容性。操作系统作为 IT 的底座，要兼容底层基础设施硬件、数据库、中间件以及业务系统，对整体兼容性也提出了比较高的要求。技术方案选型的核心逻辑是要保证业务零中断、风险可回滚、成本可控。

3. 重装系统 or 原地替换？

结合市面上主流的迁移方案，主要两种：一是重新安装国产操作系统来部署业务；二是采用腾讯 TencentOS 原地替换方案。相比之下原地替换方案更具优势，不需要重新部署，迁移周期比较短，能够有效的降低内部的人工成本，保留业务的配置和数据，整体风险也比较可控。

国产操作系统选型与业务价值

在进行 TencentOS 替换之前中粮信托做了一些内部基础设施的创新和突破。在 2024 年整体进行基础设施国产化软硬件的升级，建立了业内作为信通行业建立双活数据中心的信托公司，通过自主网关设计实现微服务架构的双活。

在基础设施升级后，TencentOS 作为上面的重要分支来打造现有企业云国产化架构解决方案。TencentOS 成为中粮信托的最终选择，主要原因是迁移的整体效率及专业的专家服务。

1. 从 POC 到全面上线：百日攻坚实现 300 套系统无缝迁移

• 2024 年 8 月份开始整体方案准备；

• 9 月份 POC 测试；

• 10 月份环境部署到迁移周期评估；

• 11 月份着重对测试环境进行迁移，来验证和演练；

• 到年底之前完成了生产系统包括存量 300 多套系统 TencentOS 的整体迁移。

2. 专业护航，平稳落地：7×24 小时专家支持与周密预案保障迁移“零感知” 

腾讯云与中粮信托团队进行了多轮投产预演，进行及时的问题复盘。业务层面，TencentOS 专家团队具备大规模迁移经验，能够提供 7×24 小时的技术支持，在迁移期间积极配合中粮信托团队提前联系用户，错开投产和变更的时间，上线后进行了重新的验证和压测，来保证整个操作系统的迁移稳步进行。

中粮信托基础设施运维经理 南昕

“腾讯的团队人员很专业，包括前期方案的制定，实施过程中表现出的专业性，因为操作系统迁移大多可迁移窗口都是晚上或者凌晨，我们腾讯的小伙伴们也是在实施过程中表现处理非常敬业的态度，让我们完成了整个工作安排。”

——中粮信托基础设施运维经理 南昕

未来展望

国产化替换不是终点，可能是数字化金融创新以及数字化转型的新起点。未来，中粮信托将持续在数字化转型的历程上不断稳步前行，和腾讯生态伙伴们一起携手并进，打造国产化改造以及数字化创新的未来。