全后端最狠的项目,名字只有三个字母

一、碎片化:后端人的日常折磨

我向来是不惮以最坏的恶意来推测后端架构的。

然而我还不料,也不信竟会碎片化到这地步。

你一个后端项目,得装多少东西?队列——Kafka、RabbitMQ,挑一个。定时任务——cron、Inngest,再选一个。HTTP网关——NGINX、Envoy。可观测性——Prometheus、Grafana、Jaeger,三个起步。状态管理——Redis。日志——ELK。

够了吗?不够。还得有服务网格、API网关、配置中心、注册中心。

这还没完。

每个工具都有自己的SDK,自己的配置格式,自己的踩坑指南。团队来一个新人,环境搭建三天,三天里啥也没干,就在那儿解决依赖冲突。

折腾。

横竖都要搞一遍。大抵每个后端项目都是这么熬过来的——熬到后来,大家居然觉得”这就是正常流程”,仿佛不折腾七八个中间件就不算正经后端。

这就离谱。

然后一个叫 iii 的项目跳出来了。

简介写得颇为自信:”the easiest way to compose, extend, and observe every service in your stack in real time。”

翻译过来就是:你后端那堆乱七八糟的东西,我一个全搞定。

说人话:别装了,一个运行时搞定。

口气不小。

二、三个概念,一个运行时

iii 的核心模型极简——三个概念,没了。

准确说,是”只暴露三个概念”。底层当然还有引擎、序列化、路由,但这些对用户隐藏了。

Worker。干活的进程。任何功能都能变成一个 worker,几行代码的事。

Trigger。触发器。HTTP 请求、定时任务、队列消息、状态变更、流事件,声明式配置。

Function。真正干活的单元。有稳定的 ID,接收输入,执行任务,返回输出。

没了。就这三个东西。

Queue 是一等公民。Cron 是一等公民。HTTP 是一等公民。State 是一等公民。Observability 是一等公民。都在同一个运行时里,同一套接口。

你不需要为每个能力单独装中间件、学 SDK、维护配置。

你只需要 iii worker add。

这就好比,以前你装修房子,得找水电工、泥瓦工、木工、油漆工,每个工种单独约时间、单独沟通、出了问题互相甩锅。

现在来了个总包。

听着很美好。

但总包意味着什么?意味着你被一个人绑定了。水电工干得不好你还能换人,总包跑了你怎么办?重新找人把整套房子翻一遍?

这不叫统一。这叫把分散的风险集中到一处。

三、跑起来看看

先看看用起来什么样。

GitHub 上 17.7k Stars、1.2k Forks、1750 次提交、14 个 open issues、33 个 open PRs。昨天——6月6号——刚发了 v0.19.0。

嗯,1750 次提交。一个 0.19.0 版本的项目。提交数和版本号不太对得上。不过开源项目嘛,squash merge 多也正常——不对,也可能是 fork 过来直接合的。不管了,代码跑起来再说。

安装倒是不麻烦:

curl -fsSL https://install.iii.dev/iii/main/install.sh | sh

一行命令。

初始化项目、启动引擎:

iii project init quickstart --template quickstart
iii

引擎就跑起来了,监听在 ws://localhost:49134。

然后往里面加 worker:

iii worker add ./workers/math-worker      # Python
iii worker add ./workers/caller-worker    # TypeScript
iii worker add iii-state                  # 状态管理
iii worker add iii-http                   # HTTP 网关

调用呢?跨语言直接调:

iii trigger math::add a=2 b=3

Python worker 里的函数,被全局 ID 索引,任何语言都能调。不需要写路由,不需要配服务注册发现。iii 引擎替你全干了。

接上 HTTP 网关,外面一个 curl 就能打到:

curl -X POST http://localhost:3111/math/add-two-numbers \
  -H 'Content-Type: application/json' \
  -d '{"a": 100, "b": 200}'

整个链路——注册、发现、路由、追踪——零代码。

嗯。

确实省事。

但你细想——零代码的代价是什么?是你把控制权交出去了。以后出了问题,debug 的不是你的代码,是 iii 引擎的内部逻辑。这事儿谁干过谁知道。

四、跟 Temporal、Inngest、Dapr 有什么不同?

但问题来了。

市面上不是没有类似的东西。

Temporal 做工作流编排,做得很好。但它的边界很清楚——就是可靠的工作流,别的不管。

Inngest 做 serverless 函数编排,也是好工具。但它是 serverless 优先的,你跑不了一个常驻进程。

Dapr 试图做分布式应用运行时,野心跟 iii 差不多大。但学曲线颇陡峭,配置颇为复杂。配置 YAML 文件的时间,比写业务代码还长。这事儿我见过不止一次——不对,准确说,我见过好多次。团队花了一周配 Dapr 的 component YAML,结果业务代码才两百行。

iii 的做法不同。它不选边界。它说——所有这些,我都是第一公民。

不是”我也支持”,不是”插件扩展”,是”我生来就是干这个的”。

这差别大得很。

好比一个瑞士军刀和一个真正的全套工具箱。瑞士军刀什么都能干,但哪个都干不精。iii 想做的不是瑞士军刀——它想做那个把工具箱焊在一起的焊点。

所有组件都是原生集成的,不是插上去的。

区别就在于,组件越多,原生集成的优势越大。

焊点断了呢?

整个箱子散架。

所以你要么全盘信任 iii,要么从一开始就别碰。最危险的是那种”先用用看”的态度——用了一半发现不合适,想退回原来的架构?回不去了。你的服务已经深度耦合了 iii 的运行时。这可不是吓唬人。

五、Agent 原生:这招有点远

再说一个有意思的点。

iii 对 AI Agent 是原生友好的。

官方文档里写得很直白:

An agent is a worker. Its tools are functions. Its memory is state. Its orchestration is triggers.

什么意思?

你的 AI Agent 不需要额外接口、不需要额外适配、不需要跑在单独的 harness 里。Agent 本身就是 iii 运行时的一部分。它可以在运行时注册新的 worker、暴露新的函数、调用其他 worker——用跟开发者完全一样的接口。

这颇有些远见。

当然,远见不等于好用。历史上远见和好用之间差了十万八千里的项目多了去了。

因为大多数 agent harness 只管一个切面。要么只管工具调用,要么只管状态管理,要么只管编排。iii 的做法是——运行时本身就是编排引擎。一套模型,全部覆盖。

说得直白点——你不用再给 Agent 套一层”Agent 框架”了。市面上那些 LangChain、CrewAI,说白了都是在 iii 想做的那层之上再叠一层。叠多了,迟早要塌。

当然,也不是说 iii 就完美。0.19.0 的版本号摆在那里,bug 肯定不少。14 个 open issues、33 个 open PRs,说明项目还在快速迭代中。用这种早期项目,你得有心理准备——出问题得自己啃源码。

但你想想——Agent 能随时往系统里注册新的 worker,暴露新的函数。这意味着什么?

意味着你的系统边界是流动的。一个 Agent 觉得”这个任务我应该加个新能力”,它就加了。你觉得不妥?不好意思,它已经注册了。

这不是 bug,是 feature。

好吧,准确说——这既是 bug,也是 feature。取决于你信不信那个 Agent 的判断。反正我不全信。

六、适合谁?不适合谁?

那 iii 到底适不适合你用?

先说适合的。

如果你的后端基础设施碎片化严重——每个服务都有自己的集成方式,每个新服务都要写路由、配网关、接监控、搞日志——iii 值得一看。

如果你在跨语言组合服务——Python 的模型服务、Node.js 的 API、Go 的数据处理——想让它们像调用本地函数一样互相调用,iii 天然支持。

如果你在做 AI Agent 相关的项目——需要一个运行时让 Agent 动态扩展能力、可观测、可追踪——iii 可能是目前最贴合这个需求的方案。

不适合的呢?

你的架构已经很稳定了,现有工具跑得好好的。没必要为了一个”大一统”的概念重构一切。重构的代价,远比你想象的大。这事儿我见过——团队花三个月把一套跑得不错的微服务搬到新架构上,结果性能降了 30%,上线又踩一堆新坑。图啥呢?

你对 Elastic License 2.0 有顾虑。iii 引擎用的不是开源协议——它允许你免费用、免费改、免费发布,但不允许你拿它做一个和 iii 竞争的托管服务。对大多数团队来说不算问题,但如果你是云厂商,或者打算把它作为核心组件对外提供服务,就要小心了。SDK 倒是 Apache 2.0。这招挺精明的——免费给你用,但你不能拿去卖。说白了,就是开源版免费,商业版收钱。不丢人,但你得知道。

你追求极致性能。多一层运行时,就多一层开销。iii 用 WebSocket 做引擎通信,对于低延迟场景未必是最优选择。如果你的服务要求毫秒级响应,这层 WebSocket 中间件就是多余的——别不信,实测过的人自然懂。

说白了,iii 适合那些被碎片化折磨到受不了的人。如果你还没到那个地步,别急。

七、满本写着两个字——野心

我翻开了 iii 的源码一查。

Rust 写的引擎,多语言 SDK(Node.js、Python、Rust、Go),React + Rust 的控制台,Agent 可读的技能文档。

歪歪斜斜的每页上都写着”统一”几个字。

我横竖睡不着,仔细看了半夜,才从字缝里看出字来。

满本都写着两个字——野心。

它想做的,不是替代某一个工具,而是改变后端开发的范式。

能成吗?

大抵是难的。

但如果你深夜加班,打开终端看到 iii 在跑,所有服务都在一个窗口里,所有日志都在一个界面里——那种”终于不用在八个 tab 之间来回切”的解脱感。

大约值回票价了。


关于码孖AI

码孖AI,专注 AI 工程化落地。我们相信:AI 不是来替代程序员的,是来帮程序员省时间的——前提是,你得会用。

关注我,持续更新实战踩坑指南。

:::callout tip 觉得有用? 点个「在看」,分享给同样在 AI 落地路上挣扎的朋友。 :::