微服务

背景 最近带团队评审一个全新业务线的技术选型，需求大概是：3 个后端 + 2 个前端，预计 18 个月内迭代 8~10 个功能域，QPS 峰值预估 2k 上下（B 端 SaaS）。团队里 3 个人立场几乎一致——"先拆服务，按业务域拆 4

背景： 做中间件研发 10 年，code review 里争议最多、也最容易"各说各对"的，就是异常处理。同一个 catch (Exception e) { log.warn("调用xx失败", e); return fallback; }

一、现象与背景：接口"悄悄变了"，没人通知你 先给一组真实数字。我们团队 11 人，维护 5 个 Java 微服务（订单、库存、支付、营销、结算），Spring Boot 3.1 + JDK 17，网关 Nginx。2024 年 Q4 的三

背景 我 3 年中间件研发下来，发现团队里对「接口变更要不要上版本号」这个问题，几乎没有两个团队答案一样。有的团队所有接口永远 "/v1"，改字段就加个 "Deprecated" 硬扛三年；有的团队每个新需求都开一个 "/v2"、"/v3"

先抛个背景：最近帮几个团队做安全加固，发现一个特别普遍的现象——外部入口有网关、有鉴权、有审计，可一旦流量进了内网，服务之间的调用就像"进了自家小区的门"，基本是裸奔：HTTP 明文、无 token、无签名，谁都能调谁。 我打个比方：这就像

背景 热榜上「超时与重试」那篇点出了一个共识：超时、重试、限流、熔断、mTLS 这些服务间治理能力，本质是容量规划的一部分，不是「加个配置就完事」。但下一个问题立刻浮出来——这些能力到底放在哪一层做？ 我 3 年里带过的团队，至少见过三种流