TPF把部署玩成乐高：同一套代码，3种形态随意切

一个支付流水处理系统，上周还在单机上跑得好好的，这周突然要拆成微服务应对大促。你的选择通常是：重写，或者硬扛。The Pipeline Framework（TPF）的团队说，这事本可以像换手机壳一样简单——同一套业务逻辑，编译时选个参数，运行时形态就变了。

这不是魔法，是把"业务流"和"怎么跑"彻底解耦的结果。TPF的runtime topology（运行时拓扑）机制，让一套pipeline代码能在三种形态间切换，无需重写业务逻辑。

形态一：单体模式，所有东西挤在一个进程里

步骤之间直接调用，插件（持久化、缓存）也内嵌其中。没有网络跳点，调试时断点一打到底，运维只需要关心一个进程活没活。

代价是共享爆炸半径：一个步骤内存泄漏，全站陪葬。

这是TPF的默认形态，也是开发阶段的舒适区。团队内部叫它"humble monolith"—— humble（谦逊）是因为知道自己随时可以被换掉，不像某些"majestic monolith"（宏伟单体）那样，拆不动也不敢动。

形态二：分组模式，把 orchestrator（编排器）拎出去

步骤仍跑在一起，但统一受外部编排器调度。插件变成共享服务，不再是每个步骤自带一份。

这个形态像给公寓楼装了个门禁：外人只能敲大门，不能直接去敲每户的门。你获得了清晰的入口点，内部组件暴露面减少，又不用承受完全分布式的心理负担。

大多数生产环境会停在这里——足够好，足够省。

TPF的PipelineRuntimeMapping组件负责这一步的"选址"。编译时，框架根据配置把步骤的输入输出适配成对应的调用方式：本地方法调用、HTTP、或者gRPC。业务代码感知不到这些变化。

形态三：完全拆分，每个步骤独立部署

步骤变成可独立发布的单元，各自按需扩缩容。团队边界、故障域、资源配额，全部物理隔离。

这是微服务教科书里的理想状态，也是运维人员的加班源泉。更多网络跳点，更多分布式事务的坑，更多凌晨两点的告警。

TPF不替你填这些坑，但它保证：填坑的时候，业务逻辑不用动。

在csv-payments示例中，同一套支付处理pipeline，开发环境跑单体，预发环境切分组模式，生产大促时拆成微服务——三行配置的事。Step contracts（步骤契约）定义了"做什么"，mappers（映射器）处理了"怎么传"，transport层的东西被挡在核心逻辑外面。

这种设计有个副作用：团队终于能诚实面对自己的选择了。

以前选微服务，往往是因为"架构先进性"或者"简历驱动"。现在TPF把切换成本降到编译期，选单体还是微服务，变成纯粹的权衡题——当前阶段，哪种形态的成本收益比更优？

框架作者用《永恒者》里的场景打比方：EMP（电磁脉冲）过后，Favalli发动一辆老爷车。那辆车没有ECU、没有总线，就是纯粹的机械连接——这是humble monolith的生存优势。但故事背景是末日，不是常态。TPF想说的是：你的系统应该既能当老爷车，也能随时加装电控单元，而不必重新铸造发动机。

runtime topology的野心不止于三种形态。框架的代码生成层基于统一的语义模型，理论上可以投影到更多执行模式：本地调用、gRPC、REST、protobuf-over-消息队列……传输协议是变量，业务语义是常量。

这解决了微服务迁移中最隐蔽的痛：不是技术债，是决策债。很多系统卡在"拆不动"的状态，不是因为代码耦合，而是因为早期选了一个形态，后期换形态的代价被低估。TPF把代价显性化、可逆化，让架构演进变成持续决策，而非一次性豪赌。

当然，前提是你愿意接受TPF的编程模型：pipeline即代码，步骤纯函数化，副作用推到插件层。这不是所有业务都能套进去的模子。但对于已经接受响应式流、函数式管道的团队，runtime topology可能是那个"早知道就好了"的功能。

TPF团队目前只公开了三种形态的实现，gRPC和REST的适配器还在实验分支。有用户在GitHub issue里问：那Serverless呢？框架作者的回复很克制：「语义模型支持，但我们需要更多生产验证。」

你的系统上一次调整部署形态，花了多久？如果答案是"以季度计"，TPF想聊的事，可能正是你正在回避的事。