微服务与持续交付的天然契合
现在公司做系统，动不动就上十几个服务。订单一个服务，用户一个服务，库存又是一个模块。刚开始图省事用单体架构，结果改个头像都要全系统重启，测试得跑一整天。后来拆成微服务，各自独立部署，问题来了——服务多了，每天手动打包上传服务器根本忙不过来。
这时候就得靠CI/CD流水线撑场面。每次开发提交代码，自动触发构建、测试、打包，最后推到对应环境。比如用户服务更新了，流水线自动拉代码、跑单元测试、打Docker镜像、推到私有仓库，再通知K8s拉取新版本滚动升级。全程没人插手，出问题直接回滚，第二天上班发现日志报错，一看昨天夜里已经自动恢复了。
流水线怎么搭才不踩坑
别一上来就搞复杂工具链。小团队可以用GitLab CI + Docker Compose先跑起来。每个微服务根目录放个 .gitlab-ci.yml，定义几个阶段：
stages:
- test
- build
- deploy
run_tests:
stage: test
script:
- npm install
- npm run test:unit
build_image:
stage: build
script:
- docker login -u $REGISTRY_USER -p $REGISTRY_PASS
- docker build -t my-registry.com/user-service:$CI_COMMIT_SHA .
- docker push my-registry.com/user-service:$CI_COMMIT_SHA等流程跑顺了，再引入Jenkins或ArgoCD做多环境发布。预发环境自动部署，生产环境加个手动确认按钮，避免半夜三点误点上线。
配置管理别藏在代码里
见过有人把数据库密码写进application.yml，还提交到Git，结果被扫描机器人抓走，半夜数据全被拖走勒索。正确做法是用ConfigMap + Secret挂载配置，不同环境加载不同参数。Kubernetes配个ConfigMap叫user-service-config，开发环境连测试库，生产环境指向主从集群，代码完全不用改。
配合CI变量功能，比如$STAGE=prod时执行生产部署脚本，$STAGE=dev就只跑测试。这样同一个流水线模板，多个环境复用，不容易出错。
监控和日志得跟上节奏
十个服务同时更新，某个服务接口延迟从50ms涨到2秒，没人报警就糟了。ELK收集日志，Prometheus抓指标，Grafana画面板，关键服务部署前后自动对比QPS和错误率。一旦异常立即暂停流水线，钉钉群里蹦出告警消息。
比如订单服务上线后5xx错误突增，流水线自动卡在“观察阶段”，运维点进去看监控图，发现是新版本缓存未预热，手动干预补救后再继续。这种设计让自动化既有速度又有安全感。