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的狀況等。

 

從新恢復正常一旦經過了衡量是否「可用」的驗證，整個系統就恢復到了「正常」狀態，此時須要從新開啓識別「不可用」的策略。就這樣，系統會造成一個循環。