原文#
Data: 2026-05-25 00:15:45
1. 从单机架构开始#
互联网架构里那些高频名词，看起来眼花缭乱，概念扎堆，但如果拆开看，核心逻辑其实很简单：它就是一套不断补短板、解决新问题的演进过程。
故事的起点非常朴素。你刚做了一个小网站，用户没几个，访问量也很低。这时候怎么简单怎么来，一台服务器上装应用程序和数据库，用 LNMP、LAMP 这类常见 Web 技术栈就能迅速跑起来。你给它取名叫单机架构。
业务慢慢有了起色，用户多了一点，单机开始扛不住了。应用和数据库经常抢 CPU、内存、磁盘 IO，怎么办？很简单，加机器，把应用和数据库拆开。
应用服务器专门处理请求和业务逻辑，数据库服务器专门存数据、做查询和写入，两者各司其职，互不干扰，可用性也比原来更好。这一步，叫应用与数据库分离。
2. 集群、负载均衡与高可用#
好景不长，用户继续增长，单台应用服务器处理不过来了。假设一台机器每秒只能扛 100 个请求，现在来了 500 个请求，那就需要 5 台应用服务器，部署同一套代码一起扛。你给它取名叫集群。
但问题来了，流量怎么分配到每台服务器？于是你加了一个中间层，把请求尽量均匀地分配给后面的应用服务器，这叫负载均衡。
扛不住就加机器，这叫水平扩展。一台应用服务器挂了，负载均衡可以自动把流量摘掉，让其他机器顶上，系统不会因为某一台机器出问题就整体崩掉，这叫高可用。
到这里，应用层的压力被分摊了，但新问题也出现了：大量请求继续打到数据库，数据库成了新的瓶颈。
3. 多级缓存：先挡住热点查询#
你开始研究应用查询数据库的过程。应用发查询请求给数据库，数据库一般会先在内存里的缓冲区找数据；如果找到了，就直接返回；如果没找到，再去磁盘读取，读出来后放进缓冲区，再返回给应用。
你发现，从内存读数据比从磁盘读快得多，差距经常是几个数量级。那能不能都从内存读？不行，数据库自己的缓冲区容量有限，放不下所有数据。
于是你把“内存缓存”这件事单独做大：把经常访问的热点数据提前放到缓存里，用户请求先查缓存，查到了就不用访问数据库。你给它取名叫缓存。
常见缓存可以分三层：浏览器缓存、应用服务器本地缓存、分布式缓存。用户请求先看浏览器缓存，没有再看本地缓存，再看 Redis 这类分布式缓存，最后才访问数据库。
这时候，绝大多数热点读请求会在缓存层被拦住，数据库压力大幅下降。缓存放在内存中，响应速度通常能从毫秒级进一步压低；即使数据库短时间抖动，缓存也能顶住一部分读流量。
这里要注意，数据库缓冲区主要缓存数据页、索引页等数据库内部结构；而业务缓存更灵活，什么常用、什么耗时、什么能减少重复计算，就可以缓存什么。它可以缓存页面、接口结果、静态资源、计算结果，不只局限于数据库里的原始数据。
4. 读写分离：让数据库分工#
缓存解决了热点读，但写请求和非热点读还是会落到数据库。而数据库有个特点：写操作通常比读操作更重，因为它涉及事务、锁、日志和数据落盘，并发一高就容易排队。
那能不能让数据库也分工？于是你让主库主要负责写，从库主要负责读，通过主从复制把数据同步过去。你给它取名叫读写分离。
现实中的很多互联网系统都是读多写少，所以可以一主多从，把大量查询分摊到多个从库上，主库专心处理写入。这样一来，数据库读写互相影响的问题会明显缓解，整体吞吐能力也会提升。
但读写分离也不是万能的。主从同步存在延迟，所以刚写入的数据，马上去从库读，可能会读到旧值。真实系统里会根据业务重要性，决定哪些读走从库，哪些读必须走主库。
5. 分库分表：应对海量数据#
系统跑了几年，数据量越来越大，订单表、日志表、用户行为表不断膨胀，单库单表撑不住了，就必须拆数据库。
第一种拆法是按业务拆，比如用户库、商品库、订单库分开，互不干扰。你给它取名叫垂直分库。
第二种拆法是把一张大表拆成多张小表，比如按用户 ID 哈希分成多张表，把存储和查询压力摊开。你给它取名叫水平分表。
配合数据库中间件，应用层可以尽量少感知底层拆分细节。到这里，数据库从单点能力变成了可横向扩展的分布式存储体系，能继续承接更大的数据量和并发压力。
6. CDN 与反向代理：让访问更快，也更安全#
后来，用户遍布全国甚至全球，有人访问很快，有人访问慢得像绕了半个地球。与此同时，应用服务器直接暴露在公网，也更容易被攻击。
于是你加了两个关键组件。
第一个是 CDN。它在各地部署节点，把图片、视频、CSS、JS 等静态资源提前放到离用户更近的地方。用户访问时，通过 DNS 调度拿到附近节点的 IP，就像去家门口的快递站取件，不必每次都跑到中心机房。访问速度直接提升，源站压力也会下降。
第二个是反向代理。公网请求先到反向代理，再由它转发给内网应用服务器。它能隐藏真实服务器地址，也能做 HTTPS 终止、请求转发、权限校验、限流、WAF 防护等能力。常见的 Nginx、Apache、Envoy，都可以承担类似角色。
7. 搜索引擎与 NoSQL：解决复杂查询#
业务越来越复杂，传统关系型数据库也会遇到不擅长的场景。
比如电商搜商品、新闻搜标题、站内搜内容，如果只用数据库的 like 模糊查询，数据量一大就会很慢。于是你引入搜索引擎，用倒排索引把文本和关键词建立映射，让全文搜索可以快速响应。Elasticsearch、OpenSearch、Solr 都属于这一类。
再比如有些数据结构不固定，有些场景追求高并发读写，有些业务需要更灵活的扩展方式，于是你引入 NoSQL 数据库。MongoDB、Redis、Cassandra、HBase 等，都可以在不同场景下补足关系型数据库的短板。
到这里，系统不再只是简单的增删改查，而是开始支持复杂检索、灵活存储和高并发访问。
8. 从巨石应用到分布式架构#
接着，应用侧也出问题了。
你的网站从一个小电商，长成了集用户、商品、订单、支付、会员于一体的大平台。所有功能都挤在一个应用里，变成了大家常说的巨石应用。
巨石应用最大的问题不是不能用，而是越长越难改。改一行用户代码，要发布整个系统；多个团队同时开发，代码冲突不断；订单流量暴涨，想只给订单模块加机器，却只能把整个应用一起扩容，资源被大量浪费。
怎么办？继续拆。
你按照业务边界，把庞大的应用切开。用户相关功能做成用户系统，商品相关功能做成商品系统，订单相关功能做成订单系统。每个系统单独部署、单独发布、单独扩容，互相影响变小。你给它取名叫分布式架构。
但拆完之后，新问题又来了：用户下单时要查库存、生成订单、扣减优惠券，系统都分开了，彼此之间怎么调用？
于是你引入 RPC 远程调用，让跨机器的服务调用尽量像调用本地方法一样简单。服务多了之后，又需要一个“总管”记录所有服务地址：服务启动时来注册，调用方需要时来查询。你给它取名叫服务注册与发现中心。
9. 消息队列：解耦与削峰填谷#
分布式系统还有一个麻烦：服务之间互相调用、互相等待，一个服务卡住，整条链路都可能被拖慢。流量一高，还可能引发雪崩。
能不能减少服务之间的等待？于是你引入消息队列。
消息队列就像一个高可靠的收件箱。一个服务把消息投进去，就可以继续处理自己的事情；另一个服务稍后再取消息慢慢消费。这样，服务之间不必强绑定，也不必实时等待。
它带来的好处很明显：服务解耦、故障隔离、异步处理。某个服务短暂不可用，消息可以先堆在队列里，等它恢复后继续消费。遇到大促流量突增，也能先把请求存起来，再按照后端系统的处理能力慢慢消化。你给它取名叫削峰填谷。
10. 微服务：继续按业务能力拆细#
分布式架构用了几年，你发现拆是拆了，但还不够细。
就拿用户系统来说，里面可能同时装着登录、个人信息、会员、地址、风控等模块，依然是一个大桶。不同团队想用不同技术栈，有的想用 Java，有的想用 Go，也很难在一个系统里自由选择。会员模块流量暴涨时，还是要把整个用户系统一起扩容。
怎么办？继续拆。
按照“一个服务聚焦一类业务能力”的原则，把系统拆得更细：登录服务、会员服务、支付服务、地址服务，各自独立开发、独立发布、独立扩容。你给它取名叫微服务架构。
微服务的优势是灵活。大促来了，订单、支付这些高峰服务可以单独扩容十倍，其他不忙的服务不用动。某个服务出 bug，影响范围也更容易控制，不至于把整个网站拖垮。团队之间边界更清楚，开发效率也会提升。
但微服务不是免费的。服务一多，调用关系会变复杂，排查问题也会更难。于是你需要全链路追踪，定位每次请求卡在哪个服务；需要限流、熔断、降级，防止局部故障扩散；需要服务治理、统一监控、日志系统、权限体系，把运行状态管起来。
这些能力配齐后，系统才算进入比较完整的微服务体系。
11. 容器化、Kubernetes 与云原生#
微服务很好用，但运维压力会突然变大。
原来只有几个应用，现在可能变成几十个、几百个服务。每个服务上线都要配环境、装依赖、调参数。稍微不一致，就会出现“我电脑能跑，服务器跑不起来”的问题。大促前要紧急扩容，一台台配置机器根本来不及；大促后要缩容，又得一台台清理。
于是你想到：能不能把服务和它需要的运行环境一起打包，放到哪台服务器都能直接跑？这就是容器化。Docker 这类技术，把应用、依赖和运行环境封装在一起，减少环境差异带来的问题。
但几百上千个容器，谁来管理？于是 Kubernetes 出场了，也就是常说的 K8s。它负责容器编排、资源调度、自动扩缩容、故障自愈。流量高了自动加容器，流量低了自动缩容，容器挂了自动重启。
再往后，你发现即使有了 K8s，仍然要自己买服务器、规划容量、管理机房。大促前买一堆机器，平时又大量闲置。于是系统被搬到云平台上。
云平台像一个巨大的资源池，CPU、内存、存储、带宽都可以按需申请，用完释放，按量付费。配合容器化、自动化部署、弹性伸缩、可观测性和 DevOps 流程，系统就逐渐进入云原生时代。
12. 最后的架构主线#
回头看这条路，其实每一步都在解决一个真实问题。
单机架构，解决从零搭建；应用与数据库分离，解决资源争抢；应用集群加负载均衡，解决高并发；多级缓存，解决查询性能和数据库压力；读写分离，缓解数据库读写互相影响；分库分表，解决海量数据和单点瓶颈；CDN 加反向代理，解决访问速度和系统安全；搜索引擎加 NoSQL，解决复杂查询和特殊存储场景；业务拆分和分布式架构，解决业务膨胀和代码维护；微服务架构，解决团队协作与弹性扩容；容器化、Kubernetes 和云平台，解决部署运维成本与自动化问题。
所以，架构师真正要记住的不是名词，而是三句话。
第一，没有最好的架构，只有最适合业务阶段的架构。公司别一上来就微服务，单机够用就先单机，业务推着架构走。
第二，架构演进本质上是在用空间换时间，用复杂度换性能。加机器、加组件、加分层，都是为了扛住更大的流量、更高的并发和更复杂的业务。
第三，架构设计永远围绕几个核心目标：高性能、高可用、可伸缩、可扩展、够安全。
从一台小服务器，到能支撑千万级、亿级访问的现代化架构，每一步都有迹可循。它不是凭空堆技术名词，而是在业务增长中不断补短板、解决新问题。这就是互联网架构演进的底层逻辑。
13. 高频名词速查#
按正文中真正围绕互联网架构演进的名词统计，一共讲到 72 个。重复出现只算一次，普通产品举例不单独凑数，Docker、K8s 这类架构阶段核心工具保留，顺序按正文首次出现的时间线排列。
单机架构：一台机器跑完整系统（解决早期先跑起来的问题）
应用服务器：专门处理业务请求（解决业务逻辑没人处理）
数据库服务器：专门存储和查询数据（解决数据没地方可靠保存）
应用与数据库分离：应用和数据库拆开部署（解决机器资源互相抢）
集群：多台机器跑同一服务（解决单台机器扛不住）
负载均衡：把请求分给多台机器（解决流量都挤到一台）
水平扩展：靠加机器提升承载力（解决性能上限太死）
高可用：局部故障不拖垮系统（解决一台坏了全站挂）
缓存：把常用数据放近处（解决每次都查库太慢）
热点数据：被频繁访问的数据（解决优先缓存谁的问题）
多级缓存：多层缓存逐级拦请求（解决单层缓存压力大）
浏览器缓存：用户浏览器里的缓存（解决静态内容反复下载）
本地缓存：应用机器内的缓存（解决近距离重复查询）
分布式缓存：多机器共享缓存服务（解决本地缓存不够用）
业务缓存：按业务结果缓存内容（解决重复计算太浪费）
读写分离：写走主库读走从库（解决读写互相堵）
主库：主要负责写入的数据库（解决写入入口混乱）
从库：主要负责读取的数据库（解决读请求压垮主库）
主从复制：主库数据同步到从库（解决读库没数据）
主从延迟：从库数据落后主库（提醒刚写完别乱读）
分库分表：拆库拆表分散压力（解决单库单表太大）
垂直分库：按业务模块拆数据库（解决不同业务互相拖累）
水平分表：按规则拆同一张表（解决一张表越来越胖）
数据库中间件：屏蔽拆库拆表细节（解决应用改造太重）
分布式存储：多节点共同存储数据（解决单点存储上限）
CDN：就近分发静态资源（解决用户离机房太远）
DNS 调度：用域名选择合适节点（解决用户该去哪个节点）
源站：原始内容所在服务器（解决内容原件放在哪）
反向代理：替后端接收公网请求（解决后端直接暴露）
HTTPS 终止：代理层处理加密连接（解决后端重复解密负担）
权限校验：判断请求是否有资格（解决谁都能访问）
限流：限制过高访问流量（解决流量突然冲垮系统）
WAF：Web 应用防火墙（解决常见 Web 攻击）
关系型数据库：用表和关系组织数据（解决结构化数据管理）
搜索引擎：专门处理搜索检索（解决数据库搜索太慢）
倒排索引：词到文档的反向映射（解决文本检索没方向）
全文搜索：在大量文本里搜内容（解决关键词查找困难）
NoSQL 数据库：非关系型数据存储（解决数据结构不固定）
高并发读写：大量请求同时读写（提醒系统压力来源）
复杂检索：多条件复杂查找数据（解决简单查询不够用）
灵活存储：适配不固定数据结构（解决表结构改动频繁）
巨石应用：所有功能挤在一个应用（提醒系统越长越难改）
业务边界：业务模块之间的分界（解决拆系统按什么拆）
分布式架构：多个系统协作完成业务（解决巨石应用太臃肿）
RPC 远程调用：像本地方法一样调远端（解决服务拆开后咋通信）
服务注册与发现中心：记录和查找服务地址（解决服务地址不好找）
分布式系统：多节点协同运行的系统（解决单系统能力有限）
雪崩：局部故障连锁放大（提醒故障会一路传）
消息队列：异步传递消息的中间件（解决服务互相等）
服务解耦：减少服务之间强依赖（解决谁挂了都互相拖）
故障隔离：控制故障影响范围（解决小故障变大事故）
异步处理：不等结果先继续执行（解决同步等待太慢）
削峰填谷：把峰值流量排队消化（解决大促瞬间冲击）
微服务架构：按小业务能力拆服务（解决系统拆得还不细）
全链路追踪：追踪一次请求完整路径（解决出问题找不到点）
熔断：故障时主动停止调用（解决坏服务继续拖人）
降级：异常时返回简化能力（解决系统忙时必须保命）
服务治理：管理服务运行和调用（解决服务多了失控）
统一监控：集中观察系统状态（解决哪里出事看不见）
日志系统：集中记录运行日志（解决问题发生没证据）
权限体系：统一管理访问权限（解决权限散乱难管）
容器化：应用和环境一起打包（解决环境不一致）
Docker：常用容器构建运行工具（解决服务打包运行）
Kubernetes/K8s：管理容器集群的平台（解决容器太多没人管）
容器编排：自动安排容器运行位置（解决容器放哪台机器）
资源调度：分配机器资源给服务（解决资源分配靠人工）
自动扩缩容：按负载自动加减实例（解决扩容缩容太慢）
故障自愈：异常后自动恢复服务（解决服务挂了没人拉）
云平台：按需使用计算资源（解决自己买机器太重）
资源池：可随时申请释放资源（解决资源闲置浪费）
可观测性：让系统状态可被看见（解决线上黑盒运行）
云原生：面向云的架构方法（解决弹性自动化不够）