为什么想上 Mesh 团队有 30+ 微服务，TLS、重试、熔断这些逻辑散落在每个 Dubbo/Spring Cloud 应用里，升级一次 SDK 全员陪跑。一次熔断规则改版，光是让各服务升级 SDK 就花了两周，还有三个老服务因为没人维护迟迟不动。我们想试试把这部分下沉到基础设施，于是拉了一套 I
注册中心抖动，推送延迟到了 8 秒 去年我们把配置中心/注册中心从 Nacos 1.x 升到 2.0，起因是一次线上抖动：一个服务下线，但网关隔了 8 秒才感知到，期间一大波请求打到了已死的实例。翻 Nacos 1.x 的源码才知道，它用的是客户端 10 秒一次 HTTP 轮询去拉变更，服务端有了新
十一月二十三号：一条 SQL 拖垮了五个服务 那天上午 10:07，监控大屏开始变红。从商品服务开始，10 分钟内波及五个服务，最后整个交易链路不可用，持续 23 分钟。这篇把整个过程复盘一遍，包括我们当时做错的判断。 时间线 时间 事件 10:07 商品服务接口 TP99 从 45ms 涨到 3.
第一次拆分拆错了，我们重做了一版 去年 10 月到今年 2 月，我把单体拆成了 7 个服务。上线稳定运行两个月之后，我自觉地把其中两个又合并了、一个重新划了边界。 原因说出来很打脸：我们造了个 common-service。它承担了字典、地区、短信模板、附件上传、金额计算这些"大家都要用"的能力，被
改了 Nacos 配置页面，服务怎么没反应 "我把限流阈值从 500 改成 200 了，Nacos 上点了发布，等了五分钟还是没生效。" 这是组内被问过最多的一个问题，我自己也卡过。Nacos 同时做注册中心和配置中心，但这两块的机制完全不同——注册是实时的，配置热更新是有条件的。这篇把我们落地 N
32 万行单体，我们用了 5 个月切成微服务，一次没停过机 去年 10 月启动的拆分，到今年 2 月底核心链路切完。这期间系统一天没停过，用户侧没有感知到任何一次发布异常。回过头看，技术选型上没什么新鲜的，真正难的是"怎么一步步把流量搬过去，以及搬错了怎么退回来"。 先说被拆的那个东西 shop-a
群里有人问：ReadTimeout 配了 5 秒，为什么 1 秒就超时 那天下午，新来的同事在企业微信群里贴了一段配置和一段报错： ribbon: ConnectTimeout: 3000 ReadTimeout: 5000 com.netflix.hystrix.exception.Hy
第一次把单体拆出 Dubbo 服务，踩了五个坑 11 月，组里决定把用户中心从订单系统里拆出来，做成独立的 Dubbo 服务。这是我第一次真正搭分布式服务，之前只在本地 demo 里跑过。 技术选型是 Dubbo 2.7.3 + Zookeeper 3.4.14 + Spring Boot 2.1.
