十二年前我接手了一个“不可能崩”的单体应用。它运行着全公司最核心的订单流程部署方式简单粗暴一台Tomcat一个WAR包MySQL连接池配到两百。上线三年从未宕机。直到双十一那天数据库连接被打满GC停顿飙到十几秒订单超时堆积如山。那天晚上我看着监控面板上刺眼的红色曲线意识到一个残酷的事实架构没有原罪只有错位的匹配。你选择了一种架构就同时选择了它的天花板。那台服务器上的单体应用最终被拆掉了。但拆掉它的过程远比想象中痛苦。这篇文章不讲理论只讲我踩过的坑、走过的弯路以及那些在代码层面真正起效的决策。单体不是原罪失控才是很多人把单体架构说得一无是处仿佛微服务是解药。但事实是你的业务复杂度决定架构复杂度而不是技术潮流决定架构选型。一个日活几千的管理系统用微服务就是在给自己挖坑网络开销、分布式事务、运维成本每一项都比那点“扩展性”收益昂贵得多。单体真正的问题出现在什么时候我总结为三个“失控”信号代码边界失控、数据访问失控、发布节奏失控。代码边界失控就是每个人都在改同一个类一个bug能连环引爆整个应用的线程池。数据访问失控是所有的业务逻辑都在查询同一张表你没法知道哪个调用方在依赖这个字段。发布节奏失控更致命哪怕你只改了一行文案也要把整个应用重新打包、全量上线牵连所有模块一起冒风险。我印象最深的是那个“订单状态流转”的功能。原本只是附加一个小改动结果因为代码耦合把库存模块的锁机制也带崩了。那次事故之后我对团队立了一条死规矩如果一个类超过三百行、一个方法超过二十行、或者一个模块的依赖树超过五层就必须拆。这个标准也许粗暴但它救了我们很多次。第一次拆分的错觉从“大单体”到“小单体”很多人对微服务的第一个误解是把“大”拆成“小”就完事了。我们第一次拆分就是把订单模块从主应用中剥出去单独部署成一个服务。结果呢服务变瘦了但问题没变少反而变多了。订单服务独立后原本在同一个JVM里的方法调用变成了跨进程的HTTP调用。原来一个事务能搞定的操作现在要分两步走先调订单服务再调库存服务。一旦中间网络抖动两边的数据就对不上了。我们花了大量时间去补偿、对账、写重试机制每天都在处理分布式系统里最恶心的“最终一致性”问题。那时候我才真正想明白一件事拆分的核心不是把代码搬出去而是把边界定义清楚。如果你拆出去的服务仍然跟原来一样访问同一个数据库、调用同样的内部类它本质上还是单体只是穿了一件服务的马甲。真正的拆分必须做到数据物理隔离、接口显式定义、依赖单向流动。于是我们推倒重来花了整整两个月重新梳理业务边界。订单服务不再直接访问库存表而是通过库存服务暴露的接口取数据。这个过程极其痛苦但也是从那时起每个团队才真正拥有了自己的“领域”。数据库拆分最硬的一堵墙要说架构演进中最难的部分我毫不犹豫投票给数据库。服务拆到一半卡在数据库上是最常见的悲剧。微服务的难点从来不在服务本身而在数据。你可以在代码层做出完美的领域划分但只要数据库还共用一个库服务之间就永远在互相拖后腿。我们当时的订单库和用户库是混在一起的。大促期间用户表的一个慢查询就能拖垮整个订单库的连接池殃及所有下游服务。后来我们咬着牙做了分库——订单库单独拆出来用户库独立部署。这个过程整整用了三个月涉及数据迁移、双写、灰度切换、回滚方案每一步都像在钢丝上行走。但分库只是第一步真正的坑在于跨库查询。过去一条SQL就能搞定的关联查询现在变成了多次RPC调用然后在应用层做聚合。性能反而下降了。为了救性能我们不得不引入CQRS模式把读模型单独抽出来用Redis做缓存用Elasticsearch做检索。架构演进到最后你会发现你真正在治理的不是代码而是数据的流动方向。从HTTP到RPC链路的觉醒我们第一版微服务服务之间通信用的是HTTP JSON。简单生态好调试方便。但等服务的数量从10个涨到50个问题开始浮现第一性能损耗。一个同步链路要经过五六个服务每个服务都是HTTP序列化用JSON延迟翻了好几倍。第二超时控制混乱。上游调用下游每个服务都设置自己的超时时间一旦链路中某个节点慢整个请求雪崩式堆积。第三缺乏服务发现和负载均衡的细粒度治理一个节点宕机流量仍然会打过去。后来替换成了gRPC Protobuf效果立竿见影。序列化体积缩小了将近一半连接复用让延迟下降了一个数量级。更重要的是gRPC的接口定义是强约束的它逼着你在写代码之前先把接口契约定清楚。这种“契约先行”的工作方式比任何代码评审都有效。当然引入RPC也带来了新问题。服务调用变成了“黑盒”你没法直观地看到哪些服务在调用哪些数据。于是我们又上了链路追踪系统。没有链路追踪的微服务就像蒙着眼睛在迷宫里跑你根本不知道你的请求走过了哪些节点卡在了哪里。当你发现排查一个线上问题需要翻阅几十个服务日志的时候你才真正理解可观测性不是可选项而是生存必需品。容器化与编排从物理机到Kubernetes拆分服务只是第一步接下来你还要面对一个更现实的问题这些服务跑在哪我们刚开始用虚拟机部署每个服务一台机器CPU和内存利用率惨不忍睹。一台16核的机器只跑一个服务大部分时间空闲着但总资源不够用只能不停地买机器。直到引入Docker和Kubernetes才真正把资源利用率提了上来。容器化最大的价值不是“轻量”而是“标准化”。它把环境差异彻底抹平了——开发环境、测试环境、生产环境同一份镜像同一个行为。以前部署上最大的痛点“在我的机器上能跑”彻底被消灭了。加上Kubernetes的自动编排、弹性伸缩、滚动发布整个交付流程都变得自动化了。但Kubernetes的复杂度也是真的。Pod、Service、Deployment、Ingress、ConfigMap概念一堆排错起来要人命。我们运维团队花了近半年才从一知半解到游刃有余。这中间踩过不少坑最惨的一次是升级集群时因为没做好PodDisruptionBudget导致滚动升级期间服务大规模重启线上订单支付短暂中断。基础设施越强大隐藏的风险就越深。K8s不是银弹它只是把单机运维的繁琐转移成了集群运维的复杂度你必须敬畏它。治理与规范微服务真正的分水岭服务拆到一百多个后我又遇到了新的挑战团队协作。以前一个团队维护一个应用现在一个团队可能维护十来个服务代码仓库分散发布节奏各异接口文档滞后出了问题不知道该找谁。这时候我才认识到微服务本质上是一个组织问题而不是技术问题。康威定律说得很清楚系统设计的结构会复制组织的沟通结构。如果你的组织是模糊的你的微服务也一定是混乱的。我们开始推行“服务自治”原则——每个微服务都有一个指定的owner负责接口变更、版本演进和线上值班。同时建立了统一的API规范、错误码约定以及发布流程。每个服务都必须有对应的健康检查、监控指标、日志追踪。不满足这些条件的服务不允许上生产。这个过程中我总结了三个字敢拒绝。要敢于拒绝那些为了“微服务而微服务”的立项敢于拒绝那些没有监控和文档的服务上线敢于拒绝那些为了让PPT好看而做的架构大改造。架构演进不是技术秀而是一场持续的、有节奏的、可回滚的渐进式变革。演进没有终点只有下一站今天回头看我们的系统已经从最初那个“不可能崩”的单体演化成了一个拥有上百个服务、十几个独立数据库、全链路自动化的分布式架构。但你要问我它完美吗我会说不。它更复杂了更脆弱了在某些场景下它甚至不如当年的单体应用来得直接高效。但我从不后悔做这次迁移因为它让业务获得了独立的扩展能力、独立的发布节奏和独立的故障隔离。单体应用让你跑得快微服务让你跑得远但跑得远的前提是你有足够的工程素养来驾驭复杂。如果你没有就别急着追新概念先把单体练好把边界切清楚把自动化做好。等到真正痛了再出发。架构演进永远没有终点下一个风口也许就是服务网格、无服务器、或者更奇怪的东西。但无论术语怎么变底层的逻辑不会变技术永远服务于业务架构永远服务于组织。你看清了这一点才不会被潮流裹挟着走而是能真正地驾驭技术为业务创造价值。那台老Tomcat早就报废了。但每次我看着Kubernetes仪表盘上自动伸缩的Pod曲线总会想起十二年前那个夜里我盯着监控上的红色警报心里默念的那句话别怕它变复杂怕的是你永远停在原地。架构如人生所有的成长都伴随着拆解和重构的阵痛。 
长河君 · 2026/8/22 18:32:47 · 阅读 1.2k 从单体到微服务：Java架构演进实践笔记
十二年前我接手了一个“不可能崩”的单体应用。它运行着全公司最核心的订单流程部署方式简单粗暴一台Tomcat一个WAR包MySQL连接池配到两百。上线三年从未宕机。直到双十一那天数据库连接被打满GC停顿飙到十几秒订单超时堆积如山。那天晚上我看着监控面板上刺眼的红色曲线意识到一个残酷的事实架构没有原罪只有错位的匹配。你选择了一种架构就同时选择了它的天花板。那台服务器上的单体应用最终被拆掉了。但拆掉它的过程远比想象中痛苦。这篇文章不讲理论只讲我踩过的坑、走过的弯路以及那些在代码层面真正起效的决策。单体不是原罪失控才是很多人把单体架构说得一无是处仿佛微服务是解药。但事实是你的业务复杂度决定架构复杂度而不是技术潮流决定架构选型。一个日活几千的管理系统用微服务就是在给自己挖坑网络开销、分布式事务、运维成本每一项都比那点“扩展性”收益昂贵得多。单体真正的问题出现在什么时候我总结为三个“失控”信号代码边界失控、数据访问失控、发布节奏失控。代码边界失控就是每个人都在改同一个类一个bug能连环引爆整个应用的线程池。数据访问失控是所有的业务逻辑都在查询同一张表你没法知道哪个调用方在依赖这个字段。发布节奏失控更致命哪怕你只改了一行文案也要把整个应用重新打包、全量上线牵连所有模块一起冒风险。我印象最深的是那个“订单状态流转”的功能。原本只是附加一个小改动结果因为代码耦合把库存模块的锁机制也带崩了。那次事故之后我对团队立了一条死规矩如果一个类超过三百行、一个方法超过二十行、或者一个模块的依赖树超过五层就必须拆。这个标准也许粗暴但它救了我们很多次。第一次拆分的错觉从“大单体”到“小单体”很多人对微服务的第一个误解是把“大”拆成“小”就完事了。我们第一次拆分就是把订单模块从主应用中剥出去单独部署成一个服务。结果呢服务变瘦了但问题没变少反而变多了。订单服务独立后原本在同一个JVM里的方法调用变成了跨进程的HTTP调用。原来一个事务能搞定的操作现在要分两步走先调订单服务再调库存服务。一旦中间网络抖动两边的数据就对不上了。我们花了大量时间去补偿、对账、写重试机制每天都在处理分布式系统里最恶心的“最终一致性”问题。那时候我才真正想明白一件事拆分的核心不是把代码搬出去而是把边界定义清楚。如果你拆出去的服务仍然跟原来一样访问同一个数据库、调用同样的内部类它本质上还是单体只是穿了一件服务的马甲。真正的拆分必须做到数据物理隔离、接口显式定义、依赖单向流动。于是我们推倒重来花了整整两个月重新梳理业务边界。订单服务不再直接访问库存表而是通过库存服务暴露的接口取数据。这个过程极其痛苦但也是从那时起每个团队才真正拥有了自己的“领域”。数据库拆分最硬的一堵墙要说架构演进中最难的部分我毫不犹豫投票给数据库。服务拆到一半卡在数据库上是最常见的悲剧。微服务的难点从来不在服务本身而在数据。你可以在代码层做出完美的领域划分但只要数据库还共用一个库服务之间就永远在互相拖后腿。我们当时的订单库和用户库是混在一起的。大促期间用户表的一个慢查询就能拖垮整个订单库的连接池殃及所有下游服务。后来我们咬着牙做了分库——订单库单独拆出来用户库独立部署。这个过程整整用了三个月涉及数据迁移、双写、灰度切换、回滚方案每一步都像在钢丝上行走。但分库只是第一步真正的坑在于跨库查询。过去一条SQL就能搞定的关联查询现在变成了多次RPC调用然后在应用层做聚合。性能反而下降了。为了救性能我们不得不引入CQRS模式把读模型单独抽出来用Redis做缓存用Elasticsearch做检索。架构演进到最后你会发现你真正在治理的不是代码而是数据的流动方向。从HTTP到RPC链路的觉醒我们第一版微服务服务之间通信用的是HTTP JSON。简单生态好调试方便。但等服务的数量从10个涨到50个问题开始浮现第一性能损耗。一个同步链路要经过五六个服务每个服务都是HTTP序列化用JSON延迟翻了好几倍。第二超时控制混乱。上游调用下游每个服务都设置自己的超时时间一旦链路中某个节点慢整个请求雪崩式堆积。第三缺乏服务发现和负载均衡的细粒度治理一个节点宕机流量仍然会打过去。后来替换成了gRPC Protobuf效果立竿见影。序列化体积缩小了将近一半连接复用让延迟下降了一个数量级。更重要的是gRPC的接口定义是强约束的它逼着你在写代码之前先把接口契约定清楚。这种“契约先行”的工作方式比任何代码评审都有效。当然引入RPC也带来了新问题。服务调用变成了“黑盒”你没法直观地看到哪些服务在调用哪些数据。于是我们又上了链路追踪系统。没有链路追踪的微服务就像蒙着眼睛在迷宫里跑你根本不知道你的请求走过了哪些节点卡在了哪里。当你发现排查一个线上问题需要翻阅几十个服务日志的时候你才真正理解可观测性不是可选项而是生存必需品。容器化与编排从物理机到Kubernetes拆分服务只是第一步接下来你还要面对一个更现实的问题这些服务跑在哪我们刚开始用虚拟机部署每个服务一台机器CPU和内存利用率惨不忍睹。一台16核的机器只跑一个服务大部分时间空闲着但总资源不够用只能不停地买机器。直到引入Docker和Kubernetes才真正把资源利用率提了上来。容器化最大的价值不是“轻量”而是“标准化”。它把环境差异彻底抹平了——开发环境、测试环境、生产环境同一份镜像同一个行为。以前部署上最大的痛点“在我的机器上能跑”彻底被消灭了。加上Kubernetes的自动编排、弹性伸缩、滚动发布整个交付流程都变得自动化了。但Kubernetes的复杂度也是真的。Pod、Service、Deployment、Ingress、ConfigMap概念一堆排错起来要人命。我们运维团队花了近半年才从一知半解到游刃有余。这中间踩过不少坑最惨的一次是升级集群时因为没做好PodDisruptionBudget导致滚动升级期间服务大规模重启线上订单支付短暂中断。基础设施越强大隐藏的风险就越深。K8s不是银弹它只是把单机运维的繁琐转移成了集群运维的复杂度你必须敬畏它。治理与规范微服务真正的分水岭服务拆到一百多个后我又遇到了新的挑战团队协作。以前一个团队维护一个应用现在一个团队可能维护十来个服务代码仓库分散发布节奏各异接口文档滞后出了问题不知道该找谁。这时候我才认识到微服务本质上是一个组织问题而不是技术问题。康威定律说得很清楚系统设计的结构会复制组织的沟通结构。如果你的组织是模糊的你的微服务也一定是混乱的。我们开始推行“服务自治”原则——每个微服务都有一个指定的owner负责接口变更、版本演进和线上值班。同时建立了统一的API规范、错误码约定以及发布流程。每个服务都必须有对应的健康检查、监控指标、日志追踪。不满足这些条件的服务不允许上生产。这个过程中我总结了三个字敢拒绝。要敢于拒绝那些为了“微服务而微服务”的立项敢于拒绝那些没有监控和文档的服务上线敢于拒绝那些为了让PPT好看而做的架构大改造。架构演进不是技术秀而是一场持续的、有节奏的、可回滚的渐进式变革。演进没有终点只有下一站今天回头看我们的系统已经从最初那个“不可能崩”的单体演化成了一个拥有上百个服务、十几个独立数据库、全链路自动化的分布式架构。但你要问我它完美吗我会说不。它更复杂了更脆弱了在某些场景下它甚至不如当年的单体应用来得直接高效。但我从不后悔做这次迁移因为它让业务获得了独立的扩展能力、独立的发布节奏和独立的故障隔离。单体应用让你跑得快微服务让你跑得远但跑得远的前提是你有足够的工程素养来驾驭复杂。如果你没有就别急着追新概念先把单体练好把边界切清楚把自动化做好。等到真正痛了再出发。架构演进永远没有终点下一个风口也许就是服务网格、无服务器、或者更奇怪的东西。但无论术语怎么变底层的逻辑不会变技术永远服务于业务架构永远服务于组织。你看清了这一点才不会被潮流裹挟着走而是能真正地驾驭技术为业务创造价值。那台老Tomcat早就报废了。但每次我看着Kubernetes仪表盘上自动伸缩的Pod曲线总会想起十二年前那个夜里我盯着监控上的红色警报心里默念的那句话别怕它变复杂怕的是你永远停在原地。架构如人生所有的成长都伴随着拆解和重构的阵痛。