Invidious：界面、媒体路径与运维责任
Invidious 架构：网页请求、账号状态与媒体字节走不同路径
追踪 Crystal/Kemal 前端、PostgreSQL 初始化和 companion 路由，不把所有请求都画成同一条代理链。
你将学会
- 把启动入口看成依赖装配
- Companion 有简单和高级两种接入形态
- 区分控制元数据、账号状态和流式响应
开始前需要
- 了解 HTTP 和容器基础
- 区分应用状态与媒体流量
解释依赖和信任边界，准备可核验的试验，并在真实范围内理解源码与模型证据。
先看结论
- 启动、持久状态和媒体传输是不同架构问题。
- public_url 会改变浏览器到 companion 的接入方式。
- 缓存中的 companion 选择不是通用故障切换保证。
把启动入口看成依赖装配
应用入口加载 Kemal、配置、数据库模块、路由、后台任务和上游辅助模块，并依据配置中的数据库 URL 打开 PostgreSQL；连接失败时会退出。在本次检查的路径中，持久状态是启动依赖，并不是因为页面看起来静态，就可以忽略的纯浏览器附加功能。
同一入口还为 YouTube、图片请求和 companion 通信创建连接池。即使它们位于同一个进程，也承担不同职责。页面请求可能涉及元数据和应用状态，而播放器接收的字节可能走另一条路径。如果把图中所有箭头都画成笼统的 API 调用，就会隐藏实际运维边界。
Companion 有简单和高级两种接入形态
配置说明把 private_url 定义为应用到 companion 的内部地址。没有 public_url 时，应用代理 companion 请求；配置 public_url 后，用户请求可以通过单独配置的反向代理路由直接到达 companion。“私有”描述的是预期拓扑，运营者仍需要落实网络隔离和密钥管理。
配置多个 companion 时，说明文档表示：获取视频数据时随机选择一个 companion，并把这个选择保留在对应的元数据缓存项中；缓存过期后才会重新选择。这不等于逐包负载均衡、透明故障切换或确定性的流量分配。容量规划需要同时考虑缓存行为和实际接入拓扑。
区分控制元数据、账号状态和流式响应
本次检查的 companion 路由通过连接池转发 GET、POST 和 OPTIONS，复制响应状态和头部，并用 IO.copy 流式复制响应体。这与把整个视频放进字符串缓冲区是有价值的代码层区别，但仅凭这一点，不能证明所有层的内存上限，也不能保证每种错误都会变成易理解的客户端响应。
账号历史和订阅属于实例状态，后台工作也有自己的生命周期。诊断时应按数据库连接、网页路由、companion 通信、上游响应和浏览器播放分别定位。搜索页正常与媒体路径故障可以同时存在。本篇图解表达的是检查过的接口约定，没有采集分布式追踪或测量真实拓扑。
实施步骤
- 1
追踪配置加载和 PostgreSQL 初始化。
- 2
分别绘制元数据、账号状态和媒体响应路径。
- 3
记录 private_url 与 public_url 对应的入口路由。
- 4
为每条边界确定探针和负责人。
可复制示例
{
"privateUrl": "application-to-companion",
"publicUrlConfigured": "browser-to-companion route requires edge configuration",
"selection": "retained with cached video metadata",
"liveTraceCollected": false
}常见问题
设置 public_url 是否也应该公开数据库？
不是。它描述浏览器可访问的 companion 路由，数据库是否暴露是独立问题，该拓扑并不要求公开数据库。
多个 companion 是否保证即时故障切换？
本次检查的说明描述了随机选择和元数据缓存保留，并没有给出经过验证的透明故障切换保证。
资料来源
- invidious/config/config.example.yml来源核查 2026-09-08
- invidious/src/invidious.cr来源核查 2026-09-08
- invidious/src/invidious/routes/companion.cr来源核查 2026-09-08
- documentation/docs/installation.md来源核查 2026-09-08