架构设计方案 (Architecture Design)¶
本文档完整阐述了当前基础设施的“双区域混合网络拓扑 (Twin-Hub Hybrid Mesh)”。所有后续的新增部署、网络配置以及故障排查必须严格依据本方案的全景视图进行。
1. 架构总览 (Global Overview)¶
整个基础设施横跨两个异地的 Oracle Cloud 区域，底层通过安全的 Tailscale 组建虚拟专网 (VPN 隧道)。
- 🇬🇧 欧洲中心 (London Swarm): 由部署在英国伦敦的 3 台节点构成的 Docker Swarm 高可用集群。作为算力池，承载重型数据库、主要对外的业务应用以及持续运算服务。
- 🇰🇷 亚洲中心 (Chuncheon Standalone): 部署在韩国春川的 2 台独立服务器。承担着距离亚洲用户最近的网络出口职责（网关代理拦截），同时也作为全局管理节点存放监控面板和私有内部服务。
控制平面 (Control Plane) 采用单一入口哲学：春川的“主节点”上部署管理面板 (Portainer Server)，通过 Tailscale 隧道，以“只读/受控指令”形式向分布在所有地点的 Agent 下发命令并纳管全局。
2. 网络平面设计 (Network Planes)¶
网络被划分为三个严格隔离的“平面”，这是兼顾安全性访问与服务内网可发现性的核心方案：
| 网络平面 | 类别驱动 | 解析对象与范围 | 定位与用途 |
|---|---|---|---|
| 底层平面 (Underlay) | 物理网络 (Oracle VCN) | 公网与单可用区内网互通 | 服务器之间的硬连线，处理 SSH (端口 22)直连和建立外网 VPN 打洞。完全受 Oracle 外部安全列表 (Security List) 防护。 |
| 隧道平面 (Mesh Overlay) | tailscale0 (Host 模式) |
跨国、跨区域服务 | 关键的基础设施平面。所有管理面板 (如 9001 端口)、跨区域的代理转发，全量且只能行进在此平面。这是零信任安全的基石。 |
| 应用平面 (Docker Net) | Bridge / Swarm Overlay | 单台节点内部 / 专属 Swarm 集群内 | 跑业务应用。例如 proxy-kr 网络服务春川自身容器互访，proxy-uk 网络支撑整个伦敦集群的动态解析。 |
[!TIP] 设计决策：为什么坚持 Tailscale 使用 Host 模式？ 我们有意识地将 Tailscale 容器配置为
network_mode: host，强制它在宿主操作系统生成一个名称为tailscale0的网卡（而非默认的用户态代理）。 这样，Portainer Agent 能够直接把服务绑定到宿主机的100.x.y.z专属内网地址。因为防火墙默认 Drop 一切，这就从根本上杜绝了服务端口被公网扫描/攻击的可能，实现了“只允许内网互信机器管理”的设计目标。
3. 部署标准化与目录 (Topology Standards)¶
业务部署应当具备高度的一致性和可预测性，分为隔离的两大“配置层”：
3.1 固定的目录结构¶
/opt/infra/bootstrap/：基建层 (Layer 0)。这里放置使一台“毛坯服务器”能独立工作并接入控制中心的基础组件。通常就是一个基础的docker-compose.yml（包含net-tailscale与ops-portainer/agent两个容器）。/opt/infra/stacks/：业务层 (Layer 1)。通过 Portainer 图形化界面或 Stack 统一部署的各类业务文件及其持数据久化的卷存放处。
3.2 节点的角色分类¶
A. 基础设施司令部 (Chuncheon-1 主节点)¶
- Layer 0 职责: 运行组网的核心 (
net-tailscale) + 全局指挥中心 (ops-portainer)。 - 安全特征: 控制面板决不直接向公网裸奔。它的控制端强制映射并在
127.0.0.1，仅通过专门的区域网关 (Traefik) 的安全认证访问路由。
B. 集群算力节点与边界节点 (London 全系 / Chuncheon-2)¶
- Layer 0 职责: 组网 (
net-tailscale) + 被指挥端 (ops-portainer-agent)。 - 安全特征: 所有的 Agent 监听本机
9001。这要求极高安全管控——宿主机的 OS 防火墙 (ufw) 以及 Oracle 的出口规则必须强拦截来自任何外网尝试连接 9001 端口的动作。
4. 流量路由与转发逻辑 (Traffic Routing)¶
所有的 HTTPS 网关接入和域名转发都由各个区的 Traefik 集群承担。
4.1 场景一：区域内网业务访问（同区路由）¶
- 用户访问某个位于伦敦的纯净应用如
https://blog.u.120224.xyz。 - 域名解析将流量送到伦敦 Swarm 负责外部接口的 Traefik (
net-traefik-uk)。 - Traefik 依据内部 Docker Socket 解析到的标签 (Labels)，智能将包在
proxy-uk网络内转给后端的服务实例。核心优势：在区域内部的横向互访，应用容器完全不需要开放 (
ports: ...) 给操作系统，这杜绝了旁路渗透。
4.2 场景二：跨区域穿透访问（网关跨城路由）¶
- 服务器资源在英国（某重度应用或因备份考虑留在 Swarm），但想要一个能从亚洲更低延迟触达的前置入口（例如：
https://hub.i.120224.xyz）。 - 用户从浏览器发起的连接首先抵达亚洲春川主节点的 Traefik-KR。
- 因为是跨城，内网容器并不互通。在英国的应用配置
ports: - "100.88.x.x:5000:5000"，仅在它自己位于隧道的 Tailscale IP 暴露了特定的传输端口。 - 春川的网关获取这个请求，根据手动设置的动态路由指引，封装加密数据包发到特定的那个
http://100.88.x.x:5000节点。核心优势：利用加密隧道打破物理孤岛。不论机器放在哪，都可以把流量交由前置的反向代理统一分配并加持认证墙。
5. 高可用性设计与底线 (HA Boundaries)¶
- 无单点故障（网络级）: 网关 Traefik (UK) 在 Swarm 中以全局模式多路分发部署，任意单台服务器宕机，访问都不会中断。Tailscale 采用完全分布式的 P2P 连接构架。
- 有物理限制的有状态服务 (Stateful Apps): 有些服务不可避免地涉及重量级的本地 IO（例如
app-pcrdb数据库集群）。- 架构让步：我们尚未有分布式 Ceph 存储池的支持，所以业务在 Swarm Compose 中采用了
constraints: [node.hostname == london3]物理设备约束进行就地锚定。 - 缓解策略：依托 Rclone 的热备份快照外加外网异地网盘进行弥补，以此降低机器暴毙造成的核心业务长时停顿风险（详见容灾体系指引文档）。
- 架构让步：我们尚未有分布式 Ceph 存储池的支持，所以业务在 Swarm Compose 中采用了
6. 主机名与设备命名约定¶
主机名统一采用：
<region>-<provider>-<role>-<index>
推荐缩写：
- region：cn、kr、uk
- provider：bce、oci
- role：dev、main、aux、mgr、worker
- index：两位序号，如 01
示例：
- cn-bce-dev-01
- kr-oci-main-01
- kr-oci-aux-01
- uk-oci-mgr-01
- uk-oci-worker-01
约定：
- Linux hostname 按此规则设定
- Tailscale 设备名尽量与 hostname 保持一致
- 域名独立规划，不要求与 hostname 完全一致