架构设计演进路径：从单体到云原生的实战思考

刚开始做系统的时候，谁没写过几个“大泥球”架构？一个应用包打天下，前端后端数据库全塞在一起，改个按钮颜色都得重新部署整个服务。那时候项目小，用户少，倒也凑合能用。可一旦业务跑起来，问题就来了——发布卡半天，扩容靠复制整个应用，查个 bug 得翻遍上千行代码。

单体架构的甜与痛

很多老系统都是这么起家的。比如早年某电商后台，订单、库存、支付全在一个 Java WAR 包里。上线初期开发快，部署简单。但随着活动增多，一到大促，服务器直接扛不住。想只给订单模块加机器？不行，只能整应用复制。更头疼的是团队协作，十来个人共用一个代码库，每天 merge 冲突不断。

拆，是唯一的出路

于是开始拆。按业务边界把系统划成订单服务、用户服务、商品服务。每个独立部署，数据库也分开。HTTP+JSON 成了服务间通信的标配。这时候 RESTful 接口开始流行，Spring Boot 搭脚手架几分钟就拉起一个微服务。

GET /api/v1/orders/12345 HTTP/1.1
Host: order-service.example.com

拆完确实灵活多了。订单服务压力大，单独扩三台；用户服务稳定，两台就够了。开发也清爽，各团队盯自己的服务，接口协议对清楚就行。

但新问题又冒出来

服务一多，调用链就长。用户下单，先查用户信息，再扣库存，最后生成订单。中间任何一个服务抖一下，整个流程就卡住。日志散在各个机器上，排查问题得登录七八台服务器拼时间线。这时候服务发现、配置中心、链路追踪成了刚需。

Spring Cloud 或者 Dubbo 这类框架被推上前台。注册中心管服务地址，Config Server 统一发配置，Sleuth 跟踪请求路径。运维也开始用 Docker 把服务打包，部署效率提升不小。

容器化推动架构再进一步

Docker 解决了“在我机器上好好的”这种经典难题。镜像一建，到处运行。但几十个服务怎么编排？Kubernetes 上场了。Pod、Service、Deployment 这一套定义下来，扩容缩容变成声明式操作。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: order-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: order-service

CI/CD 流水线接进来之后，代码一合并，自动构建镜像、推仓库、滚更新。半夜上线不再提心吊胆，点个按钮的事。

云原生时代的新常态

现在新项目起步，很少有人再从单体干起了。直接上微服务，K8s 托管，服务网格 Istio 管流量，Prometheus 加 Grafana 做监控。甚至函数计算（Serverless）也开始在非核心链路试水，比如发短信、写日志这种短任务。

架构演进从来不是为了追技术潮流。哪天业务需求变了，现有结构撑不住了，才是变革的真正契机。就像家里装修，住着住着发现厨房太小，客厅插座不够，才想着重新布局。系统也一样，用户量涨了、功能复杂了、团队扩大了，架构自然就得跟着动。

回头看，从单体到 SOA 到微服务再到云原生，每一步都是为了解决眼前的具体问题。没有所谓“最好”的架构，只有“最合适当下”的设计。明天如果业务又变天，谁知道会不会冒出新的组合方式？