全篇为从单机架构到负载均衡的互联网架构演进。从单机架构程序与数据库部署在同一服务器开始指出随着用户增长会出现资源竞争。解决方案是将应用与数据库拆分到不同服务器。当单台应用服务器无法承受流量时引入负载均衡服务器如 Nginx将请求平均分发给多台应用服务器实现水平扩展。初期单机架构如下图流量比较小此时把应用程序与数据库都部署到同一台服务器上。随着用户量上升应用程序和数据库开始争夺 CPU、I/O 和内存资源CPU 和内存被两边抢来抢去导致整体卡顿。物理分开应用服务器和数据库服务器是分布式架构的初期阶段。如何解决这一问题把它们拆开物理分离。分成应用服务器和数据库服务器。应用服务器专职处理 HTTP 请求、执行业务逻辑比如计算价格、校验权限。数据库服务器专职负责磁盘 I/O读写数据、执行 SQL 查询。从单台应用服务器扩展到应用集群QA为什么要集群单台服务器性能有物理上限CPU、内存、网络带宽当每秒请求数QPS超过单机承载极限时只能加机器——这就是横向扩展Scale Out。集群解决了什么问题高可用一台机器宕机其他机器还能继续服务不会全站瘫痪。高并发5 台机器一起扛流量总处理能力翻 5 倍理想情况。没有负载均衡器时虽然有多台服务器但用户不知道访问哪台只能靠 DNS 轮询粗糙且无法屏蔽故障。如何解决呢在所有应用服务器前面架设了一个负载均衡器Load Balancer例如 Nginx、HAProxy 或云上的 SLB。其中负载均衡有两个主要作用流量分发确保每台应用服务器收到的请求数量大致相等。这样加机器即水平扩展才能真正转化为处理能力的线性提升。故障自愈它会持续检查后面的应用服务器是否存活。如果某台服务器宕机负载均衡器会立即将其踢出集群不再分发请求。用户完全感知不到后端有机器坏了——这就是高可用。那数据库慢了怎么办——用空间内存换时间速度应用集群能扛住海量请求但所有请求最终都要去查数据库。数据库的数据在磁盘上磁盘 I/O 是机械运动速度比内存慢千倍以上。既然数据库慢是因为要读磁盘那就在应用和数据库之间加一道内存墙缓存。绝大多数读请求直接从内存返回根本不用经过数据库。但是又出现了新问题缓冲区容量有限无法容纳全部的数据。所以要采用多级缓存方式。部署到 Redis 上当前查询所需时间从 ms 级降低到 ns 级。引入 Redis 缓存挡住了 80% 的读请求但又遇到了新的问题写入操作增、删、改以及缓存未命中的读取依然要穿透到数据库。随着业务量增大数据库的磁盘 I/O 和锁冲突会越来越严重。那么针对写操作慢和锁竞争问题对应的解决方案是读写分离主从复制主库负责写从库负责读通过数据同步保持一致性。为解决单表数据量过大如超 1000 万行的问题需要进行分库分表。垂直分库按业务领域如用户、商品、订单拆分水平分表则将一张大表按一致性哈希算法拆成多张小表配合数据库中间件使用。垂直分库在这张图之前虽然有主从库但用户表、商品表、订单表全都挤在同一个物理数据库里。痛点所有业务的数据挤在一起某个业务比如订单突发大查询会拖垮整个数据库的CPU和I/O导致用户登录查用户表都变慢。一个业务生病全家跟着吃药。解法按业务领域用户、商品、订单将数据库拆分成独立的数据库实例。每个数据库都有自己的专属主库和从库。效果资源隔离独立扩展。引入CDN、反向代理与搜索引擎Elasticsearch/MongoDB支持几十万并发的其他架构组件CDN用于将静态资源缓存到离用户最近的节点反向代理Nginx用于隐藏真实服务器、抵御攻击。同时为应对模糊查询、全文检索等需求需引入搜索引擎如Elasticsearch和NoSQL数据库如MongoDB以支持非结构化数据。但是将所有代码集中在一个巨型工程巨石应用会导致维护困难。解决方案按业务边界拆分成独立的子系统如用户、订单、商品集群形成分布式架构。进一步地为追求极致灵活性可按单一职责将子系统继续拆分为更细的微服务如登录、会员、支付服务每个微服务可独立开发、部署和扩容。以前单体/分层架构所有代码用户、商品、订单打包在一个大工程里。改一行订单代码整个项目要重新编译、测试、部署。现在微服务拆分每个业务用户、商品、订单是一个独立的项目、独立的进程、独立部署。每个服务拥有自己独立的数据库对应你之前做的垂直分库。拆分微服务后用户服务要查订单数据就不能直接调方法了因为不在同一个进程里。跨系统调用可通过RPC实现。RPC如 Dubbo/gRPC性能更高像调本地方法一样调远程服务二进制传输序列化更快。以前用 Nginx 做负载均衡IP 是写死在配置文件里的。但在微服务中服务实例随时会变扩容、缩容、宕机重启IP 是动态变化的。为管理大量服务需要服务注册与发现中心如Zookeeper和消息队列如Kafka来实现异步通信、系统解耦和削峰填谷。微服务架构还需引入全链路追踪、限流熔断降级等机制。为简化部署使用Docker将应用与环境一起打包并用Kubernetesk8s管理Docker容器。最后进行总结阶段核心动作解决什么问题学术化表述1. 单机应用数据库在一起快速验证与低成本启动最小化初期基础设施投入降低部署复杂度缩短产品上市周期。2. 分离应用和数据库拆分消除资源竞用与提升隔离性通过物理/逻辑隔离避免应用逻辑与数据存储争抢CPU、内存及I/O资源保障系统整体吞吐量与稳定性。3. 应用集群加多台应用 Nginx引入负载均衡与水平扩展机制通过横向扩容分摊请求压力突破单机处理上限同时实现故障自动剔除提升系统可用性HA。4. 缓存引入 Redis构建多级缓存体系降低数据库读压力利用内存介质的高速读写特性将热点数据前置缓存显著降低数据库I/O频次与响应延迟RT。5. 读写分离主从复制实现读写流量隔离与锁竞争消解通过主从复制架构将查询请求分流至从库消除读写操作间的锁争用提升数据库并行处理能力。6. 垂直分库按业务拆库用户/商品/订单面向领域的数据物理隔离与故障隔离按业务边界拆分数据存储避免跨业务资源争抢实现故障域的隔离并为后续服务化拆分奠定数据基础。7. 水平分表数据散落到多张表突破单表数据量上限缓解索引层级退化通过分片策略将数据打散至多张物理表降低B树索引深度保障数据写入与查询的线性扩展能力。8. 多引擎引入 ES、MongoDB多模数据存储与专业化查询引擎适配针对全文检索、半结构化数据、多维分析等场景引入专用存储引擎弥补传统关系型数据库在非结构化场景下的能力短板。9. 微服务拆应用 RPC MQ K8s实现组织架构与技术架构的对齐康威定律通过服务化拆分降低系统耦合度引入异步通信与容器编排实现弹性伸缩与故障自愈支撑大规模协同开发与持续交付CI/CD。写入与查询的线性扩展能力。8. 多引擎引入 ES、MongoDB多模数据存储与专业化查询引擎适配针对全文检索、半结构化数据、多维分析等场景引入专用存储引擎弥补传统关系型数据库在非结构化场景下的能力短板。9. 微服务拆应用 RPC MQ K8s实现组织架构与技术架构的对齐康威定律通过服务化拆分降低系统耦合度引入异步通信与容器编排实现弹性伸缩与故障自愈支撑大规模协同开发与持续交付CI/CD。