夜天之书

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 解析库。其背后的开源模式，我称之为“涓滴开源”，即将商业软件依赖的微小但完整的功能模块开源出来，供其他人使用。

自去年八月以来，我一直在 Apache 软件基金会（ASF）担任品牌管理委员会成员。近期，上海开源信息技术协会组织的首次“上海开源创新菁英奖”，评奖结果包括了若干 ASF 旗下的开源项目。然而，结果公布文章在引用这些项目时，存在部分对 ASF 品牌的误用。经由一位 ASF 中国成员报告，ASF 品牌管理委员会处理，以及与上海开源信息技术协会沟通后，今天发布了《关于 Apache 软件基金会有关项目的获奖信息更正》的公告，澄清了相关误用。

我由此想到，在过去很长一段时间内，由于 ASF 开源项目潜在的商业价值，许多公司基于 ASF 开源项目构建自己的商业产品或服务。在各个场合的宣传当中，这些公司不时有意或无意地违反 ASF 的品牌使用政策，主要表现是错误地将 ASF 品牌与其商业产品或服务关联起来。这种行为不仅误导了公众对 ASF 品牌的理解，也可能侵犯了 ASF 的知识产权。

激励创新，服务和推动高质量发展需要保护知识产权。本文结合我一年以来的经验，简单介绍开源项目的知识产权，ASF 的商标品牌政策，以及常见的侵权行为。

下周五到周日，也就是 7 月 25 日到 27 日，一年一度的 Apache 社群峰会（CommunityOverCode Asia 2025）将在北京海淀举行。

峰会的最后一天，我和 Rust 社群的伙伴们组织了 Rust 分论坛，讨论开源生态以及 Apache 项目中 Rust 的发展和应用。同样在 27 日的早晨，我会做一个题为《七年之痒：我的 Apache 故事》的主题演讲，介绍 Apache 软件基金会如何深刻地影响了我的开源之路，以及每一位工程师如何从 Apache 社群中受益。

关注峰会的朋友可能会发现，今年峰会在企业赞助商之外，还开辟了个人赞助的通道，而我就是第一位个人钻石赞助者。