从340个Lambda到"云函子"：一个云架构的疯狂实验

你有没有算过，一个8人小团队要管340个无服务器函数（Lambda）和107套拓扑，人均要背多少技术债？

三年前，Informed的工程师们真的算了这笔账：80%时间花在"手工接线"上，只有20%能写业务逻辑。他们处理着全美8%的汽车贷款，却困在一个巨型Ruby on Rails应用里——所有服务挤在弹性豆茎（Elastic Beanstalk）上，用单个Postgres数据库当消息总线。

这不是技术选型失败，而是创业公司的经典路径：先随机漫步找到市场，代码结构跟着业务一起"野蛮生长"。问题是，当合规要求（银行监管+无限量个人敏感信息）撞上规模，这套系统每加一个功能都像"移山"。

他们想要的不是更好的工具，是另一种思维方式

团队试过CloudFormation，作者的原话是"一堆令人沮丧的魔法咒语"——用低级脆弱的骨头造高性能引擎。Terraform"吸得少一点"，但阻抗不匹配：它不适合分布式无服务器系统的高速肌肉。

真正的痛点被一句话点破："我们需要停止管理资源，开始把云当作一台计算机来编程。"

这句话催生了tc Cloud Functors——一套"图优先"的云心智模型。作者用了个数学味很浓的词：函子（Functor）。别被吓到，核心想法其实挺野的：

把云基础设施当成一张图，节点是计算单元，边是事件流

传统做法是你先建S3桶，再配Lambda触发器，再绕去IAM调权限——像在三维空间里玩拼图。tc的做法是：你描述"当文件落地时，触发解析流程"，系统自己算出需要哪些云资源、怎么连线。

这有点像从"汇编语言"跳到"高级语言"。不是让你忘记底层，而是把底层编织成更高层的抽象。

作者背景很杂：从迷你计算机时代混起，1993年开过ISDN ISP，搞过国际服务器农场，2008年就开始用AWS。这种"福雷斯特·甘普式"经历让他有个观察：

云计算的进化一直在做两件事——把更多责任扔给云厂商，同时让开发者用更少的声明表达更多意图。

虚拟机时代你管操作系统，容器时代你管运行时，无服务器时代你管函数。下一步呢？

tc的赌注是：管"关系"而不是管"资源"

107套拓扑、340个Lambda、三种语言（Python/Ruby/Node）。这个数字本身说明无服务器的陷阱：函数太便宜了，便宜到你会疯狂繁殖，最后陷入"分布式单体地狱"——每个函数独立，但整体耦合在事件流里，没人看得懂全貌。

tc Cloud Functors想让你用一张图看见全貌。图里的节点可以是Lambda、SQS队列、S3事件通知，边是"触发""订阅""授权"这类关系。你修改图的结构，系统 diff 出需要变更的云资源。

这背后有个狠判断：云原生工具链的瓶颈不是"部署不够快"，是"认知负担太重"。

当开发者80%精力耗在"这根线该插哪"，他们已经输了。tc的目标是把比例倒过来——20%接线，80%写逻辑。

作者没透露具体技术细节（这是系列第一篇），但抛了个线索：tc处理的是"拓扑"（topology），不是"模板"（template）。

区别很微妙。CloudFormation和Terraform都是模板思维：你声明"我要一个S3桶"，系统去创建。拓扑思维是：你声明"我的数据处理流程需要持久化存储"，系统决定是S3、EFS还是DynamoDB，且能随需求漂移。

这有点像Kubernetes的声明式配置，但再往上抽象一层——K8s让你描述"想要的状态"，tc让你描述"想要的计算关系"。

为什么是现在？

作者提了个容易被忽略的点：Informed的工作负载特征——API驱动、机器对机器、高度突发、跟随美国工作时间的正弦波。

这是无服务器的甜点场景：流量从零到峰值再归零，传统服务器要么浪费要么崩溃。但甜点也有代价：事件驱动的调试地狱、冷启动延迟、分布式追踪的复杂度。

现有工具链是"服务器思维"的遗产。Terraform诞生于虚拟机时代，CloudFormation是AWS资源编排的直译。它们假设你在管理"东西"，而不是编织"流动"。

tc的激进之处在于：从第一天就假设你是事件流、是图、是函数组合。这让它能做一些"传统工具做得到但极痛苦"的事——比如给整个拓扑做类型检查，或者在部署前模拟事件流。

作者留了个钩子：tc不是"基础设施即代码"（IaC），是"基础设施即程序"（Infrastructure as Program）。

这个词选择很刻意。代码是静态的，程序是动态的、可组合的、有语义的。如果你能把云拓扑当成值（value）来传递、变换、组合，就能做IaC做不到的事——比如把"测试环境"和"生产环境"定义为同一套拓扑的不同求值结果。

一个值得玩味的矛盾

作者一边吐槽CloudFormation是"魔法咒语"，一边承认Informed的原系统"有很多优质工程"且"非常成功"。这不是技术优越感的抒发，是亲历者的清醒：

技术债不是愚蠢的代价，是验证的代价。每个"随机漫步"的代码决策，当时都可能是正确的折中。

tc的真正对手不是Terraform，是"再写一个Lambda"的惯性。当函数足够便宜，组织会无意识地选择"复制粘贴"而不是"抽象重构"。340个Lambda不是规划出来的，是107次"先上线再说"的累积。

tc想改变的是这个决策的边际成本。如果描述一个新拓扑和复制一个旧函数一样快，开发者才有动力保持架构整洁。

这系列还有后续。作者承诺会深入tc的设计——怎么实现图到云资源的编译、怎么做类型安全、怎么在340个函数的迷宫里保持理智。

单就这篇引言，有个问题悬在空中：当云厂商自己都在推"基础设施即代码"（AWS CDK、Pulumi），一个创业公司造的新抽象能有多大生存空间？

作者的隐性回答是：CDK和Pulumi还在"代码生成模板"的范式里，tc想跳过模板，直接操作拓扑语义。这有点像"汇编 vs 高级语言"的争论重演——不是替代，是分层。但分层本身需要生态位，而云厂商的引力场太强了。

tc的赌注或许是：无服务器架构的复杂度已经越过某个阈值，让"图优先"不再是学术趣味，而是生存必需。340个Lambda就是证据——不是炫耀规模，是展示危机。

作者最后没给结论，只给了个观察视角。这很符合"福雷斯特·甘普"式的叙事：我不是预言家，我只是碰巧在场，然后做了点东西。