122 lines
12 KiB
Markdown
122 lines
12 KiB
Markdown
# Endor 系统架构
|
||
|
||
Endor 的概念模型把全球访问、区域运行时和对象数据连接起来：请求从统一入口进入，在合适的区域找到 Nexus Runtime，再由它承载的 Aster VM 执行对象操作。PostgreSQL、Aerarium 和 S3 各自维护独立的分片群，在区域内保持高可用，并由统一备份系统追踪所有区域、所有存储类型的分片与恢复材料。
|
||
|
||
> **架构说明**：本文按当前讨论绘制目标架构，不表示这些组件和协议已经全部实现。图中的区域、节点、分片数量仅为示例；CDN 和身份服务的接入方式是建议方案。
|
||
|
||
## 架构总览
|
||
|
||
|
||
|
||
图中绿色/蓝色实线表示请求路径或区域内数据依赖，紫色虚线表示身份控制与公钥分发，蓝色点线表示 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」。对象身份、远程引用、生命周期与调用语义仍需结合[节点与对象挂载草案](/docs/02-mounting-draft)继续定义。
|
||
|
||
## 三类存储各自独立分片
|
||
|
||
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 已经实现本文的概念设计：
|
||
|
||
- [Traefik：服务与后端负载均衡](https://doc.traefik.io/traefik/master/routing/services/)。
|
||
- [OpenID Connect Discovery：配置发现和 JWKS URI](https://openid.net/specs/openid-connect-discovery-1_0.html)。
|
||
- [Amazon S3：同区与跨区异步复制](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)。本文中的 S3 指兼容对象存储，具体部署并未指定 AWS。
|