---
title: Rust 与 Web 后端的适用边界
date: '2019-12-09 15:11:16'
draft: false
summary: Rust 能解决很多长期运行服务中的内存与并发问题，但多数 Web 后端的主要复杂度其实早已被数据库、缓存和外部状态托管掉了。
slug: rust-is-not-ideal-for-most-web-backends
syndication:
- platform: Weibo
  url: https://weibo.com/1648815335/IjYsCedJh
tags:
- rust
- web
- backend
- programming-language
topics:
- software-engineering
type: post
---

前一段时间 `Westar` 的 `Rust meetup` 里，有个议题专门介绍当前 `Rust` 的各种 Web 框架。看下来我的感觉还是一样：`Rust` 当然很强，但它并不是大多数 Web 开发场景里的最优先语言，除非你的主要目标是技术栈统一，或者只是给一个非 Web 项目顺手暴露一个 `HTTP` 接口。

有人会问，既然 Rust 的目标是解决并发安全的问题，并且 Web 也属于高并发要求的应用，那为什么 Rust 在这个领域没发挥出来呢？实际上 Web 的并发安全难题主要是通过状态的外部存储来解决的。大多数 Web 程序本身都是无状态的，接收请求后，通过缓存或者数据库读写数据，然后返回出去，至于状态会不会冲突，这个由数据库来解决。如果需要维护状态，也仅仅是连接池之类的，或者很少的一些静态变量。再或者像 PHP 这样的，连接池都不需要，可以理解成整个应用的生命周期都和 request 一致，执行完成后销毁掉资源，也不存在内存泄露啥的。但在 Rust 里，这些生命周期的问题需要在编译阶段解决，新手写 Rust Web，Hello world 几分钟就搞定了，觉得很简单，但让输出个全局计数器，就蒙了。

有人还会问，那 Web 服务如果长期运行，用 `Rust` 能不能一定程度避免内存泄露？这个当然有帮助。

但现实问题是，一个互联网服务如果不能频繁上线、快速重启，它往往也称不上真正的持续交付系统。很多疑难的内存问题，甚至还没来得及暴露，就已经被日常重启策略顺手消掉了。有些团队干脆还会安排夜深人静的时候自动重启服务，避免周末没人值守时出问题。

所以我对这个问题的判断一直是：`Rust` 在 Web 领域不是没有价值，而是它最核心的价值，恰好不一定落在大多数 Web 团队当前最痛的点上。

<!-- WEIBO_MEDIA_START -->
## 原微博中的媒体

![](./weibo-4447606463389371-1.jpg)
<!-- WEIBO_MEDIA_END -->