金宇澄1. 单体架构的性能上限：瓶颈从哪个环节开始出现
先说一个我真实带过的项目。早期业务逻辑简单，一个Java单体应用加一台MySQL撑了整整两年，日均请求量十几万，高峰期CPU到过80%，但整体还能扛。真正开始出事是业务翻倍之后：每天早上十点准时告警，数据库连接池打满，接口平均响应从80ms吊到1.2s，页面转圈，用户开始投诉。当时技术团队的第一反应是加机器、加缓存、调JVM参数，折腾了一周，效果有，但治标不治本。
这个经历特别典型。几乎所有单体架构的性能演进，都遵循相似规律：瓶颈不是平均分布在整个系统里的，而是按“数据库→连接池→线程池→第三方依赖”这个顺序层层递进。你想做好可扩展性架构设计，第一步就必须把这条链路看清楚。
1.1 数据库连接池为什么会成为第一块短板
单体应用最核心的瓶颈往往不在应用代码，而在数据库连接。原因是连接池的大小是有限的，而应用的所有请求都要占用连接。我用实际数据说明一下：假设Druid连接池配置了50个连接，每个接口查库平均耗时50ms，那这50个连接的每秒理论吞吐是多少？大致估算就是50除以0.05，1000 QPS。听着不少，但一旦某个慢SQL把单次查库时间拖到500ms，理论吞吐直接掉到100 QPS。更糟的是，慢SQL会把连接长时间占住不放，后面的请求排队等待，排队本身又拉长了响应时间，形成一种恶性循环。
所以我会跟团队反复强调一个判断原则：单体架构性能告急时，先看数据库连接池的活跃连接数和慢SQL日志，不要急着改代码。很多时候问题根本不在业务逻辑，而是某个表缺索引，或者某个查询用了SELECT *还带了子查询，把连接池整个拖垮。
解决这个阶段的瓶颈，常规手段无非是加索引、加Redis缓存、读写分离。这些操作不改变架构，但能帮单体尽量往后撑。我见过不少团队在这些手段没有做到位的情况下就贸然启动微服务改造，结果拆完之后数据库还是同一个，真正的问题一个都没解决，反而多了网络开销。
1.2 应用层的线程模型同样有限
数据库扛住之后，下一个瓶颈通常出现在应用层的线程池。Tomcat默认情况下一个请求占一个线程，线程数量有上限，单个请求的处理时间越长，可服务的并发数就越低。
有一个点容易被忽略：单体应用里的同步调用链路往往很长，一个下单接口要经过用户校验、库存查询、订单创建、优惠券计算、积分更新五六个步骤，每个步骤都要访问数据库或远程服务。这些步骤在线程模型里是串行执行的，总耗时是各环节耗时的累加。当其中一个环节变慢，整个线程就会被拖住。线程池一旦耗尽，新请求直接排队，Tomcat的acceptor线程不断接收连接，但工作线程没有空闲，表现就是服务端口还能通，但请求全部超时。
从单体内部改善的方式，可以考虑把链路中不需要同步返回的环节改成异步执行，比如发短信、写日志、更新积分这些，用线程池或者消息队列削峰。但这里有个前提，就是必须想清楚哪些操作可以异步，哪些必须同步返回给用户。
1.3 单体与微服务的本质区别不是代码，是容错边界
聊到这里想给单体架构一个公道话：单体不是错的，错的是把一个无限增长的业务硬塞进单一的容错边界里。单体的核心问题是它天然没有“隔离”的能力——一个功能模块出了问题，默认会影响到同一进程里的所有其他模块，比如内存溢出直接把整个应用干挂。而微服务的架构价值，恰恰是把系统拆成多个独立的容错单元，每个单元可以独立扩缩容、独立部署、独立降级。
这也是那段时间我们带团队启动微服务改造的根本原因：不是为了“技术先进”，而是因为单体的容错边界已经装不下业务的复杂度和流量增长模型了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 微服务不是银弹：动手拆分前必须算清楚的隐性成本
从我接触的很多团队情况来看，大家普遍对微服务存在两个极端认知：要么觉得微服务是神器，拆了就性能暴涨；要么觉得微服务是灾难，拆完分布式事务和链路追踪能把团队搞死。我自己的真实体会是，微服务确实能解决单体的性能瓶颈，但它带来的隐性成本，如果不在动手前想清楚，后期大概率会痛到怀疑人生。
2.1 网络开销和序列化成本：一次调用变多次调用
单体里一个方法调用是进程内的，走的是JVM的方法栈，耗时几乎可以忽略，通常小于0.1ms。拆成微服务之后，一次业务操作变成了多次RPC调用，每次都要经过网络传输和序列化反序列化，单次开销在1到10ms之间，取决于网络环境、数据包大小和序列化框架。
拿我们当时的下单链路举例。单体版本里，下单选在同一个事务里，改库存、扣余额、写订单，一次搞定。拆成订单服务、库存服务、用户服务之后，一次下单至少变成三次远程调用，再加上注册中心服务发现、负载均衡、可能的重试逻辑，链路耗时凭空多了几十毫秒。听起来不多，但在高峰期请求并发几千的情况下，这几十毫秒就是压垮线程池的那根稻草。
所以，拆服务之前一定要对链路的调用次数做一次盘点。有一条经验值可以分享：如果拆完后一次用户请求会触发超过五次内部服务调用，就要非常警惕。要么用批量接口把多次调用合并成一次，要么对链路中的高延迟环节引入缓存，要么考虑把某些服务重新合并回去。
2.2 分布式事务比想象中更麻烦，一致性和性能之间的平衡
单体时代，事务靠数据库的ACID，一个@Transactional注解就能保证数据一致性。拆微服务后，每个服务有独立的数据库，跨服务操作就无法依赖单一数据库事务了。
很多团队第一反应是引入Seata这样的分布式事务框架。但必须知道，分布式事务框架是有性能代价的：AT模式的全局锁会放大锁竞争，TCC模式需要大量幂等和补偿代码。对追求高并发吞吐的链路来说，强事务方案经常是反模式。
我们当时的选择是对业务链路做区分对待：强一致要求的场景（比如支付）尽量收敛到同一个服务内处理，拆不了的用Saga模式加可靠消息做最终一致性。这里有个非常核心的设计原则：尽量让一个业务流程的主要写入集中在一个服务内完成，只有必须跨服务的数据才走异步事件和消息队列。 这样做的好处是既能保持事务的简单性，又能把服务边界划分清楚。
2.3 运维和部署复杂度是隐形成本的大头
单体只需要部署一个应用，微服务动辄十几个服务，每个服务还要管理实例数、配置、日志、监控、告警规则。这不是某一个环节的复杂度翻倍，是全链路的复杂度翻倍。
这些成本在架构设计阶段很容易被忽略，因为画架构图的时候大家都在看服务怎么分、接口怎么调，很少有人去思考“这家公司有没有足够的运维能力支撑这么多服务”。我们团队当时是为了配合扩展才上微服务，但实际落地时，CI/CD流水线、配置中心、日志聚合、监控告警、链路追踪，这些东西一个都不能少。
3. 绞杀式演进六步法：从单体到微服务的迁移顺序与操作细节
我从来不推荐直接把单体推倒重来，尤其是业务还在快速迭代的时候。我们采用的是业界经典的绞杀者模式（Strangler Pattern），也就是在保持系统可用的前提下，逐步把单体的一部分流量剥离到新服务中，像一个藤蔓慢慢绞杀掉老树一样，最终完成整个替换。
3.1 第一步：先画“领域地图”，找到真正的拆分边界
很多团队上来就按技术分层拆，比如把Controller和Service拆成两个服务，这是典型的错误。正确的拆分边界应该按业务领域来划，核心工具是领域驱动设计里的“限界上下文”（Bounded Context）。
你可以这样操作：把系统里所有核心业务名词列出来，比如“用户”“订单”“库存”“支付”“商品”，然后看每个名词被哪些业务操作影响，再检查这些操作之间的关联强度。关联强的放一个服务里，关联弱的拆分出去。我们当时花了将近两周做这件事，产出不是代码，而是一张领域地图和依赖关系图，标注哪些模块的数据库表被多个业务同时读写——这些就是拆分的难点，也是优先要解决的。
3.2 第二步：数据库先行拆分，这是最难也最关键的
微服务拆分最麻烦的不是代码，是数据。如果服务拆了但数据库还在一起，所有服务共用一个库，连接池瓶颈依然存在，拆分没有意义。所以数据拆分必须跟着服务边界走。
数据拆分有一个实用技巧：从“写分离”开始。先把订单服务的数据从主库里分到独立的订单库，通过同步机制保证一段时间双写，等订单服务的所有读写都切到新库后再停掉同步。这个过程依赖数据迁移工具，比如使用ShardingSphere或自研迁移脚本都可以，但一定要做数据校验和灰度切换。我们当时因为数据量较大，双写阶段持续了两周，每天跑对账任务，确认两侧数据一致后才做的正式切换。
3.3 第三步：把服务伪装成新接口，通过网关完成流量切换
拆完数据后，写一个新的订单服务，对外暴露REST接口，但内部可以暂时继续调用单体里的旧逻辑，也就是“防腐层”模式。在Nacos里注册服务不注册到核心路由，先通过内部调用的方式自测，跑通一个接口后再将流量切换过去。
流量切换要遵循一个原则：先闻后切。先切一个不重要的读接口试运行几天，观察服务正常、日志正确、性能达标后，再切换写入量大的接口。每一段切换都要有回滚预案，一旦发现异常立刻切回单体。
3.4 第四步：服务发现、网关与配置中心三位一体
服务拆分到一定数量后，手写服务地址就不现实了，这时候必须引入注册中心和网关。
- 注册中心：我们用的Nacos，承担服务注册、发现和配置管理，是微服务架构的基石。
- 网关：使用Spring Cloud Gateway做统一入口，负责路由转发、鉴权、限流和灰度路由配置。网关层做的事情越多，下游服务就越简单。
- 配置中心：所有服务的配置统一收口，通过Nacos配置中心管理，支持动态刷新，不用重启服务。
搭建顺序上，我的建议是先把Nacos搭好并保证高可用（至少三节点），再接网关，最后才是业务服务。很多团队反着来，先写业务服务，一路写完后发现服务之间互相调用依赖关系混乱，回头再搭Nacos和网关，成本大得多。
3.5 第五步：重新设计容错策略：熔断、限流、降级一个都不能少
单体变成微服务后，链路变长，任何一个下游服务抖动都可能拖垮上游。所以必须给每个服务配备容错三件套：
- 限流（Rate Limiting）：在网关层和核心服务层按接口维度设置QPS上限，防止流量峰值冲垮服务。
- 熔断（Circuit Breaking）：当下游服务错误率达到阈值时，上游主动熔断，快速失败而不是继续请求，等下游恢复后再放量试探。
- 降级（Fallback）：设置预案，非核心功能挂了就返回默认值或提示稍后再试，保证核心流程可用。
我们用的是Sentinel，配合Nacos做动态规则配置，不用改代码就能调整限流阈值和熔断策略，在实战中非常灵活。
3.6 第六步：链路追踪与日志聚合，没有可观测性就不要演进
微服务拆分后，一个请求会横跨多个服务，排查问题最大的障碍就是“不知道请求去了哪里”。所以链路追踪系统是必须的，不是可选项。
我推荐SkyWalking，因为对Java生态侵入性小，支持自动埋点，配合Prometheus做指标监控，再汇聚到Grafana做可视化。日志方面，用ELK或者Loki做集中采集。这套可观测性建设的核心价值在于：出了问题能快速定位到具体服务、具体接口和具体耗时，而不是靠猜。
4. 演进后的性能验证与容量体系：为什么拆完还可能更慢
拆完微服务、把所有流量迁过去之后，很多团队会乘兴做一次压测，得到的结论往往是“还不如单体”。这个结论本身不奇怪，因为微服务架构的初始性能天然比单体差，毕竟多了网络交互和额外的框架开销。但微服务的价值体现在另一个维度：可扩展性。
4.1 单体扩容的边界：即使加机器也有副作用
单体的水平扩展理论上可以加负载均衡器后面挂多台实例，但实际效果有限，原因有二。第一，单体应用是有状态的，用户会话、本地缓存、定时任务在很多实现里都绑定在单台实例上，加机器会引入会话同步问题。第二，即使通过外置化Session解决了状态问题，数据库连接池还是共用一个库，应用实例加得越多，数据库连接压力越大，数据库成为全系统的单点。
微服务不一样，因为服务按领域拆分后，你可以只对瓶颈服务做扩容。比如订单服务压力大，就单独给订单服务加实例，商品服务保持不动，扩容粒度更细，资源利用率自然更高。
4.2 性能不升反降的常见原因及排查方向
如果拆完之后性能确实下降了，先查以下几类问题：
- 服务间调用过于频繁：一次用户操作触发多次远程调用，网络开销被放大。排查方式是看链路追踪里的调用链，统计每个用户请求对应的RPC次数，超过消费预期就要考虑接口合并。
- 序列化方式选择不当：我们早期的JSON序列化在高峰期性能波动明显，后来核心链路换成Protobuf或Hessian之后，性能改善非常明显。
- 网关成为新的瓶颈：如果所有流量都经过网关，网关就变成新的单点。网关本身的吞吐能力要重点压测，必要时可以将网关水平扩容，并开启缓存策略。
- 缓存失效导致的雪崩：拆服务后，如果缓存是各服务各自的JVM缓存，大量缓存同时失效会瞬间把数据库打穿。推荐改用Redis集中缓存，并给缓存设置随机过期时间。
4.3 容量规划：先预测再扩容，别等告警
拆完微服务后，容量规划的思路要随之改变。单体时期是整体扩容，微服务时期是按服务维度预测。通常我做容量规划的方法有两个：
- 历史数据回归：基于监控系统里的历史流量数据，找到业务增长曲线和流量峰谷规律，按季评估下一个高峰期的请求增量。
- 压测建模：使用压测工具（比如JMeter、wrk）对每个核心服务单独压测，得到单实例QPS上限和响应时间曲线，再根据预估峰值计算需要的实例数。
计算公式很简单：所需实例数 = 预估峰值QPS ÷ 单实例可承受QPS × 冗余系数（一般1.5到2）。这里有个经验：单实例压测得到的QPS上限一般比真实场景偏高，因为压测是理想网络环境，真实场景下还要受数据库、网络、下游依赖的影响，所以冗余系数要留足。
5. 我做架构演进以来最后悔的一件事
项目做到后期，我们一共拆了12个业务服务，注册中心、网关、配置中心、链路追踪、监控告警全套都上了。有一次复盘时，我们统计了月度新增代码和月度改动量，发现70%的需求改动仍然集中在那三四个核心服务里，其他服务一个月难得动一次。
这让我反思了一个问题：微服务拆分的收益是不是被高估了？
对于长期稳定、迭代缓慢的模块，微服务带来的独立部署、独立扩展优势基本没有发挥空间，反倒平添了跨服务调用的复杂度和维护成本。正确的判断标准，我认为有三条：第一，这个模块是否有独立的性能扩展需求；第一（应为第二），团队是否有多条业务线可以并行开发互不干扰；第三，这个模块的故障是否值得隔离。
后来我们在第六批服务拆分时，把几个高耦合、低频改动的模块重新合并回核心服务，系统复杂度肉眼可见地降了下来。这也是我想分享给大家的核心经验：架构不是为了拆而拆，可扩展性设计的目标是让系统能在复杂度和性能之间找到最适合当前阶段的平衡点。 单体有单体的好，微服务有微服务的贵，做架构决策前，先算清楚账，比任何先进技术都重要。