微服务性能优化分为架构层、服务代码层、数据库层、网络通信层、运维基础设施层，同时还要关注微服务特有的痛点：分布式调用开销、服务雪崩、序列化、多实例负载、数据一致性带来的性能损耗。
一、架构层面优化（最核心，解决微服务固有问题）
1. 合理拆分服务，避免过度拆分
拆分原则：按业务域拆分，不是按技术层（不要拆成独立的 Controller 服务、Service 服务）
问题：服务拆分过细会导致大量跨服务 RPC 调用，网络延迟叠加，性能反而比单体差
方案：稳定的内聚业务放一个服务；高频强关联的模块考虑模块内聚，必要时可以局部保留单体模块（宏服务）
2. API 网关层优化
网关是流量入口，很多瓶颈在这里：
网关做限流、熔断、降级、黑白名单，防止下游服务被打挂（Sentinel、Spring Cloud Gateway、APISIX）
网关聚合接口：前端一次请求需要调用多个微服务时，由网关 / BFF 层聚合，减少前端多次请求（BFF 后端为前端模式）
静态资源、缓存直接在网关返回，不转发到后端服务
网关集群水平扩容，避免单点瓶颈
3. 服务治理：熔断、降级、隔离、超时控制
微服务最大性能杀手：依赖服务慢调用导致线程池耗尽
熔断：下游服务异常时快速失败，不持续等待
降级：非核心功能关闭，保留核心链路（例如商品详情关闭推荐、评论，只返回基础商品信息）
线程池隔离：不同下游依赖使用独立线程池，避免一个慢服务拖垮整个服务
统一设置合理超时时间，禁止无限等待
4. 缓存体系建设（收益最高）
分层缓存，减少 RPC 和 DB 访问：
本地缓存（Caffeine、Guava Cache）：热点静态数据，避免远程调用，速度最快；注意多实例缓存一致性问题
分布式缓存（Redis）：共享热点数据，如商品基础信息、配置、字典；做好缓存预热、缓存击穿 / 雪崩 / 穿透防护
CDN：静态资源、大页面缓存
原则：读多写少场景优先缓存，不要让数据库承担热点读流量
5. 异步化，削峰填谷
把非实时逻辑剥离出主链路：
消息队列（RocketMQ/Kafka）：日志、通知、积分、订单后续状态变更等异步处理，缩短主请求 RT
事件驱动架构：业务完成发布事件，其他服务订阅，减少同步 RPC 调用
注意：异步会带来数据一致性复杂度，适合允许最终一致性的场景
二、服务通信优化（微服务大量跨节点调用）
选择高性能 RPC 框架 优先使用基于 HTTP2 / 二进制协议的 RPC：gRPC、Dubbo；相比 HTTP/JSON，序列化体积更小、速度更快。
RESTful 适合对外开放接口；内部服务调用推荐 RPC。
序列化优化
替换 JSON：Protobuf、Hessian2，更小的包体、更快编解码
避免大对象序列化，减少传输字段，只传需要的数据
连接池复用 RPC 客户端维护长连接池，避免每次调用新建 TCP 连接（三次握手开销）；合理设置连接数，不要过大。
批量接口 多次单条 RPC 合并为批量接口，减少网络往返次数（如批量查询列表）
服务发现与负载均衡
使用本地服务发现（客户端负载均衡：Nacos/Eureka），避免中心化 LB 单点
负载均衡策略：优先权重、最小连接数，不要固定轮询；支持就近访问（同机房优先调用）减少跨机房延迟
三、数据库 & 存储优化（性能瓶颈高发区）
微服务核心原则：数据库按业务域隔离，禁止跨服务直接连库，跨服务查数据走 API。
分库分表：单表数据量大时，水平分片（ShardingSphere）
读写分离：主库写，从库读；查询走从库，减轻主库压力
SQL 优化：索引优化，避免大事务、全表扫描、深度分页；禁止多表大 join，复杂查询可放到数仓 / OLAP
冷热数据分离：冷数据归档到对象存储 / OLAP，不要留在业务库
数据库连接池调优：HikariCP，合理最大连接数，防止连接泄露
微服务坑：为了简单直接跨服务查库，带来耦合、锁竞争，后期性能和维护灾难。
四、代码与应用层优化
线程模型调优 SpringBoot/Tomcat 线程池、RPC 线程池参数；区分 IO 密集型和 CPU 密集型。IO 密集型可以适当调大线程；CPU 密集型线程数一般等于 CPU 核心数。
避免阻塞 不要在主线程做同步 IO（文件、外部 HTTP）；非阻塞响应式（WebFlux）适合高 IO 场景，但复杂度更高。
对象复用、减少 GC 压力 减少临时大对象创建，避免频繁 Full GC；JVM 参数调优，选择合适垃圾收集器（G1/ZGC）。
大文件、大报文处理 流式处理，不要一次性把整个报文加载进内存；限制请求 Body 大小，防止 OOM。
五、基础设施 & 可观测性优化
容器资源配置 K8s 中合理设置 CPU/memory request 和 limit，避免资源争抢；热点服务单独节点隔离。
多实例水平扩容 微服务天然支持水平扩展，核心服务多副本；配合 HPA 自动扩缩容应对流量波动。
机房 / 多活部署 同机房调用优先；核心业务做多活，避免单机房故障，同时降低跨机房网络延迟。
监控、链路追踪（APM） SkyWalking/Pinpoint：查看整条链路 RT，定位慢 RPC、慢 SQL；建立指标告警：接口 RT、QPS、错误率、线程池满、GC 耗时。
优化前提：能找到瓶颈点，没有链路追踪很难定位分布式性能问题。
六、微服务常见性能陷阱
同步调用链过长：A→B→C→D，RT 层层叠加 → 解决方案：异步、数据预加载、BFF 聚合
缓存滥用：缓存 key 设计差、缓存过期时间不合理、大 value → 拆分缓存、控制 value 大小
事务滥用：分布式事务（Seata TCC）性能差，非必要不使用，优先最终一致性 + 补偿
重复调用：循环调用 RPC 接口 → 改成批量接口
忽略序列化、网络小包带来的开销
优化优先级建议（落地顺序）
先做监控链路埋点，找到真实瓶颈，不要盲目优化
热点数据增加缓存，收益最高
主链路非实时逻辑异步化
服务治理：超时、熔断、线程隔离，防止雪崩
慢 SQL 优化，数据库读写分离
内部通信切换高性能 RPC，优化序列化
架构重构：BFF、服务重新梳理拆分，消除过长调用链
本文原创作者：易君召，详见：https://www.yijunzhao.cn/authors/yijunzhao，转载请注明出处。
原文链接
欢迎访问 小易撩挨踢