微服务架构已经火了十几年。关于它的好处，独立部署、弹性伸缩、团队自治，各种文章说得够多了。Jayapragash Dakshnamurthy 在 DZone 上写了一篇从单体到微服务的实战教训，总结了他在多个企业现代化项目中的观察。文章讲了五个教训，都是微服务领域的标准知识。但其中有一个洞察值得单独拎出来说。
微服务不减少系统复杂度。它重新分配复杂度。
单体的复杂度集中在代码里：模块耦合、巨型构建、改一行测全身。微服务把这份复杂度拆散，搬到了网络、基础设施、监控、部署流水线和数据层。复杂度总量没变，只是换了地方。
换句话说，选架构本质上是在选 你愿意把复杂度放在哪里 。
故障排查 → 复杂度搬到了调用链上
单体的好处之一是故障现场完整。一个请求从认证到查库到返回结果，全在一个进程里完成，看日志和堆栈跟踪就能理清调用链。
微服务不一样。一个下单操作可能穿过认证服务、库存服务、支付服务、通知服务。任何一个环节挂了，整个操作都可能受影响。排查问题时，你不能只看一个服务的日志，要跨多个服务拼出完整链路。
复杂度没有消失。它从进程内的调用栈变成了网络上的分布式调用链。你需要分布式追踪系统（Jaeger、Zipkin）来还原请求路径，这就是单体时代不需要的东西。
可观测性 → 复杂度搬到了监控体系上
单体应用里，日志文件通常在一台机器上，grep 一下就能定位问题。告警也简单：进程挂了、CPU 飙了、磁盘满了，几个基础指标覆盖大部分场景。
微服务架构下，几十个服务分布在多台机器（或 Pod）上，日志分散在各处。要回答"用户下单为什么超时"这个问题，你得跨服务、跨机器地关联日志和指标。集中式日志平台（ELK、Loki）、指标看板（Prometheus + Grafana）、服务健康检查、告警规则，这些在单体时代是锦上添花，在微服务时代是生存必需品。
可观测性基础设施本身成了系统的一部分，不再是运维的外挂工具。
部署 → 复杂度搬到了流水线上
部署一个单体应用：打包一个 war/ear，传到服务器，重启。手工操作可能慢，但不复杂。
部署微服务：几十个服务，每个有自己的代码仓库、构建流程、配置、依赖版本。手工部署不可行，你得有 CI/CD 流水线、容器编排（Kubernetes）、基础设施即代码（Terraform、Ansible）。
原文把这叫 DevOps 成熟度。说到底是微服务把部署的复杂度从"一个包"放大到了"一个系统"。自动化不是提效手段，是进入门槛。
服务边界 → 复杂度搬到了团队协作上
单体里模块边界是一起写在代码里的，跨模块调用就是函数调用。微服务把模块边界变成了服务边界，跨模块调用变成网络调用。
这带来一个新问题：怎么切服务？按技术层切（controller 层、service 层、dao 层各一个服务），服务之间会产生大量同步调用，改一个业务需求要协调多个服务，比单体时代更慢。按业务领域切（订单服务、库存服务、支付服务各一个），团队跟着服务边界走，一个团队拥有一个完整的业务能力。
复杂度的转移方向：从"代码内部的模块职责不清"变成了"团队之间的服务边界不清"。DDD（领域驱动设计）在微服务时代重新火起来就是这个原因。
数据 → 复杂度搬到了一致性上
单体的最大便利是 ACID 事务。一个数据库连接里 begin transaction，多个表穿插操作，最后 commit 或 rollback，一致性由数据库保证。
微服务推崇每个服务有自己的数据库。好处是服务独立演进，坏处是跨服务的业务操作不再有数据库事务兜底。订单扣库存、支付扣余额、通知发消息，这三个操作跨三个服务三个数据库，任何一个失败都需要补偿逻辑。于是分布式事务（Saga）、最终一致性、事件驱动架构成了必修课。
复杂度的转移方向：从"数据库保证一致性"变成了"你得自己在代码里处理不一致"。
不是反对微服务
这篇不是反微服务的檄文。微服务解决的真实问题，比如大团队协作、独立部署、弹性伸缩，是单体确实难做好的。
但要清楚代价。每次把复杂度从一个地方搬走，它就会在另一个地方重新出现。迁移之前问自己：我们现在最痛的是哪种复杂度？搬到新地方之后，我们有能力处理那种复杂度吗？
如果团队只有五个人、没有 CI/CD 基础设施、业务逻辑还在频繁变动，单体的代码耦合可能比微服务的运维复杂度更好承受。反过来，如果团队上百人、单次部署要协调十几个组、改一个模块要回归整个应用，那运维复杂度的代价也许就值得付。
架构选型没有标准答案，只有你愿意把复杂度放在哪里。