从单体到微服务：后端技术栈演进路线

凌晨三点发布窗口开启运维把那个三百兆的war包往服务器上一扔重启等待。五分钟过去页面还没出来。日志里一行行滚一个订单查询卡住了整个应用连首页都打不开。这就是单体架构的日常——一荣俱荣一损俱损。很多人骂单体可回头想想单体不是原罪它是业务早期的必然选择。单体架构跑得快也容易摔得惨创业初期三五个人一个Spring Boot项目搞定所有。用户、订单、库存、支付全塞在一个进程里。部署简单调试方便改一行代码重启就行。可业务一旦起来代码库膨胀到几十万行编译一次十分钟改一个小功能得把整个应用重新部署。更可怕的是一个模块的内存泄漏能把整个服务拖垮。单体像一间没有隔断的大通铺住的人多了打呼噜的、磨牙的谁也别想睡好。什么时候拆别为了微服务而微服务有人说微服务是银弹可银弹打歪了照样要命。团队不到十个人日活不到一万拆成二十个服务光运维成本就压垮你。拆分的信号很明确不同模块的伸缩需求差异大比如订单需要十台机器用户只需要一台不同模块的发布频率差得多比如推荐算法天天改支付半年不动团队规模大到沟通成本超过开发成本。拆微服务不是技术升级是组织问题倒逼的架构调整。技术栈演进从Spring Boot到Spring Cloud单体时代Spring Boot是标配一个jar包打天下。要拆服务先得解决服务间调用。Spring Cloud Alibaba成了国内主流Nacos做注册中心和配置中心OpenFeign做声明式调用Sentinel做限流熔断Seata做分布式事务。再往后网关用Spring Cloud Gateway链路追踪用SkyWalking。每一层都在解决拆分带来的新问题。微服务不是把单体切碎就完了切碎之后怎么粘回去才是真功夫。容器化与K8s微服务的温床服务多了手工部署就是噩梦。Docker把每个服务连代码带环境打包成镜像K8s负责调度、扩缩容、自愈。没有容器化微服务就是纸上谈兵。K8s的Deployment管无状态服务StatefulSet管有状态服务Service做负载均衡Ingress暴露入口。再配上Helm做包管理一套YAML文件就能拉起整个集群。容器是微服务的腿没有腿跑不起来。服务治理别让微服务变成分布式泥潭拆完才发现调用链长得像迷宫。一个请求经过网关、用户服务、订单服务、库存服务、支付服务任何一个环节超时整个请求失败。这时候需要熔断降级Sentinel配置规则Hystrix做线程隔离。还需要分布式链路追踪SkyWalking把每个span串起来一眼看出哪个服务拖了后腿。微服务最大的坑是把单体里的方法调用变成了网络调用网络会断、会慢、会丢包你得为每一次调用准备好Plan B。康威定律组织架构决定技术架构你拆了十个服务却只有一个十人团队每个人维护十个服务最后每个服务都写得像单体。正确的做法是反过来先调整团队每个小组负责一个或几个服务从开发到运维全包。这就是康威定律——系统架构终将映射组织的沟通结构。想让微服务跑得顺先让团队拆得对。从单体到微服务不是一蹴而就的跳跃是随着业务和团队成长的自然演进。单体不丢人微服务不高级适合当下的才是最好的。架构演进的终点不是微服务是让系统活得更久、让团队跑得更快。别为了追时髦拆也别因为怕麻烦不拆。看清自己的阶段走稳每一步比什么都强。