本發(fā)明涉及服務(wù)器技術(shù)領(lǐng)域，尤其涉及服務(wù)器的連接控制方法及裝置。

背景技術(shù)：

隨著業(yè)務(wù)的發(fā)展與多樣化，客戶端發(fā)起的業(yè)務(wù)請求也隨之變多。當(dāng)業(yè)務(wù)服務(wù)依賴的資源出現(xiàn)問題，某些服務(wù)實例出現(xiàn)慢響應(yīng)、假死甚至無響應(yīng)的情況。而目前對于上述問題，會繼續(xù)將業(yè)務(wù)請求轉(zhuǎn)發(fā)至該服務(wù)實例上，直至該服務(wù)實例宕機。因此，目前客戶端與服務(wù)端的連接建立因無法及時解決服務(wù)實例響應(yīng)慢，導(dǎo)致業(yè)務(wù)請求響應(yīng)不及時，使得業(yè)務(wù)體驗差。

上述內(nèi)容僅用于輔助理解本發(fā)明的技術(shù)方案，并不代表承認上述內(nèi)容是現(xiàn)有技術(shù)。

技術(shù)實現(xiàn)要素：

本發(fā)明的主要目的在于提供一種服務(wù)器的連接控制方法及裝置，旨在解決目前客戶端與服務(wù)端的連接建立因無法及時解決服務(wù)實例響應(yīng)慢，導(dǎo)致業(yè)務(wù)請求響應(yīng)不及時，使得業(yè)務(wù)體驗差的問題。

為實現(xiàn)上述目的，本發(fā)明提供的一種服務(wù)器的連接控制方法，包括步驟：

在停止轉(zhuǎn)發(fā)服務(wù)請求至服務(wù)實例后，將預(yù)設(shè)數(shù)量的請求訪問轉(zhuǎn)發(fā)至所述服務(wù)實例上；

在所述服務(wù)實例正確響應(yīng)轉(zhuǎn)發(fā)的請求時，恢復(fù)轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上；

在所述服務(wù)實例未響應(yīng)轉(zhuǎn)發(fā)的請求時，保持停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。

優(yōu)選地，所述將預(yù)設(shè)數(shù)量的請求訪問轉(zhuǎn)發(fā)至所述服務(wù)實例上之后，還包括：

確定響應(yīng)的請求的數(shù)量；

計算確定的數(shù)量在預(yù)設(shè)數(shù)量中所占的比例；

在計算的比例大于預(yù)設(shè)比例閾值時，判定所述服務(wù)實例能正確響應(yīng)轉(zhuǎn)發(fā)的請求。

優(yōu)選地，所述方法還包括：

獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息；

判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件；

在所述鏈接信息滿足預(yù)設(shè)的斷開條件后，停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。

優(yōu)選地，所述判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件包括：

從所述連接信息中提取發(fā)生鏈接錯誤請求的數(shù)量；

在所述鏈接錯誤的數(shù)量大于預(yù)設(shè)的第一數(shù)量閾值時，判定所述鏈接信息是否滿足預(yù)設(shè)的斷開條件。

優(yōu)選地，所述判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件包括：

從所述鏈接信息中提取發(fā)生鏈接超時請求的數(shù)量；

在所述鏈接超時的數(shù)量大于預(yù)設(shè)的第二數(shù)量閾值時，判定所述鏈接信息是否滿足預(yù)設(shè)的斷開條件。

此外，為實現(xiàn)上述目的，本發(fā)明還提供一種服務(wù)器的連接控制裝置，包括：

控制模塊，用于在停止轉(zhuǎn)發(fā)服務(wù)請求至服務(wù)實例后，將預(yù)設(shè)數(shù)量的請求訪問轉(zhuǎn)發(fā)至所述服務(wù)實例上；

恢復(fù)模塊，用于在所述服務(wù)實例正確響應(yīng)轉(zhuǎn)發(fā)的請求時，恢復(fù)轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上；

所述控制模塊，還用于在所述服務(wù)實例未響應(yīng)轉(zhuǎn)發(fā)的請求時，保持停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。

優(yōu)選地，所述裝置還包括：

確定模塊，用于確定響應(yīng)的請求的數(shù)量；

計算模塊，用于計算確定的數(shù)量在預(yù)設(shè)數(shù)量中所占的比例；

判斷模塊，用于在計算的比例大于預(yù)設(shè)比例閾值時，判定所述服務(wù)實例能正確響應(yīng)轉(zhuǎn)發(fā)的請求。

優(yōu)選地，裝置還包括：

獲取模塊，用于獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息；

判斷模塊，用于判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件；

所述控制模塊，還用于在所述鏈接信息滿足預(yù)設(shè)的斷開條件后，停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。

優(yōu)選地，所述判斷模塊，包括：

判斷單元，用于從所述連接信息中提取發(fā)生鏈接錯誤請求的數(shù)量；

判定單元，用于在所述鏈接錯誤的數(shù)量大于預(yù)設(shè)的第一數(shù)量閾值時，判定所述鏈接信息是否滿足預(yù)設(shè)的斷開條件。

優(yōu)選地，所述判斷單元，還用于從所述鏈接信息中提取發(fā)生鏈接超時請求的數(shù)量；

所述判定單元，還用于在所述鏈接超時的數(shù)量大于預(yù)設(shè)的第二數(shù)量閾值時，判定所述鏈接信息是否滿足預(yù)設(shè)的斷開條件。

本發(fā)明通過對斷開后的服務(wù)實例進行測試，在服務(wù)實例正確響應(yīng)轉(zhuǎn)發(fā)的請求后，快速的恢復(fù)轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上，充分利用資源，提高業(yè)務(wù)體驗。

附圖說明

圖1為本發(fā)明服務(wù)器的連接控制方法的第一實施例的流程示意圖；

圖2為本發(fā)明一實施例中判斷服務(wù)實例是否正確響應(yīng)請求的流程示意圖；

圖3為本發(fā)明服務(wù)器的連接控制方法的第二實施例的流程示意圖；

圖4為本發(fā)明一實施例中判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件的流程示意圖；

圖5為本發(fā)明另一實施例中判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件的流程示意圖；

圖6為本發(fā)明一實施例中斷開計算的示意圖；

圖7為本發(fā)明服務(wù)器的連接控制方法的第三實施例的流程示意圖；

圖8為本發(fā)明一實施例中客戶端與服務(wù)端業(yè)務(wù)請求的架構(gòu)示意圖；

圖9為本發(fā)明一實施例中服務(wù)實例斷開的示意圖；

圖10為本發(fā)明服務(wù)器的連接控制裝置的第一實施例的功能模塊示意圖；

圖11為本發(fā)明服務(wù)器的連接控制裝置的第二實施例的功能模塊示意圖；

圖12為圖10中判斷模塊一實施例的細化功能模塊示意圖。

本發(fā)明目的的實現(xiàn)、功能特點及優(yōu)點將結(jié)合實施例，參照附圖做進一步說明。

具體實施方式

下面將結(jié)合本發(fā)明實施例中的附圖，對本發(fā)明實施例中的技術(shù)方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本發(fā)明的一部分實施例，而不是全部的實施例?；诒景l(fā)明中的實施例，本領(lǐng)域普通技術(shù)人員在沒有作出創(chuàng)造性勞動前提下所獲得的所有其他實施例，都屬于本發(fā)明保護的范圍。

參照圖1，圖1為本發(fā)明服務(wù)器的連接控制方法的第一實施例的流程示意圖。

在一實施例中，所述服務(wù)器的連接控制方法包括：

步驟S10，在停止轉(zhuǎn)發(fā)服務(wù)請求至服務(wù)實例后，將預(yù)設(shè)數(shù)量的請求訪問轉(zhuǎn)發(fā)至所述服務(wù)實例上；在服務(wù)實例滿足斷開條件斷開后，需要對該服務(wù)實例的斷開狀態(tài)實時監(jiān)控，以盡快利用該服務(wù)實例進行業(yè)務(wù)服務(wù)。所述設(shè)定時間可以是2分鐘或3分鐘等。在間隔設(shè)定時間后，將預(yù)設(shè)數(shù)量的請求訪問轉(zhuǎn)發(fā)至所述服務(wù)實例上，即，將少量的請求訪問轉(zhuǎn)發(fā)至所述服務(wù)實例上用以測試該服務(wù)實例是否正常，能夠及時響應(yīng)服務(wù)請求。所述預(yù)設(shè)數(shù)量為80條或50條等，根據(jù)服務(wù)實例的性能設(shè)置。

步驟S20，在所述服務(wù)實例正確響應(yīng)轉(zhuǎn)發(fā)的請求時，恢復(fù)轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上；在所述服務(wù)實例正確響應(yīng)轉(zhuǎn)發(fā)的請求時，正常向所述服務(wù)實例轉(zhuǎn)發(fā)服務(wù)請求，恢復(fù)所述服務(wù)實例的使用。

具體的，參考圖2，判斷服務(wù)實例正確響應(yīng)轉(zhuǎn)發(fā)的請求的過程包括：

步驟S11，確定響應(yīng)的請求的數(shù)量；在將預(yù)設(shè)數(shù)量的請求轉(zhuǎn)發(fā)至該服務(wù)實例上后，監(jiān)測正確轉(zhuǎn)發(fā)的請求的數(shù)量，即，確定響應(yīng)的請求的數(shù)量。

步驟S12，計算確定的數(shù)量在預(yù)設(shè)數(shù)量中所占的比例；計算正確轉(zhuǎn)發(fā)的請求的數(shù)量和占比。

步驟S13，在計算的比例大于預(yù)設(shè)比例閾值時，判定所述服務(wù)實例能正確響應(yīng)轉(zhuǎn)發(fā)的請求。所述預(yù)設(shè)比例閾值可以是80％或60％等。在能正確轉(zhuǎn)發(fā)的請求占預(yù)設(shè)數(shù)量的比例達到所述預(yù)設(shè)比例閾值時，判定所述服務(wù)實例能正確響應(yīng)轉(zhuǎn)發(fā)的請求。在本發(fā)明其他實施例中，也還可以是根據(jù)正確轉(zhuǎn)發(fā)的請求的數(shù)量來判定所述服務(wù)實例能正確響應(yīng)轉(zhuǎn)發(fā)的請求。所述預(yù)設(shè)數(shù)量的請求不是一次性轉(zhuǎn)發(fā)至服務(wù)實例，而是間隔或者持續(xù)的轉(zhuǎn)發(fā)至服務(wù)實例，且計算的周期不限定，只要響應(yīng)的請求達到條件(比例或數(shù)量)后，判定所述服務(wù)實例能正確響應(yīng)轉(zhuǎn)發(fā)的請求。

步驟S30，在所述服務(wù)實例未響應(yīng)轉(zhuǎn)發(fā)的請求時，保持停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。在所述服務(wù)實例未響應(yīng)轉(zhuǎn)發(fā)的請求時，繼續(xù)停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上，直至測試成功后，才正常向服務(wù)實例轉(zhuǎn)發(fā)請求，在間隔一定時間(5分鐘或10分鐘等)后，提示服務(wù)實例故障，需進行檢修。本實施例通過對斷開后的服務(wù)實例進行測試，在服務(wù)實例正確響應(yīng)轉(zhuǎn)發(fā)的請求后，快速的恢復(fù)轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上，充分利用資源，提高業(yè)務(wù)體驗。

進一步地，參考圖3，本發(fā)明方法還包括：

步驟S40，獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息；

在本實施例中，預(yù)設(shè)一個檢測周期，該檢測周期可以是50s或60s等，為了節(jié)省系統(tǒng)資源，所述檢測周期可以是3分鐘或5分鐘，為了提高檢測頻率，及時發(fā)現(xiàn)問題，所述檢測周期可以設(shè)置為20s或30s，客戶端向服務(wù)器端發(fā)起業(yè)務(wù)請求，獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息，該鏈接信息包括鏈接成功信息和鏈接失敗信息，所述鏈接失敗信息包括鏈接超時和鏈接錯誤。在每觸發(fā)檢測時，獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息。每個檢測周期間可以根據(jù)性能需求和業(yè)務(wù)需求進行時間間隔的設(shè)置，例如，為5分鐘或8分鐘等。每間隔該時間間隔進行一個周期的檢測。

步驟S50，判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件；

在獲取到一個檢測周期內(nèi)的鏈接信息后，判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件。具體的，在本發(fā)明一較佳實施例中，參考圖4，判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件的包括：

步驟S51，從所述連接信息中提取發(fā)生鏈接錯誤請求的數(shù)量；所述鏈接信息包括但不限于鏈接錯誤信息和鏈接超時以及鏈接成功等信息。在獲取到鏈接信息后，從所述連接信息中提取發(fā)生鏈接錯誤請求的數(shù)量，即，提取有多少請求發(fā)生了鏈接錯誤，將所述鏈接錯誤的數(shù)量與預(yù)設(shè)的第一數(shù)量閾值比對，所述預(yù)設(shè)的第一數(shù)量閾值為提前設(shè)置，例如，為20條或200條，根據(jù)該檢測周期內(nèi)發(fā)起的業(yè)務(wù)請求數(shù)量設(shè)置，例如，請求數(shù)量為200條，則第一數(shù)量閾值設(shè)置為40條或50條，例如，請求數(shù)量為500條，則第一數(shù)量閾值設(shè)置為100或120條。

步驟S52，在所述鏈接錯誤的數(shù)量大于預(yù)設(shè)的第一數(shù)量閾值時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。該檢測周期內(nèi)鏈接錯誤的數(shù)量大于預(yù)設(shè)的第一數(shù)量閾值時，判定所述鏈接信息是否滿足預(yù)設(shè)的斷開條件。在本發(fā)明其他實施例中，也可以是計算鏈接錯誤所占的比例，在鏈接錯誤的比例達到預(yù)設(shè)比例值(20％或25％等)時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。

在本發(fā)明一較佳實施例中，參考圖5，判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件的還可以是：

步驟S53，從所述鏈接信息中提取發(fā)生鏈接超時請求的數(shù)量；在獲取到鏈接信息后，從所述連接信息中提取發(fā)生鏈接超時請求的數(shù)量，即，提取有多少請求發(fā)生了鏈接超時，將所述鏈接超時的數(shù)量與預(yù)設(shè)的第二數(shù)量閾值比對，所述預(yù)設(shè)的第二數(shù)量閾值為提前設(shè)置，例如，為30條或300條，根據(jù)該檢測周期內(nèi)發(fā)起的業(yè)務(wù)請求數(shù)量設(shè)置，例如，請求數(shù)量為200條，則第二數(shù)量閾值設(shè)置為60條或70條，例如，請求數(shù)量為400條，則第二數(shù)量閾值設(shè)置為120或140條。

步驟S54，在所述鏈接超時的數(shù)量大于預(yù)設(shè)的第二數(shù)量閾值時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。該檢測周期內(nèi)鏈接超時的數(shù)量大于預(yù)設(shè)的第二數(shù)量閾值時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。在本發(fā)明其他實施例中，也可以是計算鏈接錯誤所占的比例，在鏈接錯誤的比例達到預(yù)設(shè)比例值(20％或25％等)時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。

在本發(fā)明其他實施例中，可以是將從鏈接信息中提取發(fā)生鏈接錯誤和鏈接超時的總數(shù)量，在總數(shù)量大于一個閾值(總請求為100條，閾值為60條；或總請求為300條，閾值為200條，根據(jù)需求和服務(wù)實例性能設(shè)置)時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。同樣也可以從比例考慮，在比例超過25％或30％甚至20％時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。在斷開判斷過程中，本實施例采用的算法為，每次請求對應(yīng)的時間點(Ticker)設(shè)置為1，在計算單位時間內(nèi)的counter計數(shù)的話，如圖6，想計算某個時間段的計數(shù)，只需要當(dāng)前時間和前面時間的Ticker，去掉不在這個Ticker范圍的數(shù)據(jù)，做個計數(shù)即可，這樣的計算沒有任何鎖，性能非常高，例如，運用在鏈接信息的計算和counter。

步驟S60，在所述鏈接信息滿足預(yù)設(shè)的斷開條件后，停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。

在所述鏈接信息滿足預(yù)設(shè)的斷開條件后，停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上，即，斷開所述服務(wù)實例，所述服務(wù)實例不再接收服務(wù)轉(zhuǎn)發(fā)。本實施例通過對服務(wù)實例的鏈接信息進行監(jiān)控，根據(jù)所述鏈接信息判斷是否滿足預(yù)設(shè)的斷開條件，在滿足時，斷開該服務(wù)實例，停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。通過對服務(wù)實例及時進行斷開，避免目前客戶端與服務(wù)端的連接建立因無法及時解決服務(wù)實例響應(yīng)慢，導(dǎo)致業(yè)務(wù)請求響應(yīng)不及時，使得業(yè)務(wù)體驗差的問題，使得業(yè)務(wù)請求及時響應(yīng)，提高業(yè)務(wù)體驗。

為了保證服務(wù)請求得到及時響應(yīng)，且避免資源的浪費，在本發(fā)明一較佳實施例中，參考圖7，所述方法還包括：

步驟S70，確定所述服務(wù)實例在一個檢測周期內(nèi)觸發(fā)的請求轉(zhuǎn)發(fā)次數(shù)；在進入檢測周期時，確定所述服務(wù)實例在這個檢測周期內(nèi)觸發(fā)的請求次數(shù)，該觸發(fā)的請求包括失敗和成功的請求，即，所有轉(zhuǎn)發(fā)至所述服務(wù)實例的請求。

步驟S80，在所觸發(fā)的轉(zhuǎn)發(fā)次數(shù)小于預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值時，進入下一檢測周期請求轉(zhuǎn)發(fā)次數(shù)的確定；所述預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值根據(jù)服務(wù)實例性能和用戶需求設(shè)置，例如，可以是200條或2000條等。在確定觸發(fā)的請求轉(zhuǎn)發(fā)次數(shù)后，將所觸發(fā)的轉(zhuǎn)發(fā)次數(shù)小于預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值比對。

步驟S40，在所觸發(fā)的轉(zhuǎn)發(fā)次數(shù)大于或等于預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值時，獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息；

步驟S50，判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件；

步驟S60，在所述鏈接信息滿足預(yù)設(shè)的斷開條件后，停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。在所觸發(fā)的轉(zhuǎn)發(fā)次數(shù)大于或等于預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值時，才獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息；在所觸發(fā)的轉(zhuǎn)發(fā)次數(shù)小于預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值時，不執(zhí)行獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息。在本發(fā)明一實施例中，預(yù)設(shè)一時間，例如，為1分鐘或30s等，在該時間內(nèi)，判斷觸發(fā)該服務(wù)實例的請求次數(shù)是否達到一定值，例如，為200或300條，在達到時，進入檢測周期，獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息。優(yōu)選地，設(shè)定檢測的服務(wù)類別，只對該服務(wù)類別的鏈接信息進行監(jiān)控和記錄，而對該設(shè)定的服務(wù)類別之外的其他類別不計入檢測周期內(nèi)的鏈接信息。

為了更好的描述本發(fā)明實施例，參考圖8，為客戶端與服務(wù)端業(yè)務(wù)請求架構(gòu)，在檢測周期內(nèi)，如果服務(wù)實例的鏈接錯誤或者服務(wù)實例超時達到預(yù)定的閥值，則OSP Proxy(OSP代理)將觸發(fā)熔斷機制，后續(xù)OSP Proxy特定時間內(nèi)將不在轉(zhuǎn)發(fā)請求到該服務(wù)實例將上OSP Proxy在服務(wù)熔斷后，每隔一定的恢復(fù)時長后，OSP Proxy將允許小量的請求訪問被熔斷的服務(wù)。如果服務(wù)實例又正確響應(yīng)，則OSP Proxy恢復(fù)服務(wù)的正常訪問，如果服務(wù)實例依然無法正確響應(yīng)，則OSP Proxy再間隔特定的時間內(nèi)不在轉(zhuǎn)發(fā)請求到該服務(wù)實例將上。熔斷機制控制在服務(wù)的訪問接口上；熔斷機制默認是關(guān)閉的，如需使用則必須在配置中心配置相關(guān)的參數(shù)，這些參數(shù)都是可以動態(tài)改變，OSP Proxy無需重啟；配置中心的配置參數(shù)是基于服務(wù)級別，多個服務(wù)實例共享，多個接口共享；OSP Proxy需要上報針對服務(wù)實例的熔斷狀態(tài)，Mercury路由可以在查看服務(wù)的時候獲知相關(guān)的OSP Proxy的熔斷情況

若從Available Instances可用服務(wù)實例選擇的instance服務(wù)實例錯誤率達到熔斷的策略，則把該Instance移到CircuitBreak Instances熔斷實例里面；系統(tǒng)后端對每個CircuitBreak Instance都有一個Scheduler調(diào)度程序觸發(fā)把它移到Half-Open Instance半斷開實例里面；若Half-Open狀態(tài)的Instance成功調(diào)用，則放回Available Instance里面。在Half-Open狀態(tài)的Service Instances處理過程中，需要考慮并發(fā)問題，比如并發(fā)調(diào)用的時候，一個調(diào)用成功，一個調(diào)用失敗。具體的，參考圖9，當(dāng)ServiceB服務(wù)器B的instance3服務(wù)實例3發(fā)生較大錯誤率，達到熔斷需要，則把instance3熔斷，不影響Client客戶端的調(diào)用。在熔斷了Instance3后，由于ServiceB只剩下Instance1服務(wù)實例1，Instance2服務(wù)實例2，則壓力會增加，此時需要進行告警，以免發(fā)生雪崩效應(yīng)；若以后引入Docker應(yīng)用引擎容器化后，可以動態(tài)的增加Instace4服務(wù)實例4來緩解壓力，同時隔離Instance3以便查問題。

本發(fā)明進一步提供一種服務(wù)器的連接控制裝置。

參照圖10，圖10為本發(fā)明服務(wù)器的連接控制裝置的第一實施例的功能模塊示意圖。

在一實施例中，所述服務(wù)器的連接控制裝置包括：控制模塊10、恢復(fù)模塊20、確定模塊30、計算模塊40和判斷模塊50。

所述控制模塊10，用于在停止轉(zhuǎn)發(fā)服務(wù)請求至服務(wù)實例后，將預(yù)設(shè)數(shù)量的請求訪問轉(zhuǎn)發(fā)至所述服務(wù)實例上；在服務(wù)實例滿足斷開條件斷開后，需要對該服務(wù)實例的斷開狀態(tài)實時監(jiān)控，以盡快利用該服務(wù)實例進行業(yè)務(wù)服務(wù)。所述設(shè)定時間可以是2分鐘或3分鐘等。在間隔設(shè)定時間后，將預(yù)設(shè)數(shù)量的請求訪問轉(zhuǎn)發(fā)至所述服務(wù)實例上，即，將少量的請求訪問轉(zhuǎn)發(fā)至所述服務(wù)實例上用以測試該服務(wù)實例是否正常，能夠及時響應(yīng)服務(wù)請求。所述預(yù)設(shè)數(shù)量為80條或50條等，根據(jù)服務(wù)實例的性能設(shè)置。

所述恢復(fù)模塊20，用于在所述服務(wù)實例正確響應(yīng)轉(zhuǎn)發(fā)的請求時，恢復(fù)轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上；在所述服務(wù)實例正確響應(yīng)轉(zhuǎn)發(fā)的請求時，正常向所述服務(wù)實例轉(zhuǎn)發(fā)服務(wù)請求，恢復(fù)所述服務(wù)實例的使用。

所述確定模塊30，用于確定響應(yīng)的請求的數(shù)量；在將預(yù)設(shè)數(shù)量的請求轉(zhuǎn)發(fā)至該服務(wù)實例上后，監(jiān)測正確轉(zhuǎn)發(fā)的請求的數(shù)量，即，確定響應(yīng)的請求的數(shù)量。

所述計算模塊40，用于計算確定的數(shù)量在預(yù)設(shè)數(shù)量中所占的比例；計算正確轉(zhuǎn)發(fā)的請求的數(shù)量和占比。

所述判斷模塊50，用于在計算的比例大于預(yù)設(shè)比例閾值時，判定所述服務(wù)實例能正確響應(yīng)轉(zhuǎn)發(fā)的請求。所述預(yù)設(shè)比例閾值可以是80％或60％等。在能正確轉(zhuǎn)發(fā)的請求占預(yù)設(shè)數(shù)量的比例達到所述預(yù)設(shè)比例閾值時，判定所述服務(wù)實例能正確響應(yīng)轉(zhuǎn)發(fā)的請求。在本發(fā)明其他實施例中，也還可以是根據(jù)正確轉(zhuǎn)發(fā)的請求的數(shù)量來判定所述服務(wù)實例能正確響應(yīng)轉(zhuǎn)發(fā)的請求。所述預(yù)設(shè)數(shù)量的請求不是一次性轉(zhuǎn)發(fā)至服務(wù)實例，而是間隔或者持續(xù)的轉(zhuǎn)發(fā)至服務(wù)實例，且計算的周期不限定，只要響應(yīng)的請求達到條件(比例或數(shù)量)后，判定所述服務(wù)實例能正確響應(yīng)轉(zhuǎn)發(fā)的請求。

所述控制模塊10，還用于在所述服務(wù)實例未響應(yīng)轉(zhuǎn)發(fā)的請求時，保持停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。在所述服務(wù)實例未響應(yīng)轉(zhuǎn)發(fā)的請求時，繼續(xù)停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上，直至測試成功后，才正常向服務(wù)實例轉(zhuǎn)發(fā)請求，在間隔一定時間(5分鐘或10分鐘等)后，提示服務(wù)實例故障，需進行檢修。本實施例通過對斷開后的服務(wù)實例進行測試，在服務(wù)實例正確響應(yīng)轉(zhuǎn)發(fā)的請求后，快速的恢復(fù)轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上，充分利用資源，提高業(yè)務(wù)體驗。

參考圖11，所述裝置還包括：獲取模塊60，

所述獲取模塊60，用于獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息；

在本實施例中，預(yù)設(shè)一個檢測周期，該檢測周期可以是50s或60s等，為了節(jié)省系統(tǒng)資源，所述檢測周期可以是3分鐘或5分鐘，為了提高檢測頻率，及時發(fā)現(xiàn)問題，所述檢測周期可以設(shè)置為20s或30s，客戶端向服務(wù)器端發(fā)起業(yè)務(wù)請求，獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息，該鏈接信息包括鏈接成功信息和鏈接失敗信息，所述鏈接失敗信息包括鏈接超時和鏈接錯誤。在每觸發(fā)檢測時，獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息。每個檢測周期間可以根據(jù)性能需求和業(yè)務(wù)需求進行時間間隔的設(shè)置，例如，為5分鐘或8分鐘等。每間隔該時間間隔進行一個周期的檢測。

所述判斷模塊50，用于判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件；

在獲取到一個檢測周期內(nèi)的鏈接信息后，判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件。具體的，在本發(fā)明一較佳實施例中，參考圖12，所述判斷模塊50包括：判斷單元51和判定單元52，

所述判斷單元51，用于從所述連接信息中提取發(fā)生鏈接錯誤請求的數(shù)量；所述鏈接信息包括但不限于鏈接錯誤信息和鏈接超時以及鏈接成功等信息。在獲取到鏈接信息后，從所述連接信息中提取發(fā)生鏈接錯誤請求的數(shù)量，即，提取有多少請求發(fā)生了鏈接錯誤，將所述鏈接錯誤的數(shù)量與預(yù)設(shè)的第一數(shù)量閾值比對，所述預(yù)設(shè)的第一數(shù)量閾值為提前設(shè)置，例如，為20條或200條，根據(jù)該檢測周期內(nèi)發(fā)起的業(yè)務(wù)請求數(shù)量設(shè)置，例如，請求數(shù)量為200條，則第一數(shù)量閾值設(shè)置為40條或50條，例如，請求數(shù)量為500條，則第一數(shù)量閾值設(shè)置為100或120條。

所述判定單元52，用于在所述鏈接錯誤的數(shù)量大于預(yù)設(shè)的第一數(shù)量閾值時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。該檢測周期內(nèi)鏈接錯誤的數(shù)量大于預(yù)設(shè)的第一數(shù)量閾值時，判定所述鏈接信息是否滿足預(yù)設(shè)的斷開條件。在本發(fā)明其他實施例中，也可以是計算鏈接錯誤所占的比例，在鏈接錯誤的比例達到預(yù)設(shè)比例值(20％或25％等)時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。

進一步地，所述判斷單元51，還用于從所述鏈接信息中提取發(fā)生鏈接超時請求的數(shù)量；在獲取到鏈接信息后，從所述連接信息中提取發(fā)生鏈接超時請求的數(shù)量，即，提取有多少請求發(fā)生了鏈接超時，將所述鏈接超時的數(shù)量與預(yù)設(shè)的第二數(shù)量閾值比對，所述預(yù)設(shè)的第二數(shù)量閾值為提前設(shè)置，例如，為30條或300條，根據(jù)該檢測周期內(nèi)發(fā)起的業(yè)務(wù)請求數(shù)量設(shè)置，例如，請求數(shù)量為200條，則第二數(shù)量閾值設(shè)置為60條或70條，例如，請求數(shù)量為400條，則第二數(shù)量閾值設(shè)置為120或140條。

所述判定單元52，還用于在所述鏈接超時的數(shù)量大于預(yù)設(shè)的第二數(shù)量閾值時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。該檢測周期內(nèi)鏈接超時的數(shù)量大于預(yù)設(shè)的第二數(shù)量閾值時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。在本發(fā)明其他實施例中，也可以是計算鏈接錯誤所占的比例，在鏈接錯誤的比例達到預(yù)設(shè)比例值(20％或25％等)時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。

在本發(fā)明其他實施例中，可以是將從鏈接信息中提取發(fā)生鏈接錯誤和鏈接超時的總數(shù)量，在總數(shù)量大于一個閾值(總請求為100條，閾值為60條；或總請求為300條，閾值為200條，根據(jù)需求和服務(wù)實例性能設(shè)置)時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。同樣也可以從比例考慮，在比例超過25％或30％甚至20％時，判定所述鏈接信息滿足預(yù)設(shè)的斷開條件。在斷開判斷過程中，本實施例采用的算法為，每次請求對應(yīng)的時間點(Ticker)設(shè)置為1，在計算單位時間內(nèi)的counter計數(shù)的話，如圖6，想計算某個時間段的計數(shù)，只需要當(dāng)前時間和前面時間的Ticker，去掉不在這個Ticker范圍的數(shù)據(jù)，做個計數(shù)即可，這樣的計算沒有任何鎖，性能非常高，例如，運用在鏈接信息的計算和counter。

所述控制模塊20，還用于在所述鏈接信息滿足預(yù)設(shè)的斷開條件后，停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。

在所述鏈接信息滿足預(yù)設(shè)的斷開條件后，停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上，即，斷開所述服務(wù)實例，所述服務(wù)實例不再接收服務(wù)轉(zhuǎn)發(fā)。本實施例通過對服務(wù)實例的鏈接信息進行監(jiān)控，根據(jù)所述鏈接信息判斷是否滿足預(yù)設(shè)的斷開條件，在滿足時，斷開該服務(wù)實例，停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。通過對服務(wù)實例及時進行斷開，避免目前客戶端與服務(wù)端的連接建立因無法及時解決服務(wù)實例響應(yīng)慢，導(dǎo)致業(yè)務(wù)請求響應(yīng)不及時，使得業(yè)務(wù)體驗差的問題，使得業(yè)務(wù)請求及時響應(yīng)，提高業(yè)務(wù)體驗。

為了保證服務(wù)請求得到及時響應(yīng)，且避免資源的浪費，在本發(fā)明一較佳實施例中，

所述確定模塊30，還用于確定所述服務(wù)實例在一個檢測周期內(nèi)觸發(fā)的請求轉(zhuǎn)發(fā)次數(shù)；在進入檢測周期時，確定所述服務(wù)實例在這個檢測周期內(nèi)觸發(fā)的請求次數(shù)，該觸發(fā)的請求包括失敗和成功的請求，即，所有轉(zhuǎn)發(fā)至所述服務(wù)實例的請求。

所述確定模塊30，還用于在所觸發(fā)的轉(zhuǎn)發(fā)次數(shù)小于預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值時，進入下一檢測周期請求轉(zhuǎn)發(fā)次數(shù)的確定；所述預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值根據(jù)服務(wù)實例性能和用戶需求設(shè)置，例如，可以是200條或2000條等。在確定觸發(fā)的請求轉(zhuǎn)發(fā)次數(shù)后，將所觸發(fā)的轉(zhuǎn)發(fā)次數(shù)小于預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值比對。

獲取模塊60在所觸發(fā)的轉(zhuǎn)發(fā)次數(shù)大于或等于預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值時，獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息；判斷模塊50判斷所述鏈接信息是否滿足預(yù)設(shè)的斷開條件；控制模塊20在所述鏈接信息滿足預(yù)設(shè)的斷開條件后，停止轉(zhuǎn)發(fā)服務(wù)請求至所述服務(wù)實例上。在所觸發(fā)的轉(zhuǎn)發(fā)次數(shù)大于或等于預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值時，才獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息；在所觸發(fā)的轉(zhuǎn)發(fā)次數(shù)小于預(yù)設(shè)轉(zhuǎn)發(fā)次數(shù)閾值時，不執(zhí)行獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息。在本發(fā)明一實施例中，預(yù)設(shè)一時間，例如，為1分鐘或30s等，在該時間內(nèi)，判斷觸發(fā)該服務(wù)實例的請求次數(shù)是否達到一定值，例如，為200或300條，在達到時，進入檢測周期，獲取服務(wù)實例在一個檢測周期內(nèi)的鏈接信息。優(yōu)選地，設(shè)定檢測的服務(wù)類別，只對該服務(wù)類別的鏈接信息進行監(jiān)控和記錄，而對該設(shè)定的服務(wù)類別之外的其他類別不計入檢測周期內(nèi)的鏈接信息。

為了更好的描述本發(fā)明實施例，參考圖8，為客戶端與服務(wù)端業(yè)務(wù)請求架構(gòu)，在檢測周期內(nèi)，如果服務(wù)實例的鏈接錯誤或者服務(wù)實例超時達到預(yù)定的閥值，則OSP Proxy(OSP代理)將觸發(fā)熔斷機制，后續(xù)OSP Proxy特定時間內(nèi)將不在轉(zhuǎn)發(fā)請求到該服務(wù)實例將上OSP Proxy在服務(wù)熔斷后，每隔一定的恢復(fù)時長后，OSP Proxy將允許小量的請求訪問被熔斷的服務(wù)。如果服務(wù)實例又正確響應(yīng)，則OSP Proxy恢復(fù)服務(wù)的正常訪問，如果服務(wù)實例依然無法正確響應(yīng)，則OSP Proxy再間隔特定的時間內(nèi)不在轉(zhuǎn)發(fā)請求到該服務(wù)實例將上。熔斷機制控制在服務(wù)的訪問接口上；熔斷機制默認是關(guān)閉的，如需使用則必須在配置中心配置相關(guān)的參數(shù)，這些參數(shù)都是可以動態(tài)改變，OSP Proxy無需重啟；配置中心的配置參數(shù)是基于服務(wù)級別，多個服務(wù)實例共享，多個接口共享；OSP Proxy需要上報針對服務(wù)實例的熔斷狀態(tài)，Mercury路由可以在查看服務(wù)的時候獲知相關(guān)的OSP Proxy的熔斷情況

若從Available Instances可用服務(wù)實例選擇的instance服務(wù)實例錯誤率達到熔斷的策略，則把該Instance移到CircuitBreak Instances熔斷實例里面；系統(tǒng)后端對每個CircuitBreak Instance都有一個Scheduler調(diào)度程序觸發(fā)把它移到Half-Open Instance半斷開實例里面；若Half-Open狀態(tài)的Instance成功調(diào)用，則放回Available Instance里面。在Half-Open狀態(tài)的Service Instances處理過程中，需要考慮并發(fā)問題，比如并發(fā)調(diào)用的時候，一個調(diào)用成功，一個調(diào)用失敗。具體的，參考圖9，當(dāng)ServiceB服務(wù)器B的instance3服務(wù)實例3發(fā)生較大錯誤率，達到熔斷需要，則把instance3熔斷，不影響Client客戶端的調(diào)用。在熔斷了Instance3后，由于ServiceB只剩下Instance1服務(wù)實例1，Instance2服務(wù)實例2，則壓力會增加，此時需要進行告警，以免發(fā)生雪崩效應(yīng)；若以后引入Docker應(yīng)用引擎容器化后，可以動態(tài)的增加Instace4服務(wù)實例4來緩解壓力，同時隔離Instance3以便查問題。

以上僅為本發(fā)明的優(yōu)選實施例，并非因此限制本發(fā)明的專利范圍，凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結(jié)構(gòu)或等效流程變換，或直接或間接運用在其他相關(guān)的技術(shù)領(lǐng)域，均同理包括在本發(fā)明的專利保護范圍內(nèi)。