接着始皇的说 揭秘 LINUX DO 网站服务器架构
讨论下当前负责的生产项目的集群架构
架构图
graph TD
A["👤 用户访问"] --> B["☁️ Cloud CDN"];
B --> C["⚖️ Cloud Load Balancing"];
C --> D["☸️ K8s 集群 (API & Worker)<br>(2主3从)"];
subgraph "后端内部服务"
direction LR
subgraph "后台工作服务 (K8s Pods)"
I["🔥 缓存预热服务"];
J["✍️ 异步写入服务"];
end
%% Internal Data Stores & MQ
E["📦 Memorystore for Redis"];
F["🐘 Cloud SQL for PostgreSQL"];
H["📨 NSQ 服务"];
%% Main API Synchronous Flows
D -- "同步读 (高频)" --> E;
D -- "同步读/写 (低频)" --> F;
D -- "发布消息 (高频写)" --> H;
%% Asynchronous Message Consumption
H -- "消费消息" --> J;
%% Cache Warming for internal DB
F -.-> I;
I -. "预加载数据" .-> E;
%% Async Write for internal DB
J -. "异步写入" .-> F;
J -. "更新缓存" .-> E;
end
%% External Services & Gateways
G["🍃 MongoDB Atlas"];
K["🌐 Cloud NAT"];
L["🌍 互联网 (其他服务)"];
%% VPC Peering Connection for MongoDB Atlas
D -- "VPC Peering (内网连接)" --> G;
%% NAT for all other internet-bound traffic
D -- "出站流量" --> K;
K -- "访问" --> L;
%% Logical data flows via VPC Peering
G -. "数据源 (经VPC Peering)" .-> I;
J -. "异步写入 (经VPC Peering)" .-> G;
%% Advanced Styling
classDef default fill:#f9f9f9,stroke:#333,stroke-width:2px,font-size:14px;
classDef user fill:#e0e7ff,stroke:#5b21b6,stroke-width:2px,color:#312e81;
classDef gcp fill:#dcfce7,stroke:#16a34a,stroke-width:2px,color:#14532d;
classDef k8s fill:#fee2e2,stroke:#dc2626,stroke-width:2px,color:#7f1d1d;
classDef db fill:#fef9c3,stroke:#ca8a04,stroke-width:2px,color:#713f12;
classDef mq fill:#f3e8ff,stroke:#9333ea,stroke-width:2px,color:#581c87;
classDef worker fill:#e5e7eb,stroke:#4b5563,stroke-width:2px,color:#1f2937;
classDef internet fill:#f0f9ff,stroke:#0ea5e9,stroke-width:2px,color:#0c4a6e;
class A user;
class B,C,K gcp;
class D k8s;
class E,F,G db;
class H mq;
class I,J worker;
class L internet;
linkStyle 7 stroke:#2563eb,stroke-width:2px,stroke-dasharray: 2 3;
（gemini画的架构图真不咋的）
个人总结： 通过读写分离、异步处理和多层缓存来最大化系统的吞吐量和响应速 度，同时考虑到成本和运维复杂度 选择自建集群和使用云数据服务
- 大量使用google cloud中间件服务
- k8s集群为自建
- 内部服务为api+rpc 每个服务按负载动态调整pod数量
- 使用Cloud Nat 作为流量出口
- 目前月消大概2w+
