[{"data":1,"prerenderedAt":25},["ShallowReactive",2],{"article-20-k8s":3},{"id":4,"title":5,"slug":6,"description":7,"content":8,"coverImage":9,"tags":10,"category":15,"categoryName":12,"draft":16,"reviewStatus":17,"viewCount":18,"readingTime":19,"author":20,"createdAt":23,"updatedAt":24,"series":9},"847668131346211693","20万用户量级网站 K8S 高可用整体架构方案","20-k8s","面向 20 万注册用户级别的网站，在 Kubernetes 上落地高可用、可扩容、可运维架构的一套参考方案。","这是一份面向中小型互联网网站的 Kubernetes 高可用参考架构。重点不是\"堆机器\"，而是先明确流量边界，再按接入、应用、缓存、中间件、存储、运维分层设计，最终实现高可用、弹性伸缩和成本可控。\n\n## 1. 需求边界与容量假设\n\n### 1.1 核心前提\n\n这里的\"20 万用户量级\"通常指 **20 万注册用户**，并不等于同时在线 20 万。\n\n建议按以下模型做容量规划：\n\n| 指标 | 建议假设 | 说明 |\n|------|----------|------|\n| 总注册用户 | 20 万 | 业务基础盘 |\n| 日活用户 DAU | 2 万～4 万 | 常见留存 10%～20% |\n| 峰值 QPS | 300～800 | 早晚高峰、活动峰值可突破 1000 |\n| 读写比 | 9:1 | 读多写少是典型互联网网站形态 |\n| 业务特点 | 缓存热点、静态资源多、流量波动明显 | 适合做分层和削峰填谷 |\n\n> 这个量级一般 **不需要超大规模集群**。真正的目标是：**不宕机、抗峰值、易扩容、能运维、成本别失控**。\n\n### 1.2 设计原则\n\n- **管控与业务分离**，避免业务负载影响控制平面稳定性\n- **所有核心服务尽量多副本**，不要把\"单副本\"当成默认方案\n- **先缓存后数据库**，尽可能把压力挡在最前面\n- **运维体系独立部署**，不要让监控、日志、告警和业务抢资源\n- **可扩容优先于一次性堆满资源**，为后续增长留余地\n\n---\n\n## 2. 集群规模与机器规划\n\n### 2.1 推荐生产配置：3 Master + 6 Worker\n\n采用管控与业务分离的标准方案，兼顾稳定性和成本。\n\n#### 2.1.1 控制平面节点（Master）\n\n| 项目 | 推荐配置 |\n|------|----------|\n| 节点数量 | 3 台 |\n| 推荐规格 | 4 核 8G 起步，8 核 16G 更稳妥 |\n| 核心职责 | 只做集群管控，不跑业务容器 |\n\n**建议部署组件**：`kube-apiserver`、`kube-scheduler`、`kube-controller-manager`、`etcd`\n\n**设计价值**：\n\n- 3 节点构成奇数投票的 etcd 集群\n- 单台 Master 故障不影响集群整体运行\n- 避免业务高并发把控制面拖慢，导致调度异常或无法扩缩容\n\n#### 2.1.2 业务工作节点（Worker）\n\n| 项目 | 推荐配置 |\n|------|----------|\n| 节点数量 | 6 台 |\n| 推荐规格 | 8 核 16G 起步，流量偏高可选 16 核 32G |\n| 核心职责 | 运行业务 Pod、中间件 Pod、运维组件 |\n\n建议按用途拆分：\n\n- **业务应用节点 3 台**：前端、后端 API、网关、定时任务\n- **中间件专属节点 2 台**：Redis、MQ、ES 等\n- **运维组件节点 1 台**：监控、日志、告警、CI\u002FCD 相关组件\n\n**这样拆分的原因**：\n\n- 避免中间件和业务相互抢资源\n- 避免监控\u002F日志系统被业务洪峰拖垮\n- 减少\"一个故障拖垮整套系统\"的概率\n\n### 2.2 预算精简方案：3 Master + 3 Worker\n\n如果预算有限，可以先采用 6 台机器的轻量方案：\n\n- 3 台 Master\n- 3 台 Worker\n- 允许轻微混装，但不建议用于频繁活动峰值场景\n\n> 这套方案更适合初创项目或早期验证阶段。若业务已经有明显促销峰值、搜索热度或多团队接入，建议直接上 3+6。\n\n---\n\n## 3. 整体分层架构\n\n### 3.1 架构总览\n\n建议采用经典的互联网四层链路：**接入层 → 应用层 → 缓存与中间件层 → 数据存储层**。\n\n```\n用户请求 → CDN → SLB\u002F云负载均衡 → Ingress-Nginx → 应用服务 Pods\n                                                          ↓\n                                                    Redis \u002F RabbitMQ \u002F Kafka \u002F Elasticsearch\n                                                          ↓\n                                                    MySQL 主从 \u002F 监控\u002F日志\u002F告警\n```\n\n### 3.2 接入层\n\n#### 3.2.1 CDN\n\n- 承担图片、JS、CSS、视频等静态资源分发\n- 降低源站 QPS 和带宽压力\n- 对热点内容做边缘缓存，减少回源次数\n\n#### 3.2.2 SLB \u002F 云负载均衡\n\n- 统一承接公网流量\n- 支持四层或七层转发\n- 配合健康检查自动剔除异常节点\n\n#### 3.2.3 Ingress-Nginx\n\n- 负责域名路由、TLS 终止、路径转发\n- 可做基础限流、黑白名单、访问控制\n- 适合作为集群北向流量入口\n\n### 3.3 应用层\n\n所有业务容器化部署，核心原则是：**禁止单副本运行**。\n\n- **前端静态页面**：Nginx Pod 多副本部署，配合 CDN\n- **后端 API 服务**：按领域拆分，如用户、订单、内容、支付等，每个服务至少 2～3 副本\n- **定时任务 \u002F 异步处理服务**：独立部署，避免和接口服务抢资源\n- **弹性扩缩容**：使用 HPA 作为基础能力，结合业务指标做扩缩容决策\n\n> HPA 不建议只看 CPU。更合理的方式是结合 **CPU + 请求量 + 延迟 + 自定义指标**，这样更接近真实负载。\n\n### 3.4 缓存与中间件层\n\n#### 3.4.1 Redis\n\n- 缓存用户信息、热点数据、会话、接口结果\n- 优先挡住高频读取压力\n- 常见形态是 **主从 + 哨兵**，适合单主读多写场景\n\n> 如果后续数据量和写入规模继续增长，再考虑 Redis Cluster；不要一开始就把\"集群模式\"当成默认答案。\n\n#### 3.4.2 RabbitMQ \u002F Kafka\n\n- 用于消息异步化、削峰填谷、解耦业务链路\n- 适合订单、通知、日志、异步任务等场景\n- 防止突发流量把主流程打爆\n\n#### 3.4.3 Elasticsearch\n\n- 适合全文检索场景\n- 也可承担日志检索能力，但日志最好和业务查询解耦\n- 不建议把 ES 当成万能存储\n\n### 3.5 数据存储层\n\n#### 3.5.1 MySQL 主从架构\n\n- 推荐 1 主 2 从\n- 主库负责写入\n- 从库分担读查询、报表、备份任务\n- 配合读写分离降低主库压力\n\n#### 3.5.2 持久化存储\n\n- 使用 K8S PV \u002F PVC 绑定云盘或高性能存储\n- 确保关键业务数据和中间件数据具备持久化能力\n\n#### 3.5.3 备份策略\n\n- 数据库每日全量备份\n- binlog 持续归档\n- 关键数据支持快速回滚和灾备恢复\n\n---\n\n## 4. 高可用设计要点\n\n### 4.1 集群高可用\n\n- 3 节点 Master 冗余，etcd 采用多数派机制\n- Worker 节点故障时，Pod 可自动漂移到健康节点\n- 使用节点亲和 \u002F 反亲和，避免核心服务集中在同一台机器上\n\n### 4.2 业务高可用\n\n- 核心服务多副本部署\n- 定时任务、异步任务与在线接口分离\n- 通过限流、熔断、降级防止流量雪崩\n- 接口设计要具备幂等性，减少重复请求带来的脏数据\n\n### 4.3 数据高可用\n\n- MySQL 主从复制 + 故障切换机制\n- Redis 主从 + 哨兵自动选主\n- 核心数据采用定时备份 + 异地快照\n\n---\n\n## 5. 监控、日志与发布\n\n### 5.1 监控体系\n\n- 使用 Prometheus + Grafana 监控节点、Pod、CPU、内存、QPS、延迟、数据库指标\n- 重点关注：Pod 重启次数、节点可用率、请求耗时、错误率、连接数、磁盘使用率\n\n### 5.2 日志体系\n\n- 集中采集应用日志、访问日志、审计日志\n- 使用 ELK \u002F OpenSearch 体系便于检索和定位问题\n\n### 5.3 告警体系\n\n- 节点宕机\n- 服务异常\n- QPS 异常波动\n- CPU \u002F 内存持续过载\n- 数据库延迟异常\n\n### 5.4 发布策略\n\n- 滚动发布\n- 灰度发布\n- 必要时支持快速回滚，保证业务尽量零停机更新\n\n---\n\n## 6. 扩容策略\n\n### 6.1 横向扩容路径\n\n当业务增长时，优先沿着\"先扩资源，再拆分瓶颈\"的顺序演进：\n\n- 用户量突破 50 万：增加 Worker、优化缓存、必要时 Redis 分片、MySQL 分库分表\n- 大促活动峰值：临时扩容节点、提高 HPA 上限、提前预热缓存\n- 流量不均衡：调整节点亲和、污点容忍和调度权重\n\n### 6.2 何时需要重构\n\n以下信号出现时，说明当前架构已经接近上限：\n\n- 主库写入明显成为瓶颈\n- 缓存命中率持续下降\n- 单个服务拆分粒度不够，导致发布风险过大\n- 监控与日志系统本身开始影响业务稳定性\n\n---\n\n## 7. 方案总结\n\n### 7.1 推荐方案\n\n**生产推荐配置：9 台机器（3 Master + 6 Worker）**\n\n### 7.2 预算精简方案\n\n**精简配置：6 台机器（3 Master + 3 Worker）**\n\n### 7.3 结论\n\n这套方案适合 **20 万注册用户、日均数万访问、峰值千级 QPS** 的中小型网站。它的核心优势不是\"最省机器\"，而是：\n\n- **高可用**\n- **可弹性伸缩**\n- **易运维**\n- **支持后续扩容**\n- **整体成本可控**",null,[11,12,13,14],"Kubernetes","后端","架构设计","高可用","backend",false,"APPROVED",10,9,{"id":21,"username":22},"847415776292930438","hermes","2026-05-28T10:50:31.425564","2026-05-29T12:23:54.826249",1780059956182]