一、限流入门：为什么需要限流？
在微服务架构中，系统可能面临突发流量、恶意攻击或资源耗尽的风险。限流是一种保护机制，通过控制单位时间内的请求数量，确保系统在高负载下依然稳定运行。常用的限流算法包括令牌桶（Token Bucket）、漏桶（Leaky Bucket）和滑动窗口（Sliding Window）。令牌桶允许一定程度的突发流量，而漏桶则强制请求以恒定速率通过。实际开发中，可借助Guava RateLimiter、Redis+Lua脚本或Sentinel等组件实现限流。
1.1 令牌桶算法
令牌桶以固定速率生成令牌并放入桶中，每个请求需要获取一个令牌才能执行。桶内令牌数有限，当请求超过桶容量时，多余的请求被拒绝。这种算法适合处理突发请求，例如秒杀场景。
1.2 漏桶算法
漏桶像一个底部漏孔的水桶，所有请求先进入桶内排队，然后以恒定速率漏出。如果桶已满，新请求会被丢弃。漏桶算法严格控制输出速率，适用于保护下游资源。
二、限流进阶：分布式限流与熔断
在单机环境下，限流相对简单；但在分布式系统中，需要全局协调。常用的方案有：基于Redis的计数器、Sentinel集群流控以及Nginx+Lua。此外，限流常与熔断、降级配合使用。例如当某接口错误率达到阈值时，触发熔断器打开，快速失败，避免级联雪崩。
三、SkyWalking链路追踪入门
Apache SkyWalking是一款开源的APM（应用性能监控）工具，提供分布式链路追踪、服务拓扑分析、指标监控等功能。它采用探针（Agent）方式无侵入地采集请求调用链数据，支持Java、Go、Python等多种语言。SkyWalking的架构包括以下核心组件：OAP服务器（负责分析聚合数据）、Storage（支持Elasticsearch、MySQL等）、UI控制台（展示拓扑图、调用链详情）。
3.1 链路追踪原理
每个请求从入口开始生成一个全局唯一的Trace ID，并在跨服务调用时传递。每个服务内的处理被切分为多个Span，Span记录了操作名称、开始时间、耗时、状态等信息。多个Span通过Trace ID关联，形成完整的调用链。
3.2 SkyWalking快速部署
以Java微服务为例：在启动参数中添加-javaagent:/path/to/skywalking-agent.jar -Dskywalking.agent.service_name=my-service -Dskywalking.collector.backend_service=127.0.0.1:11800，即可自动上报数据。访问SkyWalking UI默认地址http://localhost:8080即可查看拓扑图。
四、限流与链路追踪的实战结合
在实际运维中，限流和链路追踪并非孤立存在。通过SkyWalking的指标和调用链，我们可以反向推导限流策略是否合理。例如，当某个接口频繁触发限流时，SkyWalking会展示该接口的请求量、响应时间分布、错误趋势等。结合这些数据，运维人员可以动态调整限流阈值，而无需停服重启。
4.1 监控限流效果
在SkyWalking自定义告警规则中，可以配置：当某服务接口的限流拒绝数超过预设值时，发送告警通知。同时，在调用链中增加一个自定义标记（如rate_limited=true），方便排查被限流的请求来源。
4.2 实战案例：基于SkyWalking优化限流参数
某电商平台的大促活动中，订单服务出现间歇性超时。通过SkyWalking拓扑图发现，下游库存服务负载过高；打开调用链详情，发现部分请求被Sentinel限流。运维人员将限流阈值从100QPS调整到150QPS，并启用队列等待模式，最终系统稳定运行，且订单成功率从95%提升到99.9%。
五、常见问题与最佳实践
- 限流粒度如何选择？ 建议按接口维度、用户维度或来源IP维度的组合进行精细流控。
- SkyWalking采样与限流数据冲突？ 限流本身会丢弃请求，可能导致SkyWalking采样率过低。解决办法：对限流请求也生成一个特殊的Span，标记为“rejected”，以便统计。
- 如何避免限流影响正常用户？ 采用加权令牌桶，对VIP用户分配更高权重。
- 链路追踪对性能的影响？ SkyWalking采用异步上报，对业务线程影响极小，通常额外消耗<5%的CPU。
六、总结
限流与链路追踪是现代微服务系统稳定性的左膀右臂。限流保护系统不被冲垮，链路追踪则帮助开发人员洞察系统内部状况。通过本文的入门到进阶讲解，你已经掌握了限流的核心算法与实现，以及SkyWalking的部署与实战集成。下一步，建议动手搭建一个实验环境，尝试在Spring Cloud应用中整合Sentinel与SkyWalking，将理论转化为实战经验。记住：只有可观测的限流，才是可靠的限流。