nginx break-circus

upstream : read-timeout,connection-timeout,分级别 500ms,1S,100S,长链接
---颗粒度[每个服务api health-check]---
---
openresty---lua--rest--dynamic upstream
---traefik--三个出问题了--如何摘掉--
deployment---ds方式--
每类服务的时间---
websocket/io 的部署--放在nginx层，甚至更前面;静态放在cdn,qiniu

服务器剩余空间检查-----------运维老师负责
剩余空间不足，直接影响考试提交，因此应保证剩余空间至少在
做定时任务，只保留半年内的导出考试答卷包文件

服务器配置信息检查，请按下面建议配置参数配置或核查：-----------运维老师负责
1.jvm 配置参数 最大不要超过4G， GC log, 指定GC类型 并行
JAVA_OPTS="-Xms4096m -Xmx4096m -XX:-PrintGCDetails -Xloggc:/data/logs/tomcat/sso/gc_tomcat.log"
2. server.xml配置线程
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-" maxThreads="512" minSpareThreads="256" maxQueueSize="300" maxIdleTime="60000" />
3. 数据库
db.main.initialPoolSize=64
db.main.minPoolSize=64
db.main.maxPoolSize=256

除现有基本日志信息外，还需要服务器增加如下日志信息-----------运维老师负责
nginx 要求配置request_time和upstream response time
mysql 慢查询日志

熔断怎么做
首先，需秉持的一个中心思想是：量力而行。因为软件和人不同，没有奇迹会发生，什么样的性能撑多少流量是固定的。这是根本。

然后，这四步走分别是：

定义一个识别是否处于“不可用”状态的策略

切断联系

定义一个识别是否处于“可用”状态的策略，并尝试探测

重新恢复正常

定义一个识别是否处于“不正常”状态的策略
相信软件开发经验丰富的你也知道，识别一个系统是否正常，无非是两个点。

是不是能调通

如果能调通，耗时是不是超过预期的长

这个标准可以有两种方式来指定。

阈值。比如，在10秒内出现100次“无法连接”或者出现100次大于5秒的请求。

百分比。比如，在10秒内有30%请求“无法连接”或者30%的请求大于5秒。

切断联系
切断联系要尽可能的“果断”，既然已经认定了对方“不可用”，那么索性就默认“失败”，避免做无用功，也顺带能缓解对方的压力。

分布式系统中的程序间调用，一般都会通过一些RPC框架进行。

那么，这个时候作为客户端一方，在自己进程内通过代理发起调用之前就可以直接返回失败，不走网络。

这就是常说的「fail fast」机制。就是在前面提到的代码段之前增加下面的这段代码。

定义一个识别是否处于“可用”状态的策略，并尝试探测
切断联系后，功能的完整性必然会受影响，所以还是需要尽快恢复回来，以提供完整的服务能力。这事肯定不能人为去干预，及时性必然会受到影响。那么如何能够自动的识别依赖系统是否“可用”呢？这也需要你来定义一个策略。

一般来说这个策略与识别“不可用”的策略类似，只是这里是一个反向指标。

阈值。比如，在10秒内出现100次“调用成功”并且耗时都小于1秒。

百分比。比如，在10秒内有95%请求“调用成功”并且98%的请求小于1秒。

同样包含「时间窗口」、「阈值」以及「百分比」。

稍微不同的地方在于，大多数情况下，一个系统“不可用”的状态往往会持续一段时间，不会那么快就恢复过来。所以我们不需要像第一步中识别“不可用”那样，无时无刻的记录请求状况，而只需要在每隔一段时间之后去进行探测即可。所以，这里多了一个「间隔时间」的概念。这个间隔幅度可以是固定的，比如30秒。也可以是动态增加的，通过线性增长或者指数增长等方式。

这个用代码表述大致是这样。

复制代码
全局变量 successCount = 0;
//有个独立的线程每隔10秒（时间窗口）重置为0。
//并且将下面的isHalfOpen设为false。

全局变量 isHalfOpen = true;
//有个独立的线程每隔30秒（间隔时间）重置为true。

//do some thing...
if(success){
if(isHalfOpen){
successCount ++;
if(successCount = 可用阈值){
isOpenCircuitBreaker = false;
}
}

return success;
}
else{
errorcount++;
if(errorcount == 不可用阈值){
isOpenCircuitBreaker = true;
}
}
复制代码

另外，尝试探测本质上是一个“试错”，要控制下“试错成本”。所以我们不可能拿100%的流量去验证，一般会有以下两种方式：

放行一定比例的流量去验证。

如果在整个通信框架都是统一的情况下，还可以统一给每个系统增加一个专门用于验证程序健康状态检测的独立接口。这个接口额外可以多返回一些系统负载信息用于判断健康状态，如CPU、I/O的情况等。

重新恢复正常
一旦通过了衡量是否“可用”的验证，整个系统就恢复到了“正常”状态，此时需要重新开启识别“不可用”的策略。就这样，系统会形成一个循环。