记一个`MetricFetcher` 在多用户服务8719 端口连接不通导致实时监控没有数据问题

## Issue Description
dashboard 控制台会定时(每秒)去用户服务的8719 端口访问，通过http请求拉取所有机器实例的统计数据文件中的数据(app-demo-metrics.log.2022-02-11)，由于环境是docker 部署的，8719 端口需要重新映射，而很多应用部署人员都忘记了这一步，导致dashboard 控制取到的还是8719 端口，而后部署人员也没再关注。最后就开成了一个问题就是大面积的http 请求超时，最终导致的问题就是正常的机器实例的实时监控数据也未能正常取到。

这个问题发生的原因就是`MetricFetcher` 的工作线程数太少(docker 一般就4核CPU，8 个工作线程)，而机器实例太多。连接超时的时间默认是设置的3 秒。
线程池8 个工作线程，队列2048 的长度。只要多来几次3 秒超时，就会慢慢把8 个工作线程占满。最终导致正常的机器实例发送http 请求的时候，带的时间参数早已经超过5 分钟，获取到的数据也是无效的。

还有一个现象就是在dashboard 刚启动的时候实时监控正常，慢慢的监控数据就会越来越少，最后没有数据，而请求链路可以很清楚的看到实际是有正常QPS 的。

Type: *bug report* or *feature request*

### Describe what happened (or what feature you want)

### Describe what you expected to happen

### How to reproduce it (as minimally and precisely as possible)

1.
2.
3.

### Tell us your environment
sentinel 版本: 1.8.1

### Anything else we need to know?
我这边暂时的解决方案是增加工作线程池(fetchWorker)的线程数，增加定时任务的时间间隔。

```java
public class MetricFetcher {

...

private final long intervalSecond = 3; // 定时任务3 秒提交一次

...

public MetricFetcher() {
int cores = Runtime.getRuntime().availableProcessors() * 2;
long keepAliveTime = 0;

...

// 扩大线程池最大值到100
fetchWorker = new ThreadPoolExecutor(cores, 100,
keepAliveTime, TimeUnit.MILLISECONDS, new ArrayBlockingQueue<>(queueSize),
new NamedThreadFactory("sentinel-dashboard-metrics-fetchWorker"), handler);

...
```

Start by locating the `MetricFetcher` class in the Sentinel dashboard and inspect its `fetchWorker`, queue size, timeout, and three-second scheduling settings. Reproduce the many-instance Docker scenario with an unreachable port, then verify that healthy instances continue returning current real-time monitoring data while timed-out requests are present.

Written by the indexing model from the issue text.