异步编程

背景与问题界定 在微服务网关项目的开发迭代中，我们发现随着连接数和任务粒度的增长，异步运行时的调度行为开始显著影响尾延迟和CPU利用率。项目最初基于tokio构建，但在某些极致轻量场景（如嵌入式控制面、边缘节点代理）中，tokio的功能冗余和线程模型开销引发了"杀鸡用牛刀"的质疑。与此同时，基于async-executor + blocking的smol生态在社区中崭露头角。我们需要在一个混合架构中——既有高吞吐IO密集型任务，也有低延迟控制面任务——做出运行时的选型决策，避免技术栈分裂带来的维护成本。 目标拆解与工程约束 调度模型差异：tokio采用多线程work-stealing调度器（默认线程数=CPU核数），smol则基于单线程+任务窃取（thread-per-core可配置）。调度模型直接影响CPU亲和性与上下文切换开销，需要在多租户环境下验证。 功能覆盖面：tokio提供完整的IO、计时器、同步原语、进程管理等生态组件；smol追求最小核心，IO等能力由相关Crate（async-io、blocking、async-channel等）组合提供。生产环境需要稳定、文档齐全的生态支持。 运行时开销：tokio的trace、dumps、spawn阻塞检测等诊断功能带来了约5-15%的性能常驻开销；smol在这些方面几乎为零开销抽象。需要量化评估在性能敏感场景中的实际差异。 团队熟悉度：多数团队成员长期使用tokio，对smol生态的调试工具（如async-backtrace不原生支持）不熟悉。选型必须考虑学习成本和生产排障效率的平衡。 方案设计 首先需要明确：tokio与smol并非"非此即彼"的对立关系，而是在不同抽象层级上解决问题的运行时。tokio是一个完整的异步IO运行时，其核心价值在于"开箱即可用"——当你需要Timer、TCP流、信号处理、进程管理等全套基础设施时，tokio可以一站式解决。smol则更像一个"运行时内核"，提供最精简的任务调度原语，上层能力通过组合轻量Crate来构建。 对于微服务网关场景，我们提出了分层运行时架构：核心IO处理层使用tokio，利用其成熟的TcpStream、tokio-util管道和Backpressure原语保障吞吐稳定；控制面（配置推送、健康检查、路由规则更新）则切换到smol的轻量运行时，因为这些任务的特点是频率低、延迟敏感、不允许被IO阻塞干扰。分层的关键在于通过channel边界完成运行时桥接——tokio::spawn的任务通过async-channel将结果投递到smol的Executor中，反之亦然。这种模式要求我们严格定义"桥接点"的生命周期边界。 工程落地时，还需要考虑两类运行时之间的"线程配对"：tokio的多线程worker与smol的单线程executor之间若共享同一个堆分配器，可能会引发内存分配竞争。因此我们为两个运行时各自配置了独立的mimalloc arena实例，将分配隔离与运行时隔离绑定。 实施路径与关键决策 第一阶段（评估期）：在本地benchmark中，分别用tokio single-thread Runtime与smol运行同一组微基准（echo server、batch compute、timer storm），记录P50/P99延迟和CPU利用率曲线。关键发现：在纯CPU密集型场景下两者差异在3%以内；在大量短连接场景（<50ms生命周期）中smol因无全局调度器而展现更低的P99抖动。 第二阶段（分层网关POC）：实现基于tokio的IO层（4 worker线程）和基于smol的控制面（1固定线程），通过mpsc channel通信。引入tokio-console监控IO线程行为，使用perf观测smol线程的缓存命中率。 第三阶段（桥接方案定稿）：决定使用crossbeam-channel而非tokio::sync::mpsc作为跨运行时channel，以避免tokio内部的协作式调度机制对smol侧的侵入。 验证指标与可持续迭代 在灰度发布环境中，我们关注三个核心指标：P99链路延迟（目标<5ms波动）、控制面任务响应时间（目标<1ms）、以及CPU亲和性保持率（控制面线程不得漂移到IO worker core）。通过eBPF和tokio-console双轨监控，我们持续观测桥接channel的背压水位，当水位超过阈值时自动扩缩smol侧的worker线程数。 工程落地思考 这次运行时选型最大的收获是意识到"异步运行时"不仅仅是调度器，更是一套包含生命周期管理、错误传播、取消安全等语义的编程模型容器。tokio和smol分别代表了"厚重保障"与"极简可控"两种设计哲学，在工程实践中不必二选一，而应通过清晰的架构边界各取其长。最终的分层方案让IO吞吐与控制面延迟都达到了预期，同时也验证了Rust类型系统在跨运行时安全边界上的保障能力——编译器帮我们捕获了几乎所有桥接点上的Send/Sync误用。

背景 现代编程离不开异步。Python 有 asyncio，JavaScript 有 async/await，Go 有 goroutine。C++20 终于引入了协程（Coroutines）。 今天从 Python asyncio 的视角来看看 C++ 协程怎么用。 Python asyncio 的模式 async def fetch(url: str) -> str: # 模拟异步IO await asyncio.sleep(1) return f"data from {url}" async def main(): results = await asyncio.gather( fetch("a.com"), fetch("b.com"), fetch("c.com"), ) print(results) asyncio.run(main()) 核心概念：async def 定义协程函数，await 挂起等待，asyncio.gather 并发执行。 C++20 协程入门 C++ 协程的关键类型： co_await — 挂起协程 co_return — 返回值（相当于 return） co_yield — 产出值（用于生成器） std::suspend_never / std::suspend_always — 挂起策略 简单例子：模拟异步任务 #include <coroutine> #include <future> #include <iostream> template<typename T> struct Task { struct promise_type { T value; std::exception_ptr error; auto get_return_object() { return Task{std::coroutine_handle<promise_type>::from_promise(*this)}; } auto initial_suspend() { return std::suspend_never{}; } auto final_suspend() noexcept { return std::suspend_always{}; } void return_value(T v) { value = v; } void unhandled_exception() { error = std::current_exception(); } }; std::coroutine_handle<promise_type> handle; Task(std::coroutine_handle<promise_type> h) : handle(h) {} ~Task() { if (handle) handle.destroy(); } T get() { handle.resume(); return handle.promise().value; } }; // 模拟异步操作 Task<int> async_fetch() { std::cout << "开始异步任务...\n"; co_await std::suspend_always{}; // 挂起，模拟异步等待 std::cout << "异步任务完成\n"; co_return 42; } int main() { auto task = async_fetch(); std::cout << "做一些其他事情...\n"; int result = task.get(); std::cout << "结果: " << result << "\n"; } 和 Python asyncio 对比 Python C++ async def Task<T> 返回类型 await co_await return value co_return value asyncio.sleep(1) std::suspend_always{} 事件循环自动调度 手动 resume() 实际应用：HTTP 客户端 Task<Response> http_get(const std::string& url) { co_await socket_.async_connect(url); co_await socket_.async_write(request_); Response resp = co_await socket_.async_read(); co_return resp; } Task<std::vector<Response>> fetch_all(const std::vector<std::string>& urls) { std::vector<Task<Response>> tasks; for (const auto& url : urls) { tasks.push_back(http_get(url)); } std::vector<Response> results; for (auto& task : tasks) { results.push_back(task.get()); } co_return results; } 坑点 协程不能用在模板参数里 — std::vector<Task<int>> 可以，但 Task<Task<int>> 不行 生命周期管理 — 协程句柄必须手动 destroy()，除非用 RAII 封装 调试困难 — 栈帧被编译器切分，gdb 支持还在完善中 总结 C++20 协程还很年轻，库支持不如 Python 完善。但对于构建高性能网络服务，它的零成本抽象是其他语言难以比拟的。 ...