“你们的架构是怎样的？”——Zion 的几个关键决策，和背后的原因

用户问我们技术问题的时候，问法一般都很笼统：

你们的架构是怎样的？

我有一万多个用户，你们会崩掉吗？

数据安全怎么保障？

这三个问题都没法用一句话回答。一个平台撑不撑得住、安不安全，取决于它在几个关键地方做了什么选择，以及为这些选择付出了什么代价。下面我会把 Zion 从 2020 年到现在做过的几个关键决策摊开来讲：当时的约束是什么，考虑过哪些方案，为什么选了现在这个，代价是什么。其中有好几个决策，我们一开始选的并不是现在的方案，后来才改掉。

Zion 不为每个项目生成代码。所有项目共用一套运行时，由它来执行你在编辑器里搭出来的应用定义；数据存在 PostgreSQL 里，每个项目有自己独立的 schema；数据接口和权限是我们自己写的，业务逻辑跑在数据旁边，默认在一个事务里执行；AI 改的是应用定义，而不是代码。

这些决策背后是同一个判断：复杂度应该留在平台里，而不是留给创始人。代价是平台本身更难做，用户的自由度也受到一定限制。我们认为这个交换是值得的。

一、整体架构

编辑器跑在浏览器里。你在这里搭页面、建数据模型、配置行为流，或者让 AI 帮你做这些事。你做的所有修改，最后都会变成一份结构化的“应用定义”：有哪些页面、页面上有什么组件、有哪些表和字段、每个按钮点下去会发生什么。多人同时编辑时，大家改的是同一份定义。

控制面负责保存应用定义，并在你点“发布”时把它变成一个能运行的应用：比较新旧两版数据模型，生成数据库变更并执行；把新的定义同步给后端运行服务；把前端需要的文件放到 CDN 上。它也负责管理所有运行服务器，以及在我们升级运行时的时候，把新版本推到每一台服务器上。

运行时是所有项目共用的。前端运行时读取应用定义，把它渲染成 Web 页面、小程序或者 App；后端运行服务根据每个项目的数据模型，提供这个项目的数据接口，检查权限，执行行为流和定时任务。

数据层的核心是 PostgreSQL。每个项目在数据库里有自己独立的 schema，项目里的每张表都是一张真正的数据库表。Redis 用来做缓存和分布式锁。用户上传的图片、文件，以及发布出来的前端页面和资源，存在对象存储（阿里云 OSS）里，通过 CDN 分发给终端用户。

基础设施是 Kubernetes。控制面、后端运行服务、PostgreSQL，全都以容器的形式跑在 Kubernetes 集群里，Zion 用的是阿里云的容器服务。一台“运行服务器”，在 Kubernetes 里就是一组资源：一个后端运行服务、一个 PostgreSQL 数据库，以及存放运行日志的数据库。新开一台运行服务器、把它升级到新版本、把项目从一台搬到另一台，都是由控制面调用 Kubernetes 的接口自动完成的。

选 Kubernetes，原因和选数据库时一样：不能被某一家云厂商锁定。同一套部署方式，可以放到不同的云上，也可以放进客户自己的云账号里（见第四节）。PostgreSQL 也是我们自己在 Kubernetes 里运行，而不是用云厂商托管的数据库（比如阿里云 RDS），原因是成本和控制。托管数据库是一台运行服务器对应一个实例，规格固定，而我们的大多数数据库实际用到的资源很少，自己运行更便宜。控制是指数据库版本、扩展和升级节奏都由我们自己掌握，而很多 PostgreSQL 扩展在托管数据库上是用不了的。

举一个例子。我们正在上线 BM25 关键词检索，支持 43 种语言。其中英语、法语、俄语等 29 种语言用的是 PostgreSQL 自带的词干算法，在哪里都能跑；另外 14 种，在托管数据库上做不到或者做不全：日文、韩文、泰文的分词，用的是我们自己写的扩展，托管数据库不允许安装；波兰语、捷克语、乌克兰语等 10 种语言，要靠放在数据库服务器上的词典文件来还原词形，托管数据库不开放文件系统；中文分词用的扩展，也不是每家托管数据库都提供。

另外，我们尽量不拆微服务。后端只有两个应用：控制面和后端运行服务，各自按领域分成几十个模块，模块之间是代码里的调用，不走网络。微服务本质上解决的是团队太大、大家挤在同一套代码和同一条发布流程上互相等的问题，但代价也很严重：每多一个服务，就多一次网络往返，性能变差、成本变高；就多一种“一半成功、一半失败”的情况，因为跨服务的调用没法放在同一个事务里；也多一个要单独升级、单独监控、单独管理依赖版本的东西。我们的团队不大，这些代价远大于收益。

所以这些年我们做得更多的是“合并”。2021 年，自己写的数据接口引擎并进了后端运行服务；2022 年，后端运行服务里的消息队列从 RabbitMQ 换成了直接用 PostgreSQL 实现的队列，少了一个要单独运维的组件；2026 年 6 月，独立的 AI 服务连同它自己的数据库，一起合并回了控制面。现在单独部署的，只剩下三类不得不拆的东西：只能用 JavaScript 实现的（比如前端渲染、协同编辑的合并），存储引擎不同的（运行日志），以及出于安全必须隔离的（比如我们正在做的云函数：用户自己写的代码，不能和我们的内网相通）。

接下来我会逐个讲这些设计是怎么来的。

二、用 PostgreSQL

这是我们做的第一个决策。完整的选型过程我以前写过一篇，这里我只讲结论。

当时的硬性要求是：单个应用要能支撑百万级用户；要有 ACID 事务；要便宜；不能被某一家云厂商锁定；要支持二级索引。最后进入决赛的是 PostgreSQL、MySQL 和 MongoDB。

MongoDB 的卖点是不需要 schema。但我们观察下来发现，所有无代码平台在内部其实都维护着一份 schema——用户看到的就是“表”和“字段”。既然 schema 无论如何都存在，不如让数据库来保证它。对于非技术用户，平台应该多给一些约束，而不是更多自由：我们的工作是减少心智负担，不是增加。

在 PostgreSQL 和 MySQL 之间，PostgreSQL 的几个特性对我们很重要：结构变更（DDL）可以放在事务里，要么全部执行、要么全部回滚，而我们会频繁地自动执行结构变更；只有一种不限长度的文本类型，用户不需要预先知道一段文字有多长；LISTEN/NOTIFY 在事务提交时发出通知，适合做实时订阅。

最终起决定作用的是 SQL 的查询优化器。一个无代码平台事先不知道用户的数据长什么样、会怎么查。自己写一个查询优化器等于重新造轮子，而 PostgreSQL 的优化器已经打磨了几十年。

代价也很明确：修改表结构时有些操作要锁表；更新数据会产生需要清理的旧版本行；大规模数据迁移比文档数据库慢一些。这些都需要我们在平台里处理掉，不让用户感知到。我们依然选它，因为换来的查询优化器和事务，是我们自己做不出来的。

完整的分析见：创始人说｜Zion 数据库的选择之旅

三、不按项目生成代码，所有项目共用一个运行时

这是整套架构里最核心的决策，后面几个决策都建立在它上面。

2020 年刚开始做的时候，我们走的是很多人觉得最自然的路：把用户搭出来的应用“翻译”成代码。前端为每个项目生成一份源码——Web 一份，小程序一份——再分别构建；后端在运行时根据接口定义生成 Java 代码，动态编译后加载。

2022 年起，我们陆续放弃了当时的做法，原因是复杂度。

按项目生成代码，意味着平台要同时维护三样东西：生成代码的模板；每个平台各自的构建流程；以及成千上万份彼此不同的生成产物。

更大的问题是微信小程序的体积。微信对小程序的包体积有严格的上限，主包和每个分包都不能超过 2MB。生成代码时，应用里的每个页面、每个组件都会展开成一段代码，应用越大，生成出来的代码就越多，很快就会碰到这个上限。

后端的动态编译还带来了一个更具体的问题。它依赖的编译库与 JDK 17 不兼容，2022 年 2 月，我们升级 JDK 17 时不得不退回到 JDK 11。同年 5 月，我们去掉了运行时编译，当天就完成了 Java 17 的升级。也就是说，生成代码这条路曾经直接挡住了我们升级基础设施。

现在所有项目共用一个运行时。前端从 2022 年 10 月开始重写为统一的运行时：它不再为每个项目生成代码，而是直接读取应用定义来渲染页面。2023 年 7 月起，新的 Web 项目用上了新运行时；2024 年 8 月，小程序也切换了过来；同年 10 月，我们批量迁移了存量项目；12 月，我们删掉了旧的代码生成器——一共 12 万多行代码。后端也一样，行为流、数据接口都是根据项目的定义直接执行的。

现在，小程序里打包的是一份固定的运行时加上应用定义，体积不再随着生成代码膨胀。后端修复一个 bug 或者升级一个依赖，我们只需要改一份代码、发一次版本，所有项目同时生效；前端的修复也只需要改一份运行时，项目下次发布时就会用上。

为了让前后端的行为完全一致，我们还做了一件事：用 Kotlin 写了一套类型系统，同时编译成 JVM 和 JavaScript 两个版本，编辑器、后端和运行时共用。后端执行行为流时，表达式的求值也用的是和前端同一份代码。一个公式在页面上算出来是什么结果，在后端算出来就是什么结果。

这个决策有两个代价：

解释执行有性能开销。 读取定义再执行，总比直接执行写好的代码多一层。为此，我们正在考虑在保持统一运行时的前提下，对前端做编译优化。

你拿不到一份可以带走的源代码。 应用的“源代码”就是那份应用定义，它离开 Zion 的运行时没法单独运行。

我们依然这么取舍，因为性能可以靠优化运行时一次性提升所有项目，数据也随时可以导出；而按项目生成代码的复杂度，只会随着项目数量一直增长。

四、共享服务器，每个项目一个 schema

一开始，每个项目都有一套独立的运行环境：自己的 Kubernetes 命名空间、自己的 PostgreSQL 数据库、自己的接口服务。服务器的成本很高。

2022 年 6 月到 7 月，我们改掉了这种做法，原因是大多数项目在大部分时间里是没有流量的——在做原型的、在测试的、还没上线的、上线了但用户不多的。每个项目一套环境，意味着要为大量空闲的资源付钱。在这之前，2022 年 3 月，我们先让不活跃的项目自动休眠；到了 6 月至 7 月，我们改成了现在的模式：多个项目共用一台运行服务器，老项目也迁移了过来。

项目之间用 schema 来区分，而不是在表里加一列 tenant_id。多租户的另一种常见做法是所有租户共用同一批表，用一列 tenant_id 来区分数据属于谁。这对 Zion 不可行：每个项目的数据模型都不一样，一个项目有“订单”表，另一个项目有“课程”表。要让它们共用表，只能把数据存成通用的键值或 JSON 结构——这正是我们在数据库选型时排除掉的方案。

每个项目一个 schema，有几个好处：

项目里的每张表都是真正的数据库表，有真正的列类型、外键和索引，查询优化器能正常工作。

每个项目的结构变更互不影响，一个项目加字段不会碰到别的项目。

一个项目可以整体搬走。把它的 schema 导出，再导入到另一台服务器上，就完成了迁移。

最后一点让“升级”变得很简单。付费档的服务器上放的项目更少；需要更多资源的项目，可以独享一台服务器。对于数据必须留在自己云账号里的客户，我们提供 BYOC（bring your own cloud）：在客户自己的云账号里配置好 Kubernetes，然后直接通过 Kubernetes 把整套运行环境部署进去。

这个决策的代价是项目之间会互相影响。同一台服务器上的项目共用 CPU、内存和数据库，一个项目流量暴涨，邻居的响应速度可能会波动；服务器本身出了问题，上面的所有项目都会受影响。独享服务器和 BYOC 就是为不能接受这一点的项目准备的。对大多数项目来说，共享换来的是低得多的成本，这是免费版和低价档能长期做下去的前提。

五、自己写数据接口，权限放在这一层

2020 年，每个项目的数据接口由 Hasura 提供。Hasura 是一个开源工具，能根据 PostgreSQL 的表结构自动生成 GraphQL 接口，当时用它是最快的。

2021 年 12 月，我们换掉了 Hasura，主要有两个原因。

第一，接口之外的东西在 Hasura 里很难做。Hasura 擅长的是“把表变成接口”，但一个应用不只有增删改查。在 Hasura 里，业务逻辑只能写成单独的代码服务，甚至写成数据库里的 SQL 函数；调用第三方 API 也只能写代码。这些都没有类型检查，平台没法知道一段逻辑需要什么输入、会产生什么输出，也就没法把它变成用户能在编辑器里拖拽配置的东西。后来我们要在应用里加入 AI 智能体，这个问题就更突出了。

第二，Hasura 是用 Haskell 写的。会写 Haskell 的工程师太少，遇到问题时，我们很难自己去改它。

2020 年 12 月，我们开始写自己的接口引擎：根据项目的数据模型，在运行时生成这个项目的 GraphQL 接口。2021 年 12 月，新引擎全量上线；2022 年 9 月，我们删掉了所有 Hasura 相关代码。为了让已有的应用不受影响，新引擎保留了和 Hasura 一致的接口格式。

自己写引擎之后，我们可以针对无代码的场景做优化。比如嵌套查询：一次请求“所有订单，以及每个订单的商品和买家”，如果逐层去查，就会产生成百上千次数据库查询，也就是常说的 N+1 问题。现在，我们会把整个嵌套查询编译成一条 SQL，交给数据库一次执行完。

权限检查放在接口这一层。每个请求进来时，我们从用户的登录令牌里识别出这是谁、有哪些角色。然后：

行级权限，比如“用户只能看到自己的订单”，会被编译成 SQL 里的过滤条件，和用户自己的查询条件合并，由数据库来执行。过滤发生在数据库里，能用上索引，没有权限的数据根本不会被读出来。

列级权限按查询请求的字段来检查。没有权限的字段单独返回错误，不会让整个查询失败。

PostgreSQL 自己也有行级安全（RLS），我们没有用它，原因有两个。

一是太浪费。要用 RLS，数据库就得知道“当前是谁”：每次开启事务，都要先执行几条 SET 语句，设置这一次的角色和用户信息。我们试过在每次取用连接时多设置一个参数（application_name），开销就已经能在监控上看出来，最后只在调试时才打开。RLS 每次要设置的东西更多，而且数据库读每一行数据时都要再执行一遍权限策略。

二是权限要管的不只是数据。一个用户能不能执行某个行为流、能不能调用某个接口，同样是权限问题，而这些不在数据库里。我们想做的是基于属性的访问控制（ABAC）：根据用户的属性、数据的属性和当时的环境来判断能不能做一件事。这种规则只能放在比数据库更高的一层。

这样做的代价是，安全语义完全由我们自己负责。数据库不会替我们兜底，每加一条新的查询路径，都必须确保权限检查覆盖到它。我们依然这么做，因为接口层是唯一能同时看到数据、操作和用户属性的地方，权限放在这里才管得全。

六、业务逻辑放在数据旁边，默认在一个事务里执行

在 Zion 里，后端逻辑用行为流来搭建：查询数据、写入数据、调用 API、运行代码、调用 AI，按顺序串起来。行为流在后端运行服务里执行，和数据库在同一个机房里。同步行为流默认在一个事务里执行：中间任何一步失败，这次执行对数据库的所有改动都会撤回，就像什么都没发生过一样。

用一个卖票的例子来说明。一场演出有 500 个座位，热门场次几十秒就卖完。一个观众点“购买”，后端要做五件事：检查座位还在不在，把座位标成已售，创建订单，核销观众使用的优惠券，生成电子票。

第一个好处是“要么全做完，要么全没做”。 假设第四步核销优惠券时出错了。在事务里，前三步的改动会一起撤回：座位重新变成可售，订单不存在，数据和这个观众没点过“购买”时一模一样。

不放在事务里，前三步就已经生效了：座位被标成已售，却没有对应的电子票。这个座位再也卖不出去，观众也拿不到票。而且这种错误不会报错，不会有任何红色的提示，数据只是悄悄地错了。要修好它，你得自己写一段“补偿”逻辑：发现做了一半的订单，把前几步一一撤回。补偿本身也可能失败，那就还要再处理“撤回失败”的情况。对一个没有后端经验的创始人来说，这几乎不可能做对。这也是我们在选数据库时就定下的原则：“这组操作要么全部成功，要么全部没有发生”很好理解，而“前两步成功了、第三步失败了，你需要发现并撤回前两步，撤回本身也可能失败”就很难理解了。

第二个好处是并发时数据不会乱。 两个观众在同一瞬间抢最后一个座位 A12。如果座位上有唯一约束，数据库会保证只有一个人能写入成功；另一个人那一步会失败，他这次的整个行为流都会撤回，不会留下半个订单。

如果检查和写入不在一起，两个人会同时看到“A12 还在”，然后都买下了它。按每秒十几单的速度卖票，这不是偶然现象，而是每场都会发生的事。

第三个好处是快。 行为流和数据库在同一个机房，每一步数据库操作的往返在 1 毫秒左右，五步加起来也就几毫秒。

如果这五步由离数据库很远的地方依次发起——比如由用户的浏览器逐个调用接口，或者放在部署在世界各地的边缘函数里——每一步都要跨网络往返。假设一次往返 150 毫秒，五步就是 750 毫秒，用户会明显感觉到卡。更大的问题在数据库那一边：每个请求占着数据库连接的时间变长了，同样一台数据库能同时服务的人就变少了。而数据库几乎总是整个系统里最难扩容的那一部分。

第四个好处是逻辑不会被绕过。 逻辑在服务器上执行，用户拿不到、也改不了。如果这五步写在前端，懂一点技术的人就可以跳过“检查座位”这一步，直接调用后面的接口；用户中途关掉页面，也会留下一个做了一半的订单。

需要写代码的场景，行为流里有运行代码的节点，代码在一个有时间限制的沙箱里执行；前端也支持代码组件。

这个决策有两个代价：

不是所有操作都能撤回。 调用外部 API、调用 AI、发短信这类操作，一旦发出去就收不回来，所以它们不在事务里。同步行为流的执行时长也有上限。

异步行为流没有整体事务。 耗时很长的流程需要用异步执行，每一步单独提交。包含 AI 智能体的行为流必须异步执行。

我们依然把事务作为默认，因为大多数业务逻辑本来就是一组数据库操作。把少数不能撤回的情况单独标出来，比让所有逻辑都没有事务安全得多。

七、AI 改的是应用定义，而不是代码

现在 AI 已经能写全栈应用了，但在 Zion 里，AI 智能体不写代码。

我们在 AI 上也走过弯路。2023 年 8 月，编辑器里上线了第一版 AI 助手，2024 年 1 月下线了。2025 年 3 月，我们把 AI 做成了一个独立的服务，有自己的部署和数据库；2026 年 6 月，我们删掉了这个独立服务和它之前的几套实现，一共近 3 万行代码，把 AI 合并回了后端；从 7 月开始，智能体改成了现在的架构。

AI 能做的事，是一组有类型的操作。 加一张表、给表加一个字段、给页面加一个组件、给按钮配一个行为流、设置一条权限规则——这些都是操作，一共三百多种。每一种操作的参数格式，都是从第三节讲的那套类型系统里自动生成的；AI 发出的每一次调用，都要先经过类型系统的校验，参数不合法就会被拒绝。AI 能写出来的，只有这些操作，没有别的。

这样做有几个原因：

AI 能表达的东西被限制住了。 AI 没法写任意代码，所以它不可能引入并发问题、跳过事务、拼出一条能被注入的 SQL，也不会凭空引入一个新的依赖包。加锁、并发、扩容、事务这些基础设施，在运行时和数据库里，根本不在 AI 能操作的范围内。AI 只碰业务本身：有哪些数据、数据之间什么关系、谁能看什么、点了按钮之后发生什么。

AI 做出来的应用和人做的跑在同一个运行时上。 第三节讲的统一升级同样适用于 AI 做的应用：我们修一个漏洞、做一次性能优化，它们跟人做的应用一样用得上，没有一份需要单独维护的生成代码。

用户和 AI 改的是同一份定义。 智能体跑在服务器上，但它的修改会打包发给你打开着的编辑器，由编辑器应用到那份多人协同的文档上。所以 AI 改了什么，你在编辑器里能实时看到，可以和它同时改，随时可以接着改。你不需要先读懂一段 AI 写的代码。

工具的数量可以继续增长。 三百多种操作不会一次性塞给模型。智能体手里常驻的只有几个固定的基础工具；数据库、行为流、权限、支付这些领域的操作，按任务需要分插件加载。这样，请求开头那一段提示词保持不变，可以被模型缓存；我们加新的操作，也不会撑爆模型的上下文。

还有两个设计，是为了让智能体更可控、也更有用：

人始终可以拍板。 在搭建模式下，任何会改动应用的操作都要先经过你的确认；智能体要向你提问、或者提出一个计划时，会停下来等你回答。

同一套操作，对外也开放。 Cursor、Claude Code 这类外部的 AI 编程工具，可以通过我们提供的命令行工具和 MCP 来操作一个 Zion 项目，用的是同一套操作，同样经过类型系统的校验。删除项目这类不可撤销的操作，会弹出一个需要人手动确认的对话框，外部的 AI 没法自己批准自己。不管最后是我们自己的智能体更好用，还是别家的更好用，用户都能用上。

2026 年 9 月起，我们还给每个智能体会话配了一台临时的沙箱机器。在这之前，智能体能读写应用定义、调用应用的接口，但不能下载文件、读 PDF、转换图片或者跑一个构建；而且它依赖你打开着的编辑器，一合上电脑，正在做的事就停了。沙箱里有命令行和工具链，也能代替编辑器执行那套操作，所以智能体可以做这些事，你把编辑器切到后台时它也能接着干。

这样做的代价是，AI 只能做平台支持的事。每多一种能力，我们都要先加一种有类型的操作。平台还不支持的需求，要通过运行代码的节点或者代码组件来实现。我们依然这么选是因为我们觉得对非技术用户来说，AI 做出来的东西可靠比 AI 什么都能做更重要。

八、回到开头的三个问题

关于“你们的架构是怎样的”：所有项目共用一套运行时，执行你在编辑器里搭出来的应用定义；数据存在 PostgreSQL 里，每个项目一个独立的 schema。

关于“我有一万多个用户，你们会崩掉吗”：一万多个用户，对一个真正的 PostgreSQL 数据库来说不算多。下面是两个我们支持过的例子：

海南自贸港知识竞赛：64 万人次参与，219 万次答题，峰值 4.4 万 DAU，跑在一台 2 核的服务器上。

青岛的核酸小程序：12 万 DAU，服务器 8 核，实际用到 4–5 核，P95 响应时间 16ms。

能做到这一点，靠的是前面几节讲的几个决策：真正的表和索引，让查询优化器能正常工作；嵌套查询编译成一条 SQL；业务逻辑和数据在同一个地方。

关于“数据安全怎么保障”，有三层保障：

每个项目在数据库里有自己独立的 schema，项目之间的数据在逻辑上是完全隔开的。

每个请求都要经过接口层的权限检查，行级条件直接编译进 SQL。

需要物理隔离的项目，可以独享服务器，或者用 BYOC 部署在自己的云账号里。

数据安全还包括另一层意思：如果有一天你想离开，或者平台出了问题，你的数据要能拿得出来。这一点由下面三件事保证：

数据随时可以导出成 Excel 或 CSV，可以附带图片等媒体文件。

每个项目都有一套有文档的标准 GraphQL 接口，任何客户端都能直接调用，读出你所有的数据。

你的数据存在真正的 PostgreSQL 表里，而不是某种私有格式或者 JSON 大字段。表就是表，字段就是字段，换到任何一个关系数据库都能对应上。

结论

从 2020 年到现在，Zion 的架构改过很多次：先按项目生成代码，后来改成所有项目共用一个运行时；先一个项目一套环境，后来改成共享服务器；先用 Hasura，后来自己写了数据接口；AI 先做成一个独立的服务，后来又合并回了后端。每一次改动，都要把已有的项目平滑地迁移过去，用户不需要做任何事。

方案换了很多次，目的一直没有变：让一个非技术创始人不需要关心连接池、事务回滚、查询优化或者依赖升级，也能做出一个可靠、撑得住真实流量、一直有人维护的应用。每一次改动，都是因为我们发现旧方案把复杂度留在了不该留的地方——要么留给了用户，要么留给了以后的升级。这些复杂度不会消失，只会转移，而平台的价值，就在于把它们接过来。以后架构几乎一定还会继续改，但这个愿景不会变。