夜天之书

本文对应我在今年 RustChinaConf 2025 & Rust Global China 大会上的演讲，原标题《最速传说：四个月内基于 Rust 开发服务全球云数据库 ScopeDB》。由于近期我写的另一篇文章也使用了“最速传说”的字样，出于个人写作习惯，我把标题做了改动。

云原生技术方兴未艾已十余年，但是，云上的数据方案大多还只是将基于裸金属集群构建的系统几乎原样的搬到了云上，没能充分利用云上弹性调度的能力，以及云厂商提供的廉价对象存储。

我在开发者的未来：基于云服务构建数据基础设施一文中已经说明为何简单照搬原有架构行不通。

ScopeDB 的出现，既是为了压榨出云资源的所有优势，也是为了压缩大数据时代叠床架屋的数据流水线方案，将分析的能力带给每一个业务团队。

Rust 已经成为新时代基础软件开发的首选。基于可靠的 Rust 语言和繁荣的 Rust 生态，我们在四个月内从无到有开发出了云数据库 ScopeDB 并在全球多个可用区内上线服务客户需求。

在此过程中，我们也将自己对 Rust 生态的需求和改进持续反馈到上游项目社群，并将研发过程中衍生的独立模块以开源库的方式共享出来。

Apache 软件基金会官方已发布新闻稿，宣布 The ASF 的新徽标 “橡树叶”正式启用。本文按照我对新闻稿的理解进行翻译，非逐字翻译。

去年，Apache® 软件基金会（The ASF）宣布，为了更好地体现基金会“社群重于代码”的一贯理念，我们将更新组织徽标（Logo）和品牌体系。今天，我们荣幸地宣布推出全新的 ASF 徽标：橡树叶（Oak Leaf）。

关于 2024 年的相关公告，请参见：

• Evolving the ASF Brand
• Update on ASF’s brand evolution

Rust 标准库的 sync 模块提供了一系列并发原语，包括对应原子操作的 atomic 系列，实现 channel 通信的 mpsc 和 mpmc 等，以及对应互斥锁的 Mutex、RwLock 和 Condvar 等。

不过，这些原语都是对应同步编程模型，基于线程阻塞来实现的。如果在 Future 和 async/await 上下文当中使用，可能会因为阻塞运行时调度而成为 Async Rust 的性能瓶颈。甚至 Rust 官方定义了一条 Lints 规则，提示开发者不要跨越 await point 持有同步原语中的互斥锁资源。

换句话说，为了在 Async Rust 上下文中实现各种并发原语，我们必须在标准库 sync 模块以外另做实现。本文从 ScopeDB 开发过程中对并发原语的需求出发，介绍我们为此开发并开源的，运行时无关的异步并发原语库 Mea (Make Easy Rust)。

今天起来就看到 EMQX 将于明年初正式结束开源版产品生命周期。通常我是不评论时事的，不过最近关于产品是否应该开源的议题逐渐触达了国内先做开源产品再考虑商业化的公司，或许是一个整理过往的观点，集中提供相关思考方式的契机。

Confluent 是一家著名的 Apache Kafka 提供商，其创始人在 LinkedIn 工作期间创造了 Kafka 项目，并将其贡献给了 Apache 基金会。这一模式后来也在 Apache 软件基金会（ASF）内被多次复制，即依托于 Apache 顶级项目打造商业产品，对应的商业公司核心成员是该开源项目的维护者或原始作者。

在《应当尊重和保护开源项目的知识产权》一文中，我介绍了 ASF 的商标品牌政策。在 Confluent 创办到发展至今的十余年里，ASF 品牌管理部门就 Confluent 使用 Apache Kafka 等项目的商标品牌的问题和 Confluent 打过多次交道。后来，Confluent 总结出了一份 Apache 品牌指导手册，用于员工培训以避免因为缺乏相关知识导致的侵权行为。

原先，这个指导手册挂在 https://www.confluent.io/apache-guidelines/ 地址上。不过，就在上个月我想引用这个页面，向国内某些厂商说明，可以如何制定员工手册，指导处理 Apache 品牌的时候，我意外地发现这个页面已经无法访问了。

不过，感谢互联网记忆令使 Wayback Machine 的记录，我们还能看到两年前的快照版本。为了介绍这样一个比较彻底的，公司层面可以培训员工遵守 ASF 品牌政策的方式，我写作本文全文引用 Confluent 的 Apache 品牌指导手册（自翻译版）并做锐评。

2019 年，当时的 Baidu Security X-Lab 团队将自己研发的安全计算框架 MesaTEE 捐赠到 Apache 孵化器，并更名为 Apache Teaclave 开始孵化。

时过境迁，当时的 X-Lab 早已不复存在，其孵化提案中引用的 MesaTEE 网站也被其他实体申请占用。甚至，初始成员大多已经离开百度公司，前往新的团队开发新的安全软件。

很长一段时间里，Teaclave 都是所谓“源自中国”的 Apache 孵化项目当中孵化时间最长的项目：

不过，六年过去后的 2025 年，也就是今年，Teaclave 突然复苏。从三月开始时隔两年再次提名新的 Committer 到七月开始筹备毕业，就在一个月后，本周的 Apache 董事会议上，Teaclave 就完成所有流程正式成为 Apache 顶级项目。

本文从这样一个不太常见的开源项目演化历程出发，谈一谈开源生态里的“长期主义”以及如何在开源社群中取得进展。

日志是应用可观测的重要组成部分。可以说，任何运行在生产环境的应用，可能还没建立起指标（Metrics）体系，也或许还没上一套完整的追踪（Traces）方案，但是一定会打日志，至少是关键生命周期日志和错误日志。否则，一旦应用出现问题，几乎无从着手排查。

早在 2014 年底，Rust 生态就出现了官方的 log 库。这个库主要提供了打日志的宏指令定义，日志结构体的实现，以及打日志的 trait 接口。不过，它并没有提供实际日志如何打印的实现，而是将具体的日志输出方案留待社群扩展。应该说，log 库的定位跟 Java 生态里的 SLF4J 是一样的。

我猜测在 Rust lib teams 的设想当中，Rust 开源生态里应该很快会出现像 Java 生态当中的 Log4j 或 Logback 一样的日志实现，补充这部分空白，从而为所有 Rust 开发者提供一个完整的日志解决方案。

可惜，整整十年过去，Rust 生态虽然有像 env_logger 这样方便快速上手的 log 生态的日志实现，但是却迟迟没有一个能够满足生产环境下复杂配置需求和扩展需求的实现。

可以看到，上图中属于可扩展日志框架的实现，只有包括 Logforth 在内的四个。其中 spdlog-rs 甚至是在 Logforth 之后才收录到这个名单的。也就是说，在 Logforth 之前，Rust 生态只有 fern 和 log4rs 两个选择，而这两个选择又各自有明显的问题以至于很难再生产环境中大范围使用。具体问题在后续章节我会介绍。

于是，Rust 生态的日志方案发生了 slog 和 tracing 两次歧出。其中 slog 已经不再迭代，甚至 README 里就推荐用户转向 tracing 库。而 tracing 的种种问题，在上一篇文章里我们已经充分看到了。

Logforth 的出现弥补了 log 生态中可靠、可扩展日志实现的空白。本文从介绍 Logforth 的核心 API 和使用方式出发，分享 Logforth 的设计理念，以及开发并开源 Logforth 背后的故事。最后，讨论 Logforth 未来需要做的工作，以及相关的开源逸闻。

随着应用程序从单体走向分布式微服务架构，追踪（Trace）请求在各个模块间的流转变得越来越重要。然而，现有应用系统还没充分认识到分布式追踪的价值和必要性。这很大程度上是因为生态当中缺乏一个可靠、高效且易用的分布式追踪方案。

Rust 生态尤其如此。作为一个新兴的语言生态，可供 Rust 开发者选择的追踪框架并不多。目前常用的 tokio-rs/tracing 库存在明显的生态割裂、配置负载和运行低效的问题。在研发 ScopeDB 的过程中，我们深刻认识到分布式追踪对系统可观测性及问题排查的重要性。为了解决 Tracing 存在的问题，我们基于现有开源软件分叉开发维护了 Fastrace 框架。

Fastrace 经过生产环境的高压检验，可为用户提供一致且简单的 API 体验，并能与现有的 Rust 生态无缝集成，尤其是提供了高效丝滑的 OpenTelemetry 集成体验。以下是使用 Fastrace 追踪请求的简单示例：

1
2
3
4

#[fastrace::trace]
pub fn send_request(req: HttpRequest) -> Result<(), Error> {
    // business code
}

ScopeDB 线上环境中一个分布式追踪的可视化实例：

本文先介绍分布式追踪及其价值，然后讨论 Fastrace 如何解决此前 Rust Tracing 方案中没能解决好的问题，并给出一个完整的日志追踪方案。最后，分享 Fastrace 开源背后的故事。

上周，我在视频号（啸飞吟声）上做了一期连线直播，讨论包含企业开源软件变更协议在内的商业开源相关问题。其中，有一个重要的内容，就是作为开源软件的使用者，面对上游开源软件无法持续维护，或者企业开源的软件修改协议等潜在风险时，如何保障自己的使用安全。

在此前的一篇博文《开源软件有断供的风险吗？》当中，我已经说明了开源协议不可撤销地授予接收者使用、复制、修改和分发软件的权利，以及作为开源软件的使用者，如何判断开源依赖需要自己付出哪些投入。不过，这篇文章主要是讨论抽象的依赖分类，以及开源协议在源码授权上的不可撤销性。最近 KubeSphere 删除软件文档、已发布镜像等行为，实际上受影响的主要是开源制品，即基于开源软件源代码构建的二进制软件包等等。

本文讨论开源软件使用者如何可靠地依赖开源制品。

在年初的一篇关于商业开源的博文当中，我介绍了在开发商业软件的过程中，衍生出开源公共软件库的模式。在那篇博文里面，我只是简单罗列了相关开源库的名字及一句话总结。近期，我会结合商业开源实践的最新进展，对其中一些案例做详细展开。

首先介绍的是 Cronexpr，一个小巧的 Rust Crontab 解析库。其背后的开源模式，我称之为“涓滴开源”，即将商业软件依赖的微小但完整的功能模块开源出来，供其他人使用。