VibeCoding时代：从单体到微服务的7个架构演进阶段

1. VibeCoding写了那么多代码，系统为什么还是乱

最近一个月，我身边又多了几位开始用VibeCoding方式干活的朋友——对，就是那种对着AI说自然语言需求，让它生成代码，自己再做review、调试、整合的工作流。大家普遍的感觉是"新功能写起来特别爽，但过了两三个礼拜回头看项目，心态容易崩"。

这个"崩"不是代码变量命名不清晰、注释不够这种层面的问题，而是系统层面的症状开始冒出来了：

• 改一个接口，三个服务跟着一起报错
• 一个模块里堆了十几种职责，没人敢轻易动
• 数据库表越建越多，字段含义全靠猜
• 想加个新功能，完全不知道应该塞进哪个位置

这些症状背后藏着一件事：代码是AI生成出来的，架构却是"长"出来的。VibeCoding可以把单个零件的生产效率拉到极高，但它没法替你想清楚"这些零件要怎么组装成一个能持续长到很大、还能长期维护的系统"。

我一直在用一个类比来跟团队解释这件事：软件系统就像一座城市，VibeCoding是快速盖房子的机器，而软件架构是城市规划。你不可能指着一间单间工作室说"这里要装下一百万人口"，但很多人在代码世界里真就是这么干的。

这篇文章想用一条从「单间工作室」到「全球城市」的演进路线，把系统扩展拆成7个软件架构阶段。每个阶段对应一类建筑形态、一类软件架构手段、一组核心矛盾。对VibeCoding小白来说，这张路线图能帮你回答一个关键问题：系统写到什么程度，就该停下来做一次架构动作了。

如果你正在用AI辅助写真实业务系统，不管你是后端、前端还是全栈，这条路线都适用。它不是"必须一步一步走到头"的强制清单，而是一张能随时定位自己的地图。

2. 先把地图铺开：7个阶段各自在解决什么问题

聊具体阶段之前，我建议先把全貌放在面前。下面这张表是我平时给项目做"架构体检"时用的速查表，你可以直接保存：

注意一个关键点：这7个阶段的难度不是均匀分布的。前两个阶段属于"代码组织问题"，靠抽象、分层、模块边界就能解决；第3、4个阶段进入"系统拆分与通信问题"，开始引入分布式带来的全新复杂度；第5个阶段是"基础设施标准化问题"，需要运维与开发协作；第6、7个阶段则是"全球规模与自动化运营问题"，大多数人短时间内用不上，但提前知道桥在哪，就不会在错误的路口浪费一年。

对VibeCoding场景来说，阶段1到4离每个人都很近。AI能帮你生成单体、帮你拆模块、帮你写微服务模板，甚至能帮你补API网关配置。但第3阶段之后，AI生成得越快，你越需要判断"该不该拆、往哪拆"——这个判断能力，恰好是小白最容易缺失的。

下面我挨个阶段展开讲，每段都会结合VibeCoding的实际使用场景，把"为什么"说透。

3. 阶段1和2：先活下来，再给屋子分好房间

3.1 单间工作室：一个进程跑完所有事情

阶段1的本质，是所有真实业务系统的起点：一个应用、一个进程、一个数据库，所有代码放在同一个代码库里。它就像一间单间工作室——一张桌子、一个水壶、一台电脑，一个人要喝水、要写稿、要吃饭都在这个空间里解决。

为什么大多数VibeCoding项目的起点天然是单体？因为你向AI描述需求时，默认输入就是一个"完整应用"的概念："给我做一个带登录的商品列表系统""帮我写一个支持订单和支付的REST API"。AI会在一个项目结构里把所有内容生成出来，Controller层、Service层、DAO层、数据表初始化脚本，全都在。这是巨大的效率优势，没有任何问题。

单体应用不是贬义词。它是最小可行系统的正常形态，能让你在需求还没被验证之前，以最低成本把想法跑起来。VibeCoding在这里的优势是碾压级的：以前三天写完的MVP，现在一个下午加一个晚上，基本就能端到端跑通。

但这个阶段埋着两个雷：

第一，代码边界不清。AI生成代码时，会按照你最近那句prompt的上下文来决定往哪里加功能。今天说"加一个优惠券逻辑"，它可能塞进OrderService里；明天说"加一个折扣计算"，它又塞进ProductService里。两三个功能下来，折扣相关的代码分散在三个地方，互相调用，勉强能跑，全是隐患。

第二，没人负责演进规划。人类程序员的优势在于写代码时会不自觉地考虑"这个类后面会不会被复用""这个逻辑是不是应该抽出来"，AI默认不做这种预判，除非你在prompt里反复强调。于是代码量快速增长，结构却原地踏步。

所以我的建议是：阶段1可以放开了用VibeCoding，但一定要加一个观察指标——平均改一个功能要动几个文件。如果这个数字在持续上涨，比如从2涨到5、再涨到8，说明你该进入阶段2了。

3.2 独立房屋：用模块化给系统分房间

阶段2对应的架构形态是模块化单体（Modular Monolith），也常表现为分层架构。它不再是单间工作室，而是变成了一套有两室一厅的房子：厨房只负责做饭，卧室只负责睡觉，客厅只负责待客。墙面就是模块边界，门就是模块间的接口。

模块化改造的核心不是"把所有代码按目录重新摆一遍"，而是用依赖方向约束演进。什么意思？就是说你要明确一个规则：Web层只依赖Service层，Service层只依赖DAO层，任何反向依赖都不允许。这样改代码时，你只需要关心"我这个功能应该落在哪个层、影响哪几个模块"，而不是"全项目里有没有其他地方也被我不小心影响到了"。

这件事VibeCoding能不能帮忙？能，但你要用对姿势。我推荐的方式是：先让AI做一次"架构梳理"，而不是让它直接改代码。你可以这样写prompt：

code复制你是高级软件架构师。请分析下面这个项目的目录结构和关键类依赖关系，
输出一份模块划分建议：每个模块应该包含哪些包/类，模块之间的依赖方向是什么。
先不要写代码，我只想看到清晰的模块边界图。

实测下来，AI对这个任务的完成度很高。它能把散落的类按业务语义聚合成模块，也能指出"当前A模块直接依赖了C模块的内部类，这种跨边界调用是危险的"。

拿到模块划分方案后，再逐个让AI把类移动到对应模块，并把跨模块的直接调用改成接口调用。这个过程中你只需要盯住一条原则：移动代码时，依赖方向不能反。一旦AI开始出现"为了让Service不依赖DAO，直接把DAO嵌入Service"这种操作，你必须马上喊停。

阶段2的VibeCoding效率依然很高，因为AI擅长在明确边界内填充代码。只要你把"边界是什么"告诉它，它能帮你写出非常规范的模块实现。成长到独立房屋形态之后，你的系统在很长一段时间内都能保持较好的可维护性。不要急着拆微服务，很多项目其实根本没有跨越阶段2的必要。

4. 阶段3和4：拆分的自由，以及通信的新麻烦

4.1 从一栋房到一片社区：微服务化到底为了什么

先泼一盆冷水：VibeCoding不是做微服务化的理由。AI能轻易生成一个微服务项目模板，但能不能运维好两个独立服务，取决于你的基础设施能力和团队协作方式。如果只是因为"微服务听起来更高级"而拆分，你会在阶段4付出惨痛代价。

那什么情况下才真的应该拆？我总结出三个信号，至少满足两个再动手：

• 团队人数：团队超过10人，且每人每天都要在同一份代码库里合并代码，合并冲突消耗的精力已经超过代码本身的价值。
• 业务生命周期差：某个模块的发布频率和主应用差异巨大，比如用户服务每周发两次，而购物车模块一个月才发一次。这种差异会让单体里的变更互相拖累。
• 独立扩展需求：某个模块的资源消耗曲线和其他模块完全不同，比如图片处理服务在活动时段CPU会冲到100%，但它所在的单体应用没法只给它单独扩容。

拆分的本质，是通过"物理边界"把自治权交给每个服务团队。每个服务独立部署、独立发布、独立故障域。这就像从一栋房子搬进一片社区：每家单独入户，水管、电路独立，你家跳闸不会影响邻居。

但社区也有社区的问题，最大的问题是：社区之间没有路，推个垃圾都得自己过草地。 服务拆出来之后，你立刻撞上通信问题：

• 服务A怎么知道服务B的地址？
• 调用服务B时，鉴权、限流、日志这些横切逻辑谁来统一处理？
• 订单服务挂了，通知服务要不要一直重试，还是先把消息丢进队列？
• 两个服务都在改同一个业务对象，数据一致性怎么保证？

这些问题就是阶段4要解决的。

4.2 修路、建公交、设红绿灯：网关、注册中心与消息队列

把阶段4理解成"给社区修基础设施"，你会轻松很多：

• API网关（Gateway）：相当于城市主入口的收费站加红绿灯。所有外部流量先进网关，统一做鉴权、限流、路由转发。内部服务不直接暴露给外部，安全性和治理都集中在一个口。
• 注册中心（Service Registry）：相当于城市黄页。每个服务启动时到注册中心登记自己的地址，调用方通过注册中心查"服务B现在在哪"，而不是自己在配置文件里硬编码地址。
• 消息队列（Message Queue）：相当于城市货运专用道。适合不要求实时响应的通信，比如订单创建后，需要发邮件、发短信、更新积分，这些操作全部丢进队列，消费者慢慢处理，互不阻塞。

实操层面，我给中小项目一个清晰的落地顺序：

1. 先上API网关。你不需要自研，直接用开源的APISIX、Kong，或者云厂商的API网关产品。把服务间的外部入口统一管起来。
2. 对非实时链路引入消息队列。找一个高频但允许延迟的场景练手，典型例子是"用户注册后发送欢迎通知"。用RabbitMQ或Kafka都能练。
3. 在网关后面接注册中心，让服务之间的调用地址动态化。

VibeCoding在阶段4能做很多力气活：让AI根据你的OpenAPI规范生成网关路由配置；让AI写一个消息队列的消费者组件，再给你一份模拟消息的测试脚本；让AI帮你把服务间的HTTP调用从硬编码URL改成通过注册中心发现。这些都是有明确输入输出、有标准答案模板的任务，AI做得又快又好。

但有一条线必须划清楚：分布式事务不是VibeCoding能替你决定的。

当订单服务和库存服务分属两个数据库，一个下单操作跨了两个服务，如果库存扣减失败，订单怎么办？初学者很容易在这时候对AI说"帮我实现分布式事务"。AI会给你搬出一套Saga，或者两阶段提交，看起来严谨，实际落地时你大概率会踩到大量边界问题。我的建议是更朴素的做法：尽量让一个业务链路待在一个服务的数据库事务里。如果非要跨服务，优先考虑事件驱动异步补偿，而不是同步强一致。记住一条经验：分布式一致性方案每复杂一级，运维成本不是线性增加，是指数增加。

5. 阶段5和6：城市公共设施，以及通向世界的路

5.1 容器化与K8s：从私搭管线到市政水电

你可能会想，前面几个阶段我已经够忙了，第5阶段的容器化是不是可以缓一缓？我的看法是，哪怕你的系统只有两个服务，我也建议至少把Docker做起来。因为容器化解决的是一个非常朴素的问题：环境一致性。

"在我电脑上是好的"这句话，已经毁掉了无数个上线之夜。容器把代码、运行时、依赖配置一起打包成标准镜像，像集装箱一样，不管运到哪一艘货轮上，都能原样运行。这就是为什么我把Docker比作集装箱：它让"运输"和"装卸"变得标准化。

而Kubernetes（K8s）是更上一层的调度系统，相当于港口的自动化调度中心。你告诉它"我要跑3个订单服务实例，每个实例需要2核CPU、4G内存"，它自动帮你分配机器、拉起Pod、健康检查、失败重启。在容器化之前，服务部署是"人肉搬砖"；有了K8s之后，是"城市市政系统自动供水供电"。

对VibeCoding用户来说，这里有个好消息：Dockerfile和K8s的YAML配置非常适合让AI来写，因为这些文件是标准化的、结构化的、有大量公开实践模板。你只需要描述技术栈和端口，AI就能产出一份可用的配置。

但你要知道哪些字段是生产环境绝对不能省的。以一份最小Deployment为例：

yaml复制apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service
  template:
    metadata:
      labels:
        app: order-service
    spec:
      containers:
        - name: order-service
          image: registry.example.com/order-service:v1.2.3
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: 250m
              memory: 512Mi
            limits:
              cpu: "1"
              memory: 1Gi
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 15
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            initialDelaySeconds: 5
            periodSeconds: 5

这里三个关键点：resources（资源请求与上限）让调度器能合理分配机器；livenessProbe（存活探针）决定容器死了要不要重启；readinessProbe（就绪探针）决定流量要不要打进来。这三个字段缺任何一个，"能跑"和"能扛流量"就是两回事。AI生成YAML时大概率会带模板，但你是不是能看懂、能调参，决定了线上稳定性。

5.2 面向全球：CDN与多区域部署

如果你的用户开始跨越国界分布，你就会遇到新问题：服务器在北京，洛杉矶的用户访问一次要绕地球大半圈，延迟高到想骂人。

这个阶段我把它比作"从一座城市发展到全球城市群"。解决方案分三层：

• CDN（内容分发网络）：把静态资源（图片、脚本、样式表）缓存到离用户最近的边缘节点。用户访问的是就近节点，回源到中心的频率大大降低。这是成本最低、收益最明显的全球化手段。
• 多区域部署：在主要用户区域各部署一套完整服务，通过全局负载均衡把请求导向最近的数据中心。这里的关键问题是数据库同步——你可以做主从复制、多主复制，但数据一致性成本会直线上升。不同区域看到的数据版本能不能不一致？如果用户在A区域下单，B区域能不能立刻看到？需要你明确RPO（数据可丢失的时间窗口）和RTO（恢复目标）。
• 容灾设计：一个区域挂了，流量自动切换到另一个区域。听起来很顺滑，现实里大量业务在切换后发现"数据都没同步完，用户状态全丢了"。所以容灾不是架构图上的箭头，是要长期演练的工程能力。

这个阶段AI能做什么？它可以帮助你分析访问日志、推荐区域部署策略、生成Terraform这类基础设施即代码配置。但"主库应该放哪个区域""数据一致性允许的延迟是多少秒"这种决策，本质是业务取舍，AI替代不了你。

6. 阶段7：智慧城市，系统自己照顾自己

6.1 自动伸缩与自愈：从人工守夜到智能调度

很多系统开发到阶段6，已经拥有相当复杂的分布式架构。这时运维压力会反噬回来——不是因为功能不够多，而是因为"照顾系统"这件事本身变成了一份全职工作。阶段7的思路是：让系统尽可能地自己照顾自己。

自动伸缩的落地形态是HPA（Horizontal Pod Autoscaler）。它像一个智能交通信号系统，根据路口实时车流量自动调整红绿灯时长。你只需要定义触发规则：

yaml复制apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: order-service-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: order-service
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 70

这条配置的意思是：当订单服务实例的CPU平均利用率超过70%，HPA就自动扩展Pod，最多到10个副本；低于阈值一段时间后自动缩回，最少2个。这就是"城市根据早晚高峰自动调度公交班次"。

自愈机制则是另外一套保障：K8s的存活探针发现容器僵死时自动重启，就绪探针发现服务还没准备好时自动摘除流量，网络层有重试与超时，服务层有熔断与降级。当这些机制齐全，一台物理机宕机对用户来说只是毫秒级的抖动，而不是一次事故。

VibeCoding在自动伸缩配置上的角色与YAML相同：可以生成配置，但你必须理解每个指标的含义。我见过有人直接把CPU阈值设成5%，导致系统频繁扩缩容，运维成本更高。调参这事，AI给不了你，只能靠自己观察业务峰值曲线。

6.2 Serverless：从买办公楼到按需用水电

Serverless（无服务器架构）是阶段7的另一个重要形态。用城市类比的话，它像市政水电：你不用自己建水厂和发电厂，按需用水用电，按用量付费。

具体到技术层面，你可以把某个"事件型"业务函数部署到函数计算平台，比如对象存储里上传了一个文件，自动触发函数做压缩/转码；或者商品库存低于阈值时，自动触发函数给采购组发通知。函数按调用次数计费，空闲时一分钱不花，高峰期也能自动容纳海量并发。

对VibeCoding来说，Serverless函数是AI的最佳用武之地——因为函数的边界小、职责单一，AI相当擅长生成"输入事件、处理逻辑、返回结果"这种独立单元，而且函数级代码容易测试，不像微服务那样牵一发动全身。

但Serverless也不是银弹。冷启动延迟、服务商锁定、调试链路不直观，都是实实在在的代价。我认为比较稳的策略是：把系统里"低频突发型"的旁路功能交给Serverless，核心业务链路由阶段5的K8s扛着。两条腿走路，既稳健又省钱。

6.3 可观测性：一座没有灯的城市，没法运营

阶段7还有一个不能缺席的基建，就是可观测性。我常跟团队说：没有日志、指标、追踪，你就是一个在黑暗里开车的司机——车况全靠猜。

可观测性的三个支柱，一个都不能偏：

• 日志（Logs）：记录具体事件，回答"到底发生了什么"。
• 指标（Metrics）：聚合数值数据，回答"系统现在健康吗"。
• 分布式追踪（Traces）：串联一次请求经过的所有服务，回答"慢在哪里"。

实操上，给微服务系统接OpenTelemetry是目前最标准的做法：在服务里埋点生成trace，导出到Jaeger或Grafana Tempo，然后在Grafana统一看链路。VibeCoding可以帮你快速生成埋点代码、日志格式规范、甚至Grafana Dashboard的JSON配置。但"哪些业务路径需要埋点"这件事，需要你对业务价值有判断力——把关键交易链路埋明白，远胜过全系统无差别埋点。

7. VibeCoding小白的架构修炼路线图

最后给一套可以直接照着练的路线图。我把它设计成"每个阶段做一次小练习"，练完就能在真实项目里升级一个层级。

第一条建议：先别抄大厂架构，把自己的单体模块化。

大部分大厂的微服务架构分享对你来说只是新闻，不是教材。你的切入点应该是阶段1到2：找一个小项目，先让AI实现功能，然后让AI做架构梳理、模块划分，你亲手把模块边界理清楚。这一步做扎实了，后面所有架构概念都能无缝接入。

第二条建议：每次拆分必须带着"解决什么问题"的指标。 不要为了技术炫技拆服务。把"发布频率差异""团队冲突次数""资源扩展瓶颈"这些指标写下来，达到阈值再动手。达不到，就老老实实待在单体里，让AI陪你做业务迭代，快乐且高效。

第三条建议：在让AI生成代码之前，自己先画出依赖方向。 VibeCoding适合在边界明确时放大执行力，不适合在混沌状态里替你定义边界。你可以用下面的prompt模板，把"架构判断"的环节拉出来：

code复制你是高级软件架构师。我们有一个[描述当前项目]的项目，
当前遇到[描述症状]的问题。请你先不要写代码，而是：
1. 根据现有目录结构，评估当前架构属于哪个阶段（单体/模块化/微服务）。
2. 列出当前最可能引起[症状]的耦合点。
3. 给出下一步"最小架构动作"：只说明先调整哪个依赖关系、增加哪个边界。
确认之后，再逐步实现。

这个模板的本质是：让AI先做分析，再由你拍板做决策。拍板这个动作，就是架构能力的训练。坚持用一个月，你对"什么时候该重构""先动哪一块"会建立起直觉。

最后再分享一个我最近在实操中屡试不爽的小技巧：在项目根目录放一个ARCHITECTURE.md，用几段话写下当前架构阶段、模块边界、依赖方向、以及"不允许做的事"（比如：禁止Web层直接访问DAO，禁止订单服务直接读库存库）。之后每次让AI生成代码前，都在prompt里加上一句"请先阅读项目根目录的ARCHITECTURE.md，并遵守其中的架构约束"。这个小动作能让AI的输出从"功能正确"提升到"边界正确"，我已经在三个项目里验证过，效果非常稳定。

架构像城市一样，不是一次规划出来的，而是随着增长长出来的。VibeCoding把每一块砖的生产成本压到极低，但把砖砌成一座能住一百万人的城市，仍然需要你抬头看路、认准阶段、在正确的时机做正确的扩展。这7个阶段，就是你手里的那张城市地图。