m0_37242314的博客

1、当服务访问量达到一定程度，流量扛不住的时候，该如何处理？2、服务之间相互依赖，当服务A出现响应时间过长，影响到服务B的响应，进而产生连锁反应，直至影响整个依赖链上的所有服务，该如何处理？这是分布式、微服务开发不可避免的问题。我们系统假如是这样的调用图。当G服务出现程序Bug，大流量请求，硬件故障，缓存击穿时，导致服务不可用。进而导致D服务不可用，导致A服务不可用。B、C、D三个服务共享A服务的线程池，当D服务出现故障时，则导致A服务中所有线程池都在等待G服务响应而被阻塞。进而导致A服务不可用。

*** 设置命令执行的超时时间为3000毫秒(5秒)* 如果命令执行超过这个时间，将被标记为超时失败* @return*//*** 熔断器触发的最小请求数量阈值(滚动窗口内)* 只有在20个请求之后，熔断器才会根据错误率判断是否开启* @return*//*** 熔断器开启后的休眠时间(10秒)* 熔断开启后，经过这段时间会允许一个测试请求尝试访问服务* @return*//*** 错误百分比阈值(50%)

MDC（Mapped Diagnostic Context）是日志框架提供的用于跨方法传递上下文信息的工具，特别适合在分布式系统中传递 TraceID、用户信息等公共参数。当前运维监控系统会将超时接口的告警信息发送至企业邮箱，但邮件中未包含Gateway的TraceID，导致在排查分布式链路问题时难以快速定位和追踪。若缺少Gateway组件包，会导致无法捕获和传递TraceID。于是就考虑到自己将traceId 拿到到，利用MDC工具拼接到日志中。如果获取失败（空值），则通过。（推测是项目自定义的键名）