刚接手公司新项目的时候，团队正从单体架构往微服务转型。听起来挺高大上，实际干起来才发现，部署这事儿比想象中复杂得多。不是某个服务起不来，就是配置对不上，日志查了半天发现是环境变量没设对。
拆得太多反而难管
一开始觉得，既然叫微服务，那就拆细点，用户一个、订单一个、支付一个、通知一个……结果一上线，光启动就得十几分钟。运维同事直接找上门：‘你这三十多个服务，每个都要独立部署、监控、升级，出问题了怎么排查？’
后来学乖了，按业务边界合并。比如把订单和支付归到交易域，统一打包部署，共用一套配置中心和日志收集。虽然还是分开开发，但部署时可以当成一个小集群来处理，省了不少事。
配置管理不能靠手改
最头疼的是配置文件。本地测试用 application-dev.yml，预发用 application-pre.yml，生产又是一套。每次上线前，总有服务因为漏改数据库地址连不上库。
后来引入了 Spring Cloud Config + Git 仓库管理，所有配置集中存放，服务启动时自动拉取对应环境的配置。哪怕加个缓存超时时间，也走 PR 合并，留痕又安全。
spring:\n cloud:\n config:\n uri: http://config-server:8888\n label: main\n profile: prod网关是门面，也最容易堵
所有请求都走 API 网关，一开始用 Nginx 做转发，简单粗暴。可随着服务增多，路由规则越来越长，改一次就得重启，用户体验直接掉线。
换成 Spring Cloud Gateway 后，支持动态路由，配合 Nacos 实现服务发现，新增服务不用动网关配置。还能在上面统一做限流、鉴权，比如某个接口被刷，直接在网关层拦截，后端服务轻松不少。
健康检查不是摆设
有次线上一个服务挂了，但负载均衡还在往它转发请求，用户一直报错。后来才意识到，/health 接口返回 200，但实际上数据库连接已经断了。
于是把健康检查逻辑改了，不只是看进程是否存活，还要验证数据库、Redis、MQ 是否可连。Kubernetes 的 liveness 和 readiness 探针也配上，有问题自动下线，恢复后再加入流量。
livenessProbe:\n httpGet:\n path: /actuator/health\n port: 8080\n initialDelaySeconds: 30\n periodSeconds: 10日志分散就像拼图
以前一个请求打到单体应用，日志一条串到底。现在一个请求经过五六个服务，每个写各自的日志，查问题得登录五六台机器，按时间拼接，效率极低。
上了 ELK（Elasticsearch + Logstash + Kibana）还不够，加上了链路追踪 SkyWalking。每个请求生成唯一 traceId，从网关一路透传下去，最后在 Kibana 里一键查全链路日志。定位问题从半小时缩短到几分钟。
微服务部署不是一蹴而就的事。工具链要配齐，流程要标准化，更重要的是团队协作方式得跟着变。谁负责发布、谁响应告警、变更有没有灰度，这些细节决定了系统是灵活还是混乱。