Files
endorphin-tabularium-docs/content/docs/00-endor-concepts-draft.md
T
codex-bot 9fcfbdb694
Verify and deploy Tabularium / verify-and-deploy (push) Successful in 5m28s
Protect Tabularium with persistent authenticator-code login
2026-10-27 21:48:16 +08:00

12 KiB
Raw Blame History

Endor 系统架构

Endor 的概念模型把全球访问、区域运行时和对象数据连接起来:请求从统一入口进入,在合适的区域找到 Nexus Runtime,再由它承载的 Aster VM 执行对象操作。PostgreSQL、Aerarium 和 S3 各自维护独立的分片群,在区域内保持高可用,并由统一备份系统追踪所有区域、所有存储类型的分片与恢复材料。

架构说明:本文按当前讨论绘制目标架构,不表示这些组件和协议已经全部实现。图中的区域、节点、分片数量仅为示例;CDN 和身份服务的接入方式是建议方案。

架构总览

Endor 架构:全球入口连接北美、亚洲及其他区域;各区两个 Traefik 与五个 Nexus Runtime 全连接,每个 Nexus 侧下方配一个 Aster VM;Aerarium 分片群分别与 PostgreSQL、S3 分片群全连接,所有分片汇入统一备份系统

图中绿色/蓝色实线表示请求路径或区域内数据依赖,紫色虚线表示身份控制与公钥分发,蓝色点线表示 CDN 回源,金色虚线表示向统一备份系统采集数据。连线表示可达或依赖关系,不表示请求向所有节点广播。

全球入口与区域入口

客户端包括浏览器、Tessera、SDK 和 CLI。endorphin API 是逻辑上的全球流量入口,尚未在本文规定一个真实的域名。全球调度根据健康、延迟、项目归属和数据放置策略选择区域;不能只选择网络最近的区域而忽略对象在哪个分片。

图中展开北美和亚洲两个区域,并用“ … / etc · 其他区域”表示可以继续扩展。每个区域有自己的负载均衡入口,下面是 Traefik 网关,负责按配置进行 TLS、主机名或路径路由。图中的第二个 Traefik 标记为 HA 副本:多副本是生产冗余选项,单实例概念部署不要求两个网关。

为什么画成二分全连接

每个区域示例中有两个 Traefik 和五个 Nexus Runtime,画出全部十条边,即二分图 K₂,₅。网关使用独立的路由分流图标,与 Nexus 的服务器图标区分。每个网关都能把请求路由到任意一个符合条件的健康 Runtime,避免把一个网关固定绑定到一个运行时。

这是逻辑可达关系。实际转发仍需考虑服务发现、健康检查、项目和对象归属,以及有状态连接的路由策略;Runtime 之间并没有因此形成全连接网状网络。

Nexus Runtime 与 Aster VM

此处采用 一个 Nexus Runtime 节点配一个 Aster VM 的概念约定。Nexus 表示对外接入与运行时承载边界,Aster VM 执行对象相关逻辑。图中每台服务器侧下方单独画出一个 VM 芯片,用点线连接到对应 Nexus;节点与 VM 采用错位排布,保持一对一归属。

请求经过区域入口和 Traefik 到达 Nexus,再定位目标分片。图中运行时下方的连接汇入分片路由层,表示节点可以按归属访问区域分片,不是「Runtime 1 只能访问分片 1」。对象身份、远程引用、生命周期与调用语义仍需结合节点与对象挂载草案继续定义。

三类存储各自独立分片

PostgreSQL、Aerarium Object data pool 和 S3 是三组独立的分片群。图中每组各展开三个分片,数量可以独立增长,分片边界也可以不同;不能将一个 PG 分片、一个 Aerarium 分片和一个 S3 分片打包成固定“三件套”。

分片群 概念职责 分片标识示例
PostgreSQL 结构化元数据、对象索引及需要事务约束的状态;具体数据模型待定 NA-PG-01、NA-PG-02、NA-PG-03
Aerarium Object data pool 对象数据的逻辑组织、对象池状态和访问层;同时依赖 PG 与 S3 NA-AO-01、NA-AO-02、NA-AO-03
S3 兼容存储 Blob、文件、快照和适合对象存储的数据;具体格式待定 NA-S3-01、NA-S3-02、NA-S3-03

分片群之间的全连接

每个 Aerarium 分片都能按映射访问任意一个 PostgreSQL 分片,也能访问任意一个 S3 分片。图中左右各画一组 K₃,₃:Aerarium ↔ PostgreSQL 有九条边,Aerarium ↔ S3 也有九条边;每区合计十八条存储关系边。

这些线表示逻辑可达关系,实际读写仍根据对象归属、分片映射、授权与健康状态选择目标。它们不表示广播,也不表示所有分片保存相同数据。PostgreSQL 和 S3 之间没有凭空增加直接全连接;两种存储通过 Aerarium 的对象模型与版本映射协作。

运行时访问先进入对象池的分片定位层,再由 Aerarium 按映射访问 PG 和 S3。因此不同层可以采用不同的分片数量和容量规划,而无需一一绑定。

区域内高可用

每个存储图标下面有一个小型副本图标,用点线连接,表示本区域的高可用副本。生产部署应跨独立故障域放置,具体可以是不同可用区或独立节点。

这是逻辑 HA 要求,各层的实现不同:PostgreSQL 可以使用主备复制,Aerarium 需要自己的状态协调和故障恢复设计,S3 的耐久性与副本由选定的存储系统提供。图不强制三者采用同一种同步复制机制,也不把单纯增加副本等同于已经实现故障自动切换。

一个统一的备份系统

备份是覆盖所有区域的总体系统,不按“北美备份亚洲、亚洲备份北美”分成两个固定系统。它统一编排各区域、各存储类型的备份采集、持久化、校验、保留与恢复。物理副本应隔离源区域的故障风险,实际存放位置由备份策略决定;图中不将该系统固定放进任何业务区域。

图中金色线路将每个区域的三类分片群接入同一备份边界,代表采集组内全部分片。统一恢复目录按“区域 + 存储类型 + 分片 ID”追踪每个分片,避免遗漏或将不同层的编号误当作同一个分片。

备份中的 PG、Aerarium、S3 分别是什么

备份内容 保存什么 恢复时的用途
PostgreSQL 备份 各 PG 分片的基础备份、WAL 与可恢复时间点等事务恢复材料 恢复结构化元数据与事务状态
Aerarium 备份 各对象池分片的状态、索引、对象身份和版本映射等恢复材料,具体格式待定 重建对象池,并关联 PG 恢复点与 S3 对象版本
S3 备份 各 S3 分片的实际对象版本、Blob、文件及快照 恢复被对象池引用的实际字节数据

这里展示的是统一系统内三类不同的备份内容与采集能力,不是每个备份槽里又放一套在线 PG + Aerarium + S3 服务。系统还要维护统一恢复清单、校验和、重试状态,以及各层的版本对应关系。

恢复某个对象或项目时,清单应能定位所需的 PG 分片恢复点、Aerarium 分片状态与 S3 对象版本。因为三类存储独立分片,恢复集合也可能涉及多个不同编号的分片;不能按固定三件套恢复,也不能只备份其中一种存储就宣称整个对象可恢复。

“最终一定拿到数据”需要怎样的保证

设计目标是:正常访问优先本区域;本地不可用时,仍能找到异地保存的数据。需要区分两类能力:

  • 异地在线副本:已有服务能读取它;追平状态、授权和路由满足要求后,才可承担故障读取。
  • 异地备份:保留了恢复材料,需要恢复 PostgreSQL、重建 Aerarium 并校验对象版本后才能提供服务,通常更慢。

保证边界:异步复制与定期备份不能无条件保证最后一笔已确认写入不会丢失。若源区在复制完成前永久丢失,未到达异地的数据仍可能丢失。当前图承诺的是“已校验恢复点可恢复”的目标,而非已实现的零数据丢失保证。

要实现更强的承诺,需要明确写入确认条件。例如必须等跨区持久化成功才返回写入成功,或者以独立耐久日志作为重放来源,并设计重试、校验、告警与恢复演练。这会增加延迟或实现成本,不能只靠一条“最终一致”虚线获得。

后续设计需要分别确定 RPO(可接受的数据丢失窗口)和 RTO(恢复服务所需时间),以及备份保留、删除传播、加密密钥和数据跨区合规策略。

CDN 应该放在哪里

建议把 CDN 作为面向静态和可缓存内容的边缘路径,与动态 API 调度区分:

  1. 客户端请求静态前端、文档或允许缓存的对象,优先命中 CDN;命中后直接返回,无需访问 Nexus。
  2. 缓存未命中时,CDN 回源到指定的 S3 兼容存储,或专门的资源服务。图中仅示例回源到亚洲区域的 S3,并不把亚洲设为唯一源站。
  3. 私有对象可使用短时签名 URL、受控回源或独立授权服务。缓存键、过期、权限隔离和失效策略需要单独设计。
  4. 登录、写入、实时连接和个性化动态 API 默认不进入共享缓存。CDN 能代理这些流量,不代表应该缓存这些响应。

CDN 是可替换、可选的加速层,不是数据库副本,也不承担跨区灾难恢复的唯一责任。

身份服务是否依赖 Nexus

建议在逻辑上独立,不把它画成依赖某个业务 Nexus 的服务。 客户端向身份服务登录或刷新凭证;Nexus 验证访问凭证、项目归属和操作权限后才接受业务请求。

图中紫色线路表示公钥或认证配置的分发关系:使用适当的签名访问令牌方案时,Nexus 可以缓存 JWKS,在本地完成签名及必要声明校验。具体访问令牌格式尚未确定,不能把 OpenID Connect 的 ID Token 直接当作所有 API 的授权凭证。

如果采用不透明令牌、即时撤销或实时策略评估,可能需要在线内省或授权查询;这会引入身份服务的在线依赖,需要单独设计可用性和失败策略。已有令牌可离线验证也不意味着公钥轮换、过期、撤销和权限变化可以不处理。

身份服务本身仍可以使用 PostgreSQL、缓存和密钥管理等基础设施;逻辑独立不等于没有存储依赖。将来即使选择在通用 Nexus 基础设施上托管它,也应保留独立的故障和信任边界,避免启动、登录与业务运行时形成循环依赖。

继续确定的设计边界

  • 全球入口如何发现项目与分片的归属,跨区域请求采用转发还是让客户端重连。
  • Nexus 接入职责与 Aster VM 边界、连接亲和性和 Runtime 故障迁移。
  • Aerarium 的数据格式、事务边界、对象版本和跨存储一致恢复点。
  • 区域内 HA 的实际协议与跨区域 RPO/RTO、故障读取与恢复流程。
  • 身份签发者、访问令牌验证与撤销机制,以及私有内容的 CDN 授权。

参考依据

以下资料仅用于解释通用组件的能力,不证明 Endor 已经实现本文的概念设计: