互联网架构演进：从单机到云原生，一篇讲清楚

这篇文章基于视频《互联网架构就这？1个故事讲清楚》整理，并加入了一些工程化解释。它不是逐字稿，而是把视频里最有价值的那条线拎出来：架构不是一开始设计出来的，而是业务规模一步步逼出来的。

很多人学架构时会被一堆名词砸晕：负载均衡、读写分离、缓存、分库分表、RPC、注册中心、消息队列、微服务、Kubernetes……如果只背概念，很容易知道“有什么”，却不知道“为什么会出现”。

更好的理解方式是：把一个网站想象成从 0 开始长大。每次流量变大、数据变多、团队变大，原来的方案就会暴露一个瓶颈。于是架构升级一步，解决一个主要矛盾，同时引入新的复杂度。

核心脉络

架构演进最重要的不是“用了多少技术”，而是每一步都要回答三个问题：

单机时代的价值是快。一个小网站、一个后台系统、一个 MVP，最开始完全可以用一台机器跑应用和数据库。这个阶段追求的是低成本验证，而不是提前把 Kubernetes、服务网格、消息队列全搬进来。能用简单方案解决的问题，就不要过早分布式。

当流量变大，最先撞到的是资源竞争：应用在吃 CPU 和内存，数据库在吃磁盘 I/O 和缓存，两者混在一台机器上互相拖累。把应用和数据库拆到不同机器，是第一次非常自然的升级。

接下来，应用层通常比数据库层更容易横向扩容。多加几台应用服务器，再用 Nginx 或 HAProxy 做负载均衡，请求就能被分摊出去。这里会遇到第一个“分布式味道”的问题：用户 Session 不能只放在某台应用机器上，否则用户下一次请求被转发到另一台机器时就可能丢状态。

读流量继续增长后，数据库会成为核心瓶颈。多数互联网业务是读多写少，比如浏览商品、看文章、查资料、刷列表。于是主库负责写，从库负责读，读请求可以横向扩展。但这也意味着主从复制存在延迟：刚写完的数据，马上读从库时可能还没同步过去。

缓存是下一次大提速。浏览器缓存减少重复下载，CDN 把静态资源放到离用户更近的边缘节点，本地缓存减少进程外调用，Redis 这类分布式缓存挡住大部分热点读请求。缓存的本质是用空间换时间，但它不是免费午餐：缓存失效、脏数据、热点 Key、穿透和雪崩都需要设计。

数据层怎么长大

数据库的演进可以单独看成一条线：从一台主库，到主从复制，再到分片，再到多种存储协作。

分库分表不是“数据库优化的高级形态”，而是单库单表确实扛不住后的手段。它能把数据分散出去，也会带来跨库 Join 难、跨分片事务难、分页统计难、扩容迁移难等问题。

一个比较稳妥的经验是：先优化索引、SQL、缓存和读写分离；只有当数据量、写入量或单表维护成本真的压上来，再进入分库分表。架构升级要被证据推动，而不是被焦虑推动。

从单体到服务化

当系统功能越来越多，单体应用会从“简单”慢慢变成“沉重”。所有模块共用一套代码、一套数据库、一条发布流水线，一个小功能也要跟整个系统一起上线。团队变大后，代码冲突、发布排队、故障影响面都会变得很难受。

服务化的第一步是按业务边界拆开：用户服务、商品服务、订单服务、支付服务、库存服务、推荐服务。拆开之后，每个服务可以独立开发、独立部署、独立扩容。

但服务拆开后，新的问题马上出现：

消息队列是服务化里非常关键的一块。它把同步调用变成异步事件，让订单创建、库存扣减、积分发放、短信通知、搜索索引更新等动作不必全部堵在一个请求里完成。代价是系统从“立即一致”变成“最终一致”，业务上要能接受中间状态。

微服务不是单体的反面，也不是架构的终点。它适合业务边界稳定、团队规模较大、部署节奏不同、局部扩容需求明显的系统。如果项目还小，团队也小，强行微服务反而会把工程复杂度提前引爆。

云原生解决的是交付问题

当服务数量来到几十、上百个，真正痛苦的往往不只是代码，而是交付和运维：环境不一致、发布步骤多、机器资源浪费、扩容靠人工、故障恢复慢。

Docker 先把应用和依赖打成标准镜像，解决“在我机器上能跑”的问题。Kubernetes 再把镜像调度到集群里，通过声明式配置维持期望状态：副本少了就补，节点挂了就迁，版本升级按策略滚动。

这时架构的关注点从“单个服务怎么写”扩展到“整个平台怎么运行”：

云原生并不是“把应用放进容器”这么简单。它更像是一套围绕自动化交付、弹性扩缩容和故障自愈建立起来的平台能力。

常见误区

最后可以用一张“什么时候升级”的表来压轴：

总结

互联网架构演进不是一条炫技路线，而是一条不断处理主要矛盾的路线：

1
2
3
4
5
6

先跑起来
  -> 扛住更多请求
  -> 保护数据库
  -> 拆开数据与业务边界
  -> 让服务独立交付
  -> 让平台自动化运行

如果只记一句话：架构升级的本质，是在业务增长带来的新瓶颈面前，用可接受的复杂度换取性能、可用性、可扩展性和交付效率。

真正好的架构师，不是把所有热门技术都塞进系统里，而是知道此刻最应该解决哪个问题，也知道每个方案会带来什么代价。

参考资料

• 原视频：互联网架构就这？1个故事讲清楚
• 辅助整理：互联网架构演进精读：从单机到云原生
• B 站视频嵌入使用本站已有 bilibili shortcode；本文配图为基于内容重新绘制的本地 SVG。