Incremental Adoption Strategy
渐进式引入策略
What you’ll learn: How a Java organization can introduce Rust gradually, which workloads make the best first candidates, and how to sequence skills, tooling, and production rollout.
本章将学习： Java 团队如何渐进式地把 Rust 引入组织，哪些负载最适合作为第一批目标，以及能力、工具链、生产发布该怎样排顺序。Difficulty: 🟡 Intermediate
难度： 🟡 中级
The wrong slogan is “rewrite the monolith in Rust.”
最容易把事情带偏的口号，就是“用 Rust 重写整个单体系统”。
The healthy path is staged adoption:
更健康的路径是分阶段引入：
- learn on contained workloads
先在边界清晰的小工作负载上学习。 - deploy one focused service or worker
再上线一个聚焦的服务或 worker。 - expand only after tooling and operations are stable
等工具链和运维流程稳定之后再扩大范围。
Good First Targets
适合作为第一批目标的工作负载
| Candidate 候选目标 | Why it works well 为什么合适 |
|---|---|
| CLI or scheduled batch job CLI 或定时批处理任务 | easy deployment and rollback 部署、回滚都简单 |
| CPU-heavy worker CPU 密集型 worker | Rust often wins on latency and memory Rust 在延迟和内存上往往更有优势 |
| narrow microservice 边界清晰的小型微服务 | HTTP or Kafka contract is easy to freeze HTTP 或 Kafka 契约容易冻结 |
| gateway or adapter 网关或协议适配器 | explicit I/O fits Rust well 显式 I/O 非常适合 Rust |
Bad first targets usually look like this:
不适合作为第一枪的目标通常长这样：
- a huge Spring Boot monolith
一个巨大无比的 Spring Boot 单体。 - modules full of reflection and proxy magic
充满反射和代理魔法的模块。 - components with weak tests and many owners
测试薄弱且多人共同维护的组件。
Three Common Integration Styles
三种常见接入方式
1. Separate Service or Sidecar
独立服务或 Sidecar
Spring Boot keeps calling over HTTP or gRPC, while Rust owns one focused workload.
Spring Boot 继续通过 HTTP 或 gRPC 调用，Rust 则接管一个聚焦的工作负载。
This is usually the best first production move.
这通常是最适合作为第一步生产接入的方式。
2. Queue Worker
队列消费型 Worker
If the organization already uses Kafka or RabbitMQ, a Rust consumer is often even easier than a public HTTP service.
如果组织已经用了 Kafka 或 RabbitMQ，那么 Rust 消费者往往比新开一个公共 HTTP 服务还更容易上手。
3. JNI or Native Embedding
JNI 或原生嵌入
Useful in some cases, but rarely the first step.
某些场景里当然有用，但几乎不该作为第一步。
Packaging, debugging, and ownership boundaries all become harder.
打包、调试、所有权边界，都会一下子变得更难。
A 90-Day Plan
一个 90 天引入计划
Days 1-30: Foundation
第 1 到 30 天：打基础
- ownership, borrowing,
Result, andOption
把所有权、借用、Result、Option先学扎实。 - standardize
cargo fmt,clippy, and tests
把cargo fmt、clippy、测试命令统一下来。 - write small internal exercises
写几组内部小练习。
Days 31-60: One Real Service
第 31 到 60 天：做一个真实服务
- choose one bounded workload
挑一个边界清晰的工作负载。 - add config, logs, health checks, metrics
把配置、日志、健康检查、指标都补齐。 - make sure the team can operate it
重点不是能跑，而是团队真能运维它。
Days 61-90: Expand Carefully
第 61 到 90 天：谨慎扩大
- define review checklists
定义代码审查清单。 - define crate layout conventions
定义 crate 布局规范。 - define error-handling conventions
定义错误处理规范。
That is when Rust stops being an experiment and starts becoming an engineering capability.
走到这里，Rust 才算从实验品变成了组织真正掌握的工程能力。
Operational Readiness
运维就绪清单
Before expanding Rust usage, the first service should already have:
在继续扩展 Rust 之前，第一批服务最好已经具备下面这些能力：
- tracing or structured logging
追踪或结构化日志。 - health and readiness endpoints
健康检查和就绪探针。 - metrics export
指标导出。 - reproducible builds
可复现构建。 - integration tests against the real boundary
对真实边界的集成测试。
If these are missing, the organization is learning syntax but not learning production engineering.
如果这些都没有，那组织学到的只是语法，不是生产工程能力。