从340个Lambda到"云函子"：一个老极客的架构复仇记

你有没有算过，一个工程师真正写代码的时间占比多少？

三年前，Tommy McClung加入Informed时，这个数字是20%。剩下80%？在AWS控制台里手动接线——像给340个Lambda函数织毛衣。

更荒诞的是，这家公司处理着全美8%的汽车贷款，技术栈却是个"随机漫步"的产物：巨型Ruby on Rails单体应用，通过Elastic Beanstalk调用几乎所有AWS服务，Postgres数据库兼职当消息总线。

Tommy不是新手。从1993年创办ISDN ISP，到2008年成为AWS早期用户，他自嘲是"计算领域的阿甘"——啥热闹都赶过。但面对这个局面，连他也觉得传统工具像是"用脆弱的骨头造高性能引擎"。

CloudFormation？一堆令人沮丧的魔法咒语。Terraform？ suck得少一点，但阻抗不匹配。

他们需要的不只是更好的工具，而是一套全新的心智模型。三年后，这套模型有了名字：tc Cloud Functors（云函子）。

一张图，三个圆

tc的核心是一张极简的概念图。三个嵌套圆环，从外到内依次是：Cloud（云资源）、Compute（计算）、Code（代码）。

最外层Cloud，代表AWS、GCP、Azure这些云厂商提供的原始能力——存储、队列、数据库、事件总线。中间层Compute，是Lambda、容器、批处理作业等执行单元。最内层Code，才是工程师真正想写的业务逻辑。

传统基础设施工具的问题在于：它们逼你在最外层Cloud花费80%的精力。你要手动声明每个S3桶、每条SQS队列、每个IAM角色，像在玩一个永远通关不了的俄罗斯方块。

tc的洞见是：让Code层自动"坍缩"出Compute和Cloud。你写一段Python函数，标注它需要监听某个事件，tc自动推导出：需要创建EventBridge规则、需要Lambda执行角色、需要SQS死信队列——所有"云 plumbing"（管道工程）被隐藏。

这不是基础设施即代码（Infrastructure as Code）。这是代码即基础设施的逆向操作。

函子是什么？为什么用数学名词

Tommy用了"Functor（函子）"这个范畴论术语，不是装腔作势。

在数学中，函子是范畴之间的映射——保持结构的变换。tc Cloud Functors的核心操作类似：你在Code层定义的结构，被保持结构地映射到Cloud层。

具体来说，tc引入了几个关键抽象：

Topology（拓扑）：一个自包含的计算单元，包含输入、输出、处理逻辑。107个拓扑，就是107个独立部署、独立扩缩容的功能模块。

Wire（连线）：拓扑之间的连接方式。不是手动配置ARN，而是在代码里写source.wire_to(target)，tc自动创建底层事件路由。

Materialization（物化）：Code层到Cloud层的最终编译。本地开发时，拓扑跑在内存里；部署时，同一个定义变成Lambda+EventBridge+SQS的完整栈。

这种"一次编写，多处运行"的幻觉，正是函子的本质——结构保持的变换。

从340个Lambda到"看不见的云"

Informed的迁移不是推倒重来。他们采用了"绞杀者模式"：新功能用tc写，旧功能逐步包裹、替换。

关键转折发生在第18个月。Tommy回忆：「我们有个核心流程，原本需要改动7个CloudFormation模板、3个Terraform模块、2次手动IAM权限申请。用tc之后，一个工程师2小时搞定——包括测试。」

更隐蔽的收益是认知负荷的转移。新入职的工程师不需要先成为AWS专家，才能贡献代码。tc的拓扑抽象屏蔽了云厂商的复杂性，团队可以专注在贷款审批的业务逻辑上。

340个Lambda没有消失，但它们变成了"实现细节"。工程师看到的，是107个有明确输入输出的业务模块，像搭乐高一样组合。

Graph-First：被忽视的数据结构

tc的另一个激进选择是图优先（Graph-First）。

传统基础设施工具用树或列表建模：资源A依赖资源B，资源B依赖资源C。但真实世界的云架构是图：事件总线扇出到多个消费者，Lambda同时监听S3和DynamoDB流，死信队列被多个服务共享。

tc把整个系统建模为有向图。拓扑是节点，Wire是边。这种表示法的威力在于：它可以被分析、被优化、被可视化。

Tommy展示过一张图：Informed的生产环境拓扑图，107个节点、400多条边，自动生成的SVG。一个新工程师可以在10分钟内理解系统数据流，而以前这需要数周的代码考古。

图结构还解锁了传统工具难以实现的优化。tc可以自动检测"热点"——被多个拓扑订阅的事件源，建议拆分为专用队列；可以发现循环依赖，在部署前报错；甚至可以计算最小权限IAM策略，基于实际的调用图而非人工猜测。

Serverless的第二次浪潮

2014年Lambda发布时，承诺是"只需写代码，我们来处理基础设施"。十年过去，这个承诺只兑现了一半。

是的，你不需要管理服务器了。但你需要管理：函数版本、别名、并发限制、事件源映射、层、IAM角色、VPC配置、日志组、告警、死信队列……清单长得让人窒息。

业界反应是分层抽象。AWS推出SAM、CDK，社区有Serverless Framework、Pulumi。但Tommy认为这些仍是"CloudFormation的语法糖"——你在用更友好的语言，写同样繁琐的资源声明。

tc的不同在于语义层面的跃迁。它不提供"更好的方式声明Lambda"，而是问：如果云真的是一台计算机，编程它应该是什么体验？

答案是：事件驱动的、函数式的、响应式的。你描述计算图，系统负责物化到物理资源。当负载波动时，云自动扩缩容；当故障发生时，拓扑隔离限制爆炸半径。

这接近Serverless最初的愿景，但实现路径完全不同。不是"无服务器"，而是"服务器不可见"——它们存在，但不在你的认知界面里。

小众工具，还是范式转移？

tc目前仍是Informed的内部工具，正在逐步开源。它的学习曲线不平缓：你需要接受范畴论词汇，理解图建模，放弃对底层资源的精细控制。

但Tommy的赌注是：随着Serverless架构的复杂度指数级增长，这种认知税是值得的。340个Lambda不是终点，大型组织可能有数千个。没有更高阶的抽象，人类工程师将成为瓶颈。

历史上有过类似赌注。2006年，AWS EC2被批评"只是虚拟主机"；2014年，Lambda被嘲笑"只能跑5分钟"。范式转移总是从"过度设计"的指责开始。

tc的真正考验是社区采纳。如果它能从Informed的特定场景（金融文档处理、强合规、 burst流量）泛化到其他领域，"云函子"可能成为Serverless 2.0的标志性概念。

如果不能，它至少提供了一个有价值的对照：当我们抱怨云原生工具复杂时，问题可能不在工具，而在心智模型的代差——我们仍在用管理服务器的方式，编程一台已经变成计算机的云。

Tommy的系列文章还有多篇待发。下一篇据说会深入拓扑的数学结构，以及tc如何实现"本地开发体验与生产环境的一致性"——这是Serverless工具的另一个长期痛点。

对于每天在和CloudFormation搏斗的工程师，这系列值得一追。不是为了迁移到某个新工具，而是为了看一眼：如果云编程本该有的样子，会是什么模样。