个人水平有限，可能有错，欢迎大家在评论区指正和讨论。
这是我读完王伟杰《从程序员到架构师》的读书笔记。这只是一个总结，真正深入学习，还是推荐读书！

《从程序员到架构师》第三部分：基于常见组件的微服务场景实战

第 8 章 注册发现

1 业务痛点

几十套多语言微服务（Java/Go/Node.js），原始依靠 Nginx 静态配置服务地址，存在 4 大问题：

1. 机器扩容、下线需要手动修改 Nginx，多节点同步配置极易出错；

2. 新增服务实例必须重启 Nginx，影响线上业务；

3. Nginx 存在单点故障，一旦挂掉所有服务调用全部瘫痪；

4. 无自动化服务清单，人工维护成本极高。

2 核心解决方案

核心逻辑：服务启动自动注册至协调中心，客户端监听节点变更，本地做负载均衡，去掉 Nginx 中转。
协调中心选型

• Zookeeper：CP 模型，强一致性，集群选举期间不可用，适合已有 ZK 存量系统；

• Nacos：支持 AP/CP 切换，内置配置中心，新项目首选；

• Eureka：AP 模型，高可用优先，一致性弱，早期 Spring Cloud 方案。
  兜底方案：注册中心宕机时，客户端本地缓存服务列表，新服务启动降级读取静态配置。

3 小节

场景描述：微服务集群机器频繁扩缩容，手动维护 Nginx 配置繁琐、易出错。
解决思路：引入注册发现中间件，服务自动注册下线，客户端实时感知节点变化；
故障兜底：依靠本地缓存，保障注册中心不可用时业务正常调用。

第 9 章 全链路日志

1 业务痛点

微服务多节点跨服务调用，无统一追踪标识，报错 / 超时排查效率极低，分散在多台机器的日志无法串联完整请求流程。

核心需求：

1. 全局唯一 TraceID 贯穿整条请求，覆盖服务、Redis、MQ、数据库等所有调用；

2. 记录每个调用环节耗时、入参、异常堆栈；

3. 支持流量采样、错误日志全量采集，避免海量日志占满存储。

2 方案选型与落地

主流组件：SkyWalking、Zipkin、Jaeger
落地架构：Agent （探针）无埋点采集数据，异步上报服务端，数据存入 Elasticsearch；
基础配置：自定义采样比例、日志自动过期、集群高可用。

3 小节

场景描述：接口响应缓慢，跨多个微服务，无法定位是哪个服务拖慢整体流程。
解决思路：接入全链路追踪系统，通过 TraceID 串联整条请求，查看各环节耗时，快速定位性能瓶颈。

第 10 章 熔断

1 业务故障场景

场景 1：下游第三方接口响应缓慢，上游服务线程池被占满，所有接口阻塞卡死；
场景 2：下游服务宕机、大量请求超时，连锁拖累所有调用方，引发服务雪崩。

2 方案选型与落地

1. Hystrix：Spring Cloud 原生组件，线程池隔离，现已停止迭代；

2. Sentinel：阿里开源，配套可视化控制台，熔断 + 限流一体化，国内企业常用。

核心执行流程：

滑动时间窗口统计请求指标 → 失败率超限打开熔断 → 半开状态试探性调用 → 恢复正常则关闭熔断。

3 小节

场景描述：依赖的下游服务频繁超时，导致自身服务所有接口不可用。
解决思路：引入熔断组件，做资源隔离，触发熔断后执行降级逻辑，阻断故障雪崩。

第 11 章 限流

1 业务场景

秒杀、大促活动产生瞬时海量流量，服务器、数据库承载能力不足，流量洪峰直接打垮系统。限流核心目标：控制系统 QPS，过滤超额无效请求。

2 方案选型与落地

四类限流算法:

1. 固定窗口：存在临界流量突刺缺陷，基本不使用；

2. 滑动窗口：流量平滑，网关常规限流使用；

3. 漏桶：匀速处理流量，不支持瞬时突发；

4. 令牌桶：可预存令牌，适配秒杀突发流量，Guava RateLimiter 实现。

分层限流方案:

1. CDN / 前端：拦截重复刷的无效请求；

2. 网关层限流（最优）：提前拦截流量，不穿透业务服务；

3. 分布式限流：多实例部署时，基于 Redis 统一管控总流量。

3 小节

场景描述：秒杀活动瞬间涌入几十万请求，后端数据库容易被打崩。
解决思路：网关采用令牌桶算法分层限流，超出阈值直接返回提示，保护后端核心服务与数据库。

总结

1. 服务节点频繁扩缩容、静态配置难维护 → 注册发现中心，自动感知上下线；

2. 跨服务接口超时 / 报错，难以定位瓶颈 → 全链路追踪，TraceID 串联整条调用链路；

3. 下游故障引发服务雪崩 → 熔断隔离资源，配置降级逻辑；

4. 大促 / 秒杀瞬时高流量冲垮系统 → 分层限流，令牌桶控制最大 QPS。