云原生架构项目实战案例：从传统部署到容器化落地

一次真实的电商系统改造经历

去年我们团队接手了一个老电商平台的性能优化任务。原来的系统跑在几台物理机上，每次大促前都要提前一周停服扩容，运维同事熬夜打包镜像、手动改配置，就像赶集前搭摊位，手忙脚乱还容易出错。

最头疼的是版本发布。有一次前端误把测试资源推上了生产环境，导致首页图片全挂了。客户投诉电话打爆客服，我们一边查日志一边远程删文件，像在火灾现场救火。

转向云原生的第一步：容器化拆解

我们决定用云原生思路重构。先把单体应用按业务拆成用户服务、商品服务、订单服务，每个服务独立打包成 Docker 镜像。比如用户服务的构建文件长这样：

FROM openjdk:11-jre-slim
WORKDIR /app
COPY user-service.jar .
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "user-service.jar"]

写好之后推到私有镜像仓库，配合 CI 流水线，代码一合并自动构建新镜像，再也不用手动传 jar 包。

Kubernetes 编排真实场景

服务多了以后，光靠 docker run 已经管不过来。我们搭了一套三节点的 K8s 集群，用 Deployment 管理副本数，Service 做内部通信。比如订单服务的部署配置：

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
        ports:
        - containerPort: 8080

上线当天凌晨两点突发流量激增，K8s 自动把订单服务从3个实例扩到8个，等我们起床看监控时，系统已经扛住了峰值。这种弹性在过去根本不敢想。

服务治理的实际效果

引入 Istio 后终于解决了长期困扰的日志追踪问题。以前查一个跨服务的异常要分别登录三四台机器翻日志，现在通过 Jaeger 直接看到完整调用链。有次支付失败的问题，五分钟就定位到是第三方接口超时触发了熔断。

配置管理也统一到了 ConfigMap 和 Vault。开发人员再也不能把数据库密码写死在代码里，所有敏感信息走密钥中心动态注入。新来的实习生第一次提交代码就把密码硬编码了，CI 流水线直接卡住不让他合并，倒逼团队养成好习惯。

监控和告警怎么设置才有效

我们给每个服务都加了健康检查接口，K8s 每30秒探测一次。但真正起作用的是 Prometheus + Alertmanager 的组合。设置了一条规则：如果5分钟内错误率超过5%，立即发钉钉通知值班人员。

有天下午突然收到告警，发现是某个缓存预热脚本异常退出导致大量穿透查询。因为告警及时，我们在用户大规模访问前半小时修复了问题，避免了一次潜在的服务雪崩。