nginx break-circus orange api-gateway

Nginx mainly works at layer 7 (application), what you need is something at layer 4 (transport) for this HAProxy could better help to achieve what you need since it can do both HTTP and TCP (db load balancing with HAProxy example)

Probably by using Nginx plus you could also do the same, check this article regarding how to do layer 4 load balancing.

Also look at TCP and UDP load balancing with requires the latest open source Nginx built with the --with-stream configuration flag.

 

---orange-tryout---

?username=llq&password=1234
http://129.0.1.227:8888/httpmd5?uuid=akdflja1299330aa&pjcid=11111&sig= md5(uuid+pjcid+secret key)
akdflja1299330aa11111111111

akdflja1299330aa11111111111

echo -n 'akdflja1299330aa11111111111' | openssl dgst -md5 -hmac '111111'

http://129.0.1.227:8888/httpmd5?uuid=akdflja1299330aa&pjcid=11111&sig=1b04d8da6b7fb39c285b1463842fcd12

---orange-tryout---

 

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的状况等。

 

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