在学习Docker之前我们需要先学习服务器架构目录单机服务架构特点优缺点适用场景应用数据分离架构特点优缺点适用场景应用服务集群架构特点优缺点适用场景读写分离架构特点优缺点适用场景冷热分离架构特点优缺点适用场景垂直分库架构特点优缺点适用场景微服务架构必备基础设施优缺点服务间通信模式适用场景容器编排架构特点核心组件优缺点适用场景横向对比总结架构演进路线架构选型决策矩阵各架构核心数据对比架构演进阶段建议单机服务架构特点维度说明部署应用、数据库、文件存储全部打包在同一台服务器上运行通信进程内函数调用或本地 Socket无网络开销数据单一数据库实例应用直连本地数据库团队极简运维单人即可管理全部技术栈LAMP (Linux Apache MySQL PHP) 或 Tomcat MySQL Nginx优缺点优点缺点开发简单IDE 友好调试方便单点故障服务器宕机则整个系统不可用部署极简一个包或一条命令搞定不可水平扩展只能靠升级硬件垂直扩展性能高进程内调用无网络延迟资源争抢应用和数据库共享 CPU/内存/磁盘事务管理简单本地事务安全风险攻击者攻破应用即拿到数据库初期开发效率极高适合快速验证随着规模增长代码耦合度急剧上升适用场景初创项目 MVP 快速验证业务逻辑简单的内部管理系统团队规模 1~5 人的小型项目无需高可用高并发的工具类应用应用数据分离架构特点维度说明部署应用服务器和数据库服务器分机部署各自独立运行通信应用与数据库通过 TCP 网络通信数据数据库独立于应用服务器可单独配置和优化硬件应用服务器侧重 CPU数据库服务器侧重内存和磁盘 I/O技术栈应用服务器Tomcat/Node.js 独立数据库服务器MySQL/PostgreSQL优缺点优点缺点应用和数据库可按需独立配置和升级硬件应用服务器和数据库各仍为单点任一宕机服务不可用数据库不暴露在公网安全性提升引入网络延迟每次数据库交互需经网络传输部署结构清晰为后续架构演进打下基础水平扩展能力仍未解决应用和数据库资源不再互相争抢运维成本略增需管理多台服务器适用场景业务量增长单机资源出现瓶颈需要将数据库隔离到更安全的内网环境团队规模 5~10 人开始有专职 DBA 或运维应用服务集群架构特点维度说明部署同一应用部署在多台服务器上由负载均衡器统一分发请求通信客户端先到 LBLB 按策略轮询/最少连接/IP Hash分发到后端节点高可用单台应用节点宕机流量自动切到健康节点用户无感知Session多节点带来状态共享问题需引入 Redis 集中 Session 或 JWT 无状态方案技术栈Nginx/HAProxy 多台应用服务器 单台数据库服务器优缺点优点缺点应用层高可用单节点故障不影响整体服务数据库仍是单点成为系统的瓶颈和故障源水平扩展流量增加时加机器即可Session 共享需额外引入 Redis 或改造成无状态支持灰度发布和滚动更新不影响在线服务负载均衡器本身需考虑高可用如 Keepalived 双机热备解耦应用层团队可按节点分工运维引入分布式后调试排错复杂度上升适用场景用户量增长应用服务器 CPU 或内存成为瓶颈需要保证应用层高可用容忍短暂停机不可接受日均 PV 达到百万级以上读写分离架构特点维度说明数据架构一主多从一个主库负责写入多个从库负责读取同步机制主库通过 binlog 将变更异步复制到所有从库读扩展从库可线性扩展读流量按比例分摊到各从库路由策略需中间件或代码层实现读写分离路由ShardingSphere / MyCat延迟控制主从之间存在同步延迟对实时性要求极高的场景需强制读主库优缺点优点缺点读性能线性扩展增加从库即可分摊读压力主从延迟刚写入后立刻读可能拿到旧数据天然适合读多写少的互联网场景资讯、电商浏览写瓶颈未解决主库仍是单点写入写入压力大时无计可施从库可承担报表、数据分析等离线查询不影响线上业务需引入中间件或在代码层手动切数据源增加开发复杂度主库故障时可快速将从库提升为主库实现故障转移主从切换需额外机制保障可能出现数据不一致适用场景读多写少的业务如内容资讯、商品浏览、社交 feed 流数据库读操作成为主要性能瓶颈读写比在 8:2 或更高冷热分离架构特点维度说明分层策略按数据访问频率分为热、温、冷三层每层使用不同成本的存储介质热数据近期、高频访问的数据放 Redis/内存级存储保证亚毫秒级响应温数据访问频率中等的数据放 MySQL/SSD 存储平衡性能和成本冷数据历史归档、极少访问的数据放 HDFS/OSS/S3 等廉价存储生命周期需定义迁移策略数据按时间或访问频率自动从热层降级到冷层优缺点优点缺点大幅降低存储成本90% 冷数据用廉价存储10% 热数据用高性能存储冷热判定逻辑复杂需定义合理的温度标准和迁移策略热数据查询速度不受冷数据规模影响始终保持低延迟跨冷热存储的查询需在应用层或中间件层处理冷数据归档至对象存储后天然支持异地容灾从冷存储恢复数据延迟高秒到分钟级不适合实时场景Redis MySQL HDFS/OSS 组合经过大规模验证成熟度高数据迁移过程可能影响线上性能通常需在低峰期执行适用场景海量数据存储如日志系统、电商订单归档、IoT 设备数据数据有明显的时效性越旧的数据访问越少存储成本成为主要矛盾需要精细化控制垂直分库架构特点维度说明拆分维度按业务域用户、商品、订单、库存将单一数据库拆分为多个独立数据库数据归属每个业务模块拥有自己专属的数据库数据模型在该模块内闭环跨库操作原有单库 SQL JOIN 失效跨业务数据查询需在应用层分步完成并组装事务保障跨库操作需引入分布式事务方案Seata / Saga / TCC / 本地消息表独立扩缩各业务库根据自己的访问量和数据量独立扩容或缩容优缺点优点缺点业务维度解耦各业务模块数据独立团队可并行开发跨库 Join 失效无法用一条 SQL 跨业务查询独立扩缩订单库压力大不影响用户库可针对性扩容分布式事务下单同时扣库存需额外方案保证一致性故障隔离商品库宕机不会拖垮用户登录功能数据一致性保障复杂最终一致性方案增加业务代码量为微服务拆分打下数据层基础数据库连接池数量激增应用需管理多个数据源适用场景单库表数量和并发量接近上限业务模块边界清晰模块间数据耦合度较低开始按业务域分工的团队各业务线有独立的开发小组微服务架构┌─────────────────────────────────────────────────────┐ │ 微服务九大核心原则 │ ├─────────────────────────────────────────────────────┤ │ 1. 围绕业务能力组织 │ 6. 独立部署 │ │ 2. 去中心化治理 │ 7. 基础设施自动化 (CI/CD) │ │ 3. 去中心化数据管理 │ 8. 容错设计 (熔断/降级/重试) │ │ 4. 智能端点哑管道 │ 9. 演进式设计 │ │ 5. 产品化思维 (You build it, you run it) │ └─────────────────────────────────────────────────────┘必备基础设施组件常见方案职责服务注册与发现Consul / Eureka / Nacos / K8s DNS服务实例动态上下线感知API 网关Kong / Nginx / Spring Cloud Gateway统一入口、路由、认证、限流配置中心Apollo / Nacos / Consul KV配置集中管理与动态刷新负载均衡Ribbon / K8s Service / Envoy客户端/服务端负载均衡熔断降级Hystrix / Sentinel / Resilience4j防止级联故障链路追踪Jaeger / Zipkin / SkyWalking分布式调用链可视化日志收集ELK / Loki Grafana集中式日志跨服务排查问题监控告警Prometheus Grafana指标收集与告警优缺点优点缺点独立部署、独立演进各服务可独立发版、独立选择技术栈运维复杂度剧增几十上百个服务监控排错难度指数级上升故障隔离支付服务挂了不影响用户浏览商品分布式固有复杂度网络延迟、超时重试、数据一致性需全量处理团队自治小团队5~8 人全权负责自己的服务基础设施依赖重需注册中心、配置中心、网关等全家桶弹性伸缩按服务粒度扩缩热门服务多副本调试困难一个请求跨越 5~10 个服务定位问题需串联多节点日志技术异构不同服务可选用 Java/Go/Python/Node.js集成测试环境搭建复杂数据一致性从本地事务变为分布式事务服务间通信模式同步模式 异步模式 -------- -------- REST (HTTP/JSON) 消息队列 (RabbitMQ) gRPC (HTTP/2 Protobuf) 事件流 (Kafka) GraphQL 异步 HTTP (Webhook)适用场景团队规模 20 人按业务线分为多个小组业务模块间耦合度低各模块有独立的迭代节奏高并发系统需要按服务粒度弹性伸缩需要技术异构不同模块适合不同的技术栈容器编排架构特点维度说明容器化每个微服务打包为 Docker 镜像包含完整运行环境和依赖保证环境一致性调度与编排Kubernetes 负责容器调度、自动扩缩、滚动更新、自愈和服务发现声明式管理通过 YAML 声明期望状态副本数、资源限制、网络策略控制器自动调至期望状态弹性伸缩HPA水平 Pod 自动扩缩根据 CPU/内存/自定义指标自动增减 Pod 数量CI/CD代码提交 - 构建镜像 - 推送到镜像仓库 - K8s 滚动更新全流程自动化核心组件组件所属平面职责API ServerMaster集群统一入口所有操作需经过 API ServeretcdMaster分布式 KV 存储保存集群全部状态SchedulerMaster负责 Pod 调度决定 Pod 运行在哪个 Node 上Controller ManagerMaster运行各种控制器确保集群实际状态符合期望状态kubeletWorker节点代理管理本节点上的 Pod 和容器生命周期kube-proxyWorker网络代理维护节点上的网络规则实现 Service 负载均衡Container RuntimeWorker容器运行时containerd / CRI-O实际运行容器优缺点优点缺点环境一致性开发、测试、生产使用同一镜像学习曲线陡峭K8s 概念繁多团队培训成本高自动编排与自愈Pod 挂了自动重启节点宕机自动迁移资源开销K8s 集群本身占用可观资源弹性伸缩HPA/VPA 按负载自动增减实例排错门槛高问题可能出现在 Pod、网络策略、存储卷等任意层声明式 GitOpsYAML 描述期望状态Git 即单一事实来源版本升级风险K8s 版本迭代快API 弃用可能导致已有配置失效资源利用率高容器共享内核密度远超虚拟机网络和存储模型复杂需要专门的 CNI 和 CSI 插件适用场景微服务数量达到几十上百个手动运维不可行需要标准化交付流程保证多环境一致性追求极致资源利用率和弹性伸缩能力团队具备一定的云原生基础设施能力横向对比总结架构演进路线单机 ── 应用数据分离 ── 应用集群 ── 读写分离 ── 冷热分离 │ ▼ 垂直分库 ── 微服务 ── 容器编排架构选型决策矩阵简单 ────────────────────────── 复杂 快速交付 高扩展性 单机架构 ████████░░░░░░░░░░░░░░░░░░░ 初创/MVP/小团队 应用数据分离 ██████████░░░░░░░░░░░░░░░░░░ 单机资源瓶颈 应用集群 ████████████░░░░░░░░░░░░░░░░ 应用层高可用需求 读写分离 ████████████████░░░░░░░░░░░░ 读多写少/DB 读瓶颈 冷热分离 ██████████████████░░░░░░░░░░ 海量数据/存储成本 垂直分库 ████████████████████░░░░░░░░ 业务耦合/单库瓶颈 微服务 ████████████████████████░░░░ 大规模团队/独立迭代 容器编排 ████████████████████████████ 标准化交付/弹性伸缩各架构核心数据对比架构耦合度复杂度可扩展性性能运维成本团队规模核心瓶颈单机高低低最高最低1~5单点故障/资源上限应用数据分离中高低低高低5~10应用和 DB 各为单点应用集群中中中高中10~20数据库单点读写分离中中中高中高中10~30主库写入瓶颈/主从延迟冷热分离中中高中中中高10~30冷热路由/数据迁移垂直分库中低中高中高中高中高20~50跨库查询/分布式事务微服务低高高中高20服务治理/运维复杂度容器编排低最高最高中最高50K8s 本身的学习和维护架构演进阶段建议阶段一初创验证 (1~5 人) - 单机架构 - 目标快速验证业务活下来 阶段二初步增长 (5~15 人) - 应用数据分离 应用集群 - 目标解决单点、保证高可用 阶段三快速增长 (15~50 人) - 读写分离 冷热分离 垂直分库 - 目标解决数据库瓶颈、降低存储成本、业务解耦 阶段四规模化 (50 人) - 微服务 容器编排 - 目标团队自治、独立交付、弹性伸缩 核心原则架构演进应由业务量级驱动而非技术崇拜。 不要为了微服务而微服务避免过度设计。封面图自取