[go: up one dir, main page]

TWI878165B - 智慧選擇方法以及應用此方法的資訊系統平台 - Google Patents

智慧選擇方法以及應用此方法的資訊系統平台 Download PDF

Info

Publication number
TWI878165B
TWI878165B TW113124249A TW113124249A TWI878165B TW I878165 B TWI878165 B TW I878165B TW 113124249 A TW113124249 A TW 113124249A TW 113124249 A TW113124249 A TW 113124249A TW I878165 B TWI878165 B TW I878165B
Authority
TW
Taiwan
Prior art keywords
service
workload
completion time
work
valve
Prior art date
Application number
TW113124249A
Other languages
English (en)
Inventor
陳啓昌
李振忠
曾彥博
林家弘
郭坤平
Original Assignee
廣達電腦股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 廣達電腦股份有限公司 filed Critical 廣達電腦股份有限公司
Priority to TW113124249A priority Critical patent/TWI878165B/zh
Application granted granted Critical
Publication of TWI878165B publication Critical patent/TWI878165B/zh

Links

Images

Landscapes

  • Computer And Data Communications (AREA)

Abstract

提供一種智慧選擇方法,用於資訊系統平台中第一服務呼叫第二服務執行具有多筆工作的服務時決定溝通的方式。前述方法包括:計算第一服務前一次呼叫第二服務的未完成工作量、和第二服務最近完成一筆工作的完成時間;以及,依據未完成工作量、和完成時間,決定第一服務目前呼叫第二服務時,選擇要使用第一方式或第二方式來進行溝通,並將選擇結果通知第一服務。

Description

智慧選擇方法以及應用此方法的資訊系統平台
本發明是關於資訊系統平台之應用,特別在是關於在資訊系統平台中智慧選擇多個服務之間的溝通方式的方法,以及應用此方法的資訊系統平台。
在一個資訊系統平台,是由各個功能服務(亦即,應用程式、或模組功能)所組成,當工作需要平台完成時,平台會串接所需要的功能服務來完成這項工作,而服務之間所使用的串接溝通方式,主流有分成兩大類:(1)表現層狀態轉換應用程式介面(Representational State Transfer Application Programming Interface,簡稱為Restful API)、與(2)訊息佇列(Message Queue)。這兩種方式的特性與適合的使用情境分別簡單地列出如下。
(1) Restful API: 特性:較單純、處理較快、同步呼叫。 適合情境:單位時間內少量工作、以及短時間的工作。 (2) 訊息佇列(Message Queue): 特性:較複雜、處理較慢、非同步呼叫。 適合情境:單位時間內大量工作、以及長時間的工作。
通常,在資訊系統平台的架構設計上,會先依據特性與工作情境決定好每個服務之間的串接溝通方式。參照第1圖,顯示傳統資訊系統平台10的架構。資訊系統平台中10中,包括服務A、服務B、服務C和服務D,以串接的方式連行溝通。第1圖中的符號Task 1、Task2和Task3表示工作。在此示例中,假設在服務A和服務B之間處理的工作Task1、Task2,以及在服務B和服務C之間處理的工作Task2,是屬於單位時間內少量工作、以及短時間的工作,所以資訊系統平台的設計者通常會在服務A和服務B之間和服務B和服務C之間,分別使用Restful API 11的溝通方式。此外,假設在服務C和服務D之間處理的工作Task3須進一步處理的工作Task2是屬於單位時間內大量工作、以及長時間的工作,所以資訊系統平台的設計者通常會在服務C和服務D之間,使用訊息佇列12的溝通方式。
然而,資訊系統平台服務之間的串接溝通方式要使用哪一種方式比較合適,並不是全都是在設計階段就可以決定好的。例如,若設計使用Restful API的溝通方式,當遇到某些工作需要長時間執行時,則可能會因為超過Restful API的暫停(timeout)時間而導致工作沒有成功執行。此外,若設計使用訊息佇列的溝通方式,當工作量不是很多的時候,或者是當某些工作是短時間即可執行完成的時候,則因為Queue排隊執行的特性,會損失速度效能。
基於前述,目前在平台的設計階段,就需要決定好每一個服務之間需要使用哪一種方式來進行溝通,缺少在執行時期的即時動態選擇機制,無法即時動態的使用當下最適合的溝通方式來完成工作。
有鑑於此,為解決前述問題,本發明提供一種機制可以在資訊系統平台的多個服務彼此之間,動態地選擇最合適的溝通方式。
本發明的一實施例提供一種智慧選擇方法,可應用用於資訊系統平台中當第一服務呼叫第二服務執行具有多筆工作的服務時的溝通。此智慧選擇方法,包括:計算第一服務先前呼叫第二服務的未完成工作量、和第二服務最近完成一筆工作的完成時間;以及,依據未完成工作量、和完成時間,決定第一服務目前呼叫第二服務時,選擇要使用第一方式或第二方式來進行第一服務和第二服務之間的溝通,並將選擇結果通知第一服務。
前述實施例的一些樣態中,依據該未完成工作量、和該完成時間來決定該第一方式或該第二方式之步驟,更包括以下決策。(1)當未完成工作量未超過一工作量閥值、且該完成時間未超過完成時間閥值時,選擇第一方式。(2)當未完成工作量未超過該工作量閥值、但完成時間已超過完成時間閥值時,選擇第二方式。(3)當未完成工作量已超過工作量閥值時,選擇該第二方式。
前述實施例一些樣態中,更對多筆工作之任一筆,接收由第一服務傳來的由第二服務執行工作的起始時間、和第二服務透過該第一服務傳來的工作的完成時間,而且進一步利用完成時間和起始時間計算工作完成時間(以下簡稱為“完成時間”),以更新該工作完成時間。
前述實施例一些樣態中,更進一步接收由第一服務傳來的資訊,判斷第一服務的呼叫第二服務所進行的工作是否成功完成。若判斷為成功,則增加該工作量閥值;以及,若判斷不成功,且是以第一方式進行的話,則改以第二方式重新執行第二服務所進行的工作。此外,在以第二方式重新執行工作後,判斷工作是否成功完成。若判斷為成功,則減少該工作量閥值。
本發明的又一實施例提供一種資訊系統平台,包括:第一服務、和第二服務;以及,智慧選擇模組,用於當第一服務呼叫第二服務執行具有多筆工作的服務時,以動態地決定第一服務和第二服務之間的溝通方式。其中,前述智慧選擇模組,執行,包括: 計算第一服務先前呼叫該第二服務的未完成工作量、和第二服務最近完成1筆工作的完成時間;以及,依據未完成工作量、和完成時間,決定第一服務目前呼叫第二服務時,選擇要使用第一方式或第二方式來進行第一服務和第二服務之間的溝通,並將選擇結果通知第一服務。
為使本發明之上述目的、特徵和優點能更明顯易懂,下文特舉較佳實施例,並配合所附圖式,作詳細說明如下。
第2圖顯示本發明實施例之資訊系統平台20的系統架構。第2圖中,資訊系統平台20,包括:第一服務21和第二服務22;以及智慧選擇模組23。第一服務21和第二服務22之間的溝通,可透過Restful API 24(為本發明第一方式的示例)、或訊息佇列25(為本發明的第二示例)之方式來進行溝通。本發明的重點在於,透過智慧選擇模組23即時動態地選擇第一服務21和第二服務22要以Restful API 24或訊息佇列25之方式進行溝通。
本發明的資訊系統平台20,例如為具有處理器或控制器之電腦系統、電子裝置、或伺服器等電子設備,可透過處理器或控制器載入程式並執行,以達成所需的功能。第一服務21和第二服務22,例如為應用程式、或由處理器或控制器執行應用程式後可完成特定功能的模組。第一服務21和第二服務22之間,可具有一或多個實體通道(未圖示),透過智慧選擇模組23,可以選擇要遵照Restful API 24或訊息佇列25,使第一服務21和第二服務22進行溝通。智慧選擇模組23,例如為透過處理器或控制器載入程式並執行,以達成所需的功能。
智慧選擇模組23可包括:計算模組231、選擇模組232、與回饋模組233。計算模組231,計算未完成工作量與判斷是否超過工作量閥值,且計算工作完成時間。選擇模組232,依據計算模組231的結果,來選擇溝通方式(本發明的第一方式或第二方式)。回饋模組233,依據所選擇的溝通方式,以重試第一服務21和第二服務22之間的工作,並且更新記錄。前述計算模組231、選擇模組232、與回饋模組233,例如為透過處理器或控制器載入程式並執行後所形成的功能模組。此外,智慧選擇模組23可以是單一模組,以執行前述計算模組231、選擇模組232、與回饋模組233的所有動作和功能。此外,在一些實施例中,前述智慧選擇模組23、計算模組231、選擇模組232、與回饋模組233,亦可以由特殊應用積體電路(ASIC)、現場可程式化邏輯閘陣列(FPGA)等硬體來實現。
第3圖表示本發明另一實施例的智慧選擇方法30的流程圖。本發明的慧選擇方法,與智慧選擇模組23的動作功能相對應,用於資訊系統平台20中的第一服務21呼叫第二服務22執行具有多筆工作的服務時決定溝通的方式,亦即選擇第一方式(Restful API 24)或第二方式(訊息佇列25)。
第3圖中,本發明的智慧選擇方法30,首先,計算第一服務21先前呼叫第二服務22的未完成工作量、和第二服務22最近完成1筆工作的完成時間(步驟31)。然後,於步驟S32,依據未完成工作量、和完成時間,決定第一服務21目前呼叫第二服務22時,選擇要使用Restful API 24或訊息佇列25,來進行第一服務21和第二服務22之間的溝通。之後,將選擇結果通知第一服務21(步驟S33)。
在此,未完成工量表示,第一服務21前一次已傳送給第二服務22,但第二服務22仍未完成的工作數量。
第4圖顯示本發明的智慧選擇方法30應用至資訊系統平台20時,智慧選擇方法30(由智慧選擇模組23執行)與第一服務21和第二服務22相對應的系統運作概念圖40。以下,將參照第4圖與第2圖,詳細說明第3圖的智慧選擇方法30的更多細節。
參照第4圖,第一服務21傳送工作給第二服務22後,智慧選擇模組23計算第一服務21前一次呼叫第二服務22(亦即傳送工作給第二服務22)之後,第二服務22尚未完成的未完成工作量Count_W、和第二服務22最近完成1筆工作的完成時間Time_W (步驟S41)。接著,判斷未完成工作量Count_W是否超過工作量閥值TH_W(步驟S42)、及判斷工作時間Time_W是否超過完成時間閥值TH_T(步驟S43)。
當未完成工作量Count_W未超過工作量閥值TH_W(步驟S42:否)、且完成時間Time_W未超過完成時間閥值TH_T(步驟S43:否)時,選擇Restful API方式(步驟S44)。
當未完成工作量Count_W未超過該工作量閥值TH_W(步驟S42:否)、但完成時間Time_W已超過完成時間閥值TH_T(步驟S43:是)時,選擇訊息佇列(Message Queue)方式(步驟S45)。此外,當未完成工作量Count_W已超過工作量閥值TH_W(步驟42:是)時,選擇訊息佇列方式(步驟S45)。
接著,第一服務21,依據智慧選擇模組23的選擇結果,使用Rest API 24或訊息佇列25與第二服務22進行溝通。而且,第一服務21透過Rest API 24或訊息佇列25,與第二服務22進行工作上的溝通。
智慧選擇模組23,對多筆工作之任一筆,接收由第一服務21傳來的由第二服務執行該筆工作的一起始時間、和第二服務22透過第一服務21傳來的該筆工作的完成時間,並且寫入起始時間和完成時間(步驟S46)。智慧選擇模組23,可進一步利用該完成時間和該起始時間計算該工作完成時間,以更新完成時間Time_W。
此外,在第一服務21,依據智慧選擇模組23的選擇結果,使用Rest API 24或訊息佇列25與第二服務22進行溝通之後,智慧選擇模組23進一步接收由第一服務21傳來的資訊,判斷該第一服務21呼叫第二服務22所進行的工作是否成功完成(步驟S47)。倘若判斷為成功(步驟S47:是),則增加工作量閥值Count_W。在此,例如,可增加5%~15%, 較佳為增加10%。之後,更新工作量閥值(步驟S50)。
於一些實施例中,智慧選擇模組23可進一步判斷工作時的溝通模式是否為Restful API。如此,倘若是以Restful API進行溝通的話,而且智慧選擇模組23判斷為不成功(步驟S47:否),則改以訊息佇列方式,重新執行第一服務21呼叫第二服務22所進行的工作(步驟S48)。
在此,改為使用訊息佇列的方式重試一次,一方面可以提高工作執行的成功率,以及資訊系統平台20的穩定度。另外一方面因為Restful API溝通方式下,在這未完成的工作量當下會執行失敗,而改用訊息佇列的方式可以執行成功,意謂第二服務22透過Restful API執行工作的工作負荷量,應是該些未完成的工作量以下(亦即無法負荷該些未完成的工作量),所以可以設計將工作量閥值TH_W設為此時未完成的工作量Count_W。
此外,在以訊息佇列方式重新執行工作(步驟S48)之後,智慧選擇模組23判斷工作是否成功完成(步驟S49);若判斷為成功(步驟S49:是),則減少該工作量閥值。在此,例如,可減少5%~15%, 較佳為減少10%。之後,更新工作量閥值(步驟S50)。而若智慧選擇模組23判斷為不成功(步驟S49:否),則發出警示訊息(步驟S51)。
此外,在以訊息佇列方式重新執行工作(步驟S48)時,智慧選擇模組23接收由第一服21務傳來該重新工作的起始時間,以及該第二服務22傳來的該重新工作的完成時間,以更新該(工作)完成時間(步驟S46)。
於前述的實施例中,工作量閥值Count_W的初始值,可以是任意的初始值,可依據實際運行後所累的經驗值來決定。透過本發明的方法,可以逐漸適性地調整至每個服務適合的工作量閥值。此外,完成時間閥值TH_W的初始值為表現層狀態轉換應用程式介面(Restful API)的暫停(timeout)設定值。
為了使本發明的特徵更易明暸,以下茲列舉多各個範例。首先,給定兩個閥值:工作量閥值TH_W,以及完成時間閥值TH_T。設定兩個閥值的初始值:工作量閥值TH_W 例如1000 (可為任意初始值)。;完成時間閥值TH_T為Restful API的暫停(timeout)設定值,例如為60秒。
[情境1] 第一服務21傳送工作給第二服務22時,計算過程為: (1)取得送出給第二服務22,執行中還未完成的工作量Count_W ,例如為100(筆)。計算最近一次送出給第二服務22的工作完成時間 Time_W,例如為20秒。 (2)依據判斷式: If Count_W (100) > TH_W (1000) 選擇 Message Queue else if Time_W (20秒) > TH_T (60秒) 選擇 Message Queue else 選擇 Restful API。 (3)邏輯判斷結果為選擇 Restful API 溝通方式。
假設工作執行成功(步驟S47),則將工作量閥值TH_W增加10% (步驟S50),而且更新工作量閥值TH_W為TH_W×(1+10%)=1100。接著,更新最近一次的工作完成時間 Time_W例如為30秒(步驟S46)。
[情境2] 接續情境1,第1服務21要再傳送給第二服務22工作時,計算過程為: (1)計算送出給第二服務22,執行中還未完成的工作量 Count_W,例如為800(筆)。計算最近一次送出給第二服務22的工作完成時間 Time_W,在此為30秒。 (2)依據判斷式 If Count_W (800) > TH_W (1100) 選擇 Message Queue else if Time_W (30秒) > TH_T (60秒) 選擇 Message Queue else 選擇 Restful API。 (3)邏輯判斷結果為選擇 Restful API 溝通方式。
假設此次工作執行失敗,則使用Message Queue 的方式重試一次(步驟S48),如果重試執行成功(步驟S49),則減少工作量閥值TH_W(步驟S50)。因為工作量閥值TH_W為1100大於此時未完成的工作量Count_W (800),所以更新工作量閥值TH_W成為未完成工作量Count_W=800。更新最近一次的完成時間Time_W。在此為65秒。
[情境3] 接續情境2,第一服務21要再傳送給第二服務22工作,計算過程為: (1)計算送出給第二服務22,執行中還未完成的工作量 Count_Work,例如為700。計算最近一次送出給第二服務22的工作完成時間 Time_W,在此為65秒。 (2)依據判斷式 If Count_W (700) > TH_W (800) 選擇 Message Queue else if Time_W (65秒) > TH_T (60秒) 選擇 Message Queue else 選擇 Restful API。 (3)邏輯判斷結果為選擇 Message Queue 溝通方式,更新最近一次的工作完成時間 Time_W為40秒。
[情境4] 接續情境3,第一服務21要再傳送給第二服務22工作,則計算過程為: (1)計算送出給第二服務22,執行中還未完成的工作量 Count_W,例如為100。計算最近一次送出給第二服務22的完成時間 Time_Work_B為40秒。 (2)依據判斷式 If Count_W (100) > TH_W (800) 選擇 Message Queue else if Time_W (40秒) > TH_T (60秒) 選擇 Message Queue else 選擇 Restful API。 (3)邏輯判斷結果為選擇 Restful API 溝通方式。
假設工作執行成功(步驟S47),則將工作量閥值TH_W增加10%,更新工作量閥值TH_W為TH_W×(1+10%)成為880(步驟S50)。更新最近一次的完成時間 Time_W為 30秒(步驟S46)。
本發明的又一實施例為一種電腦可讀取記錄媒體,儲存有程式,當電腦載入該程式並執行後,可完成如前述智慧選擇方法的所有操作和功能。
依據本發明具有以下的優點和功效: (Ⅰ)不需要在資訊系統平台的設計階段就決定好所有的服務之間要使用哪一種溝通方式。 (Ⅱ)能夠在執行時期依據即時實際狀況,動態決定服務之間最合適的溝通方式。 (Ⅲ)在資訊系統平台的服務忙碌時,超過可承受的工作負荷量時,選擇Message Queue的溝通方式,可以降低工作執行失敗率,追求穩定。 (Ⅳ)在資訊系統平台的服務不忙碌時,選擇Restful API的溝通方式,可以提高處理的效能。 (Ⅴ)讓平台可以依據即時狀況,智慧調整達到平台穩定度高與最佳效能的動態平衡。
10:傳統資訊系統平台 11:Resful API 12:訊息佇列(Message Queue) A~D:服務 Task1~Task3:工作 20:資訊系統平台 21:第一服務 22:第二服務 23:智慧選擇模組 231:計算模組 232:選擇模組 233:回饋模組 24:Restful API 25:訊息佇列(Message Queue) 30:流程圖 S31~S33:步驟 40:系統流程圖 S41~S51:步驟
第1圖顯示傳統資訊系統平台10的架構。 第2圖顯示本發明實施例之資訊系統平台20的系統架構。 第3圖表示本發明另一實施例的智慧選擇方法30的流程圖。 第4圖顯示本發明的智慧選擇方法,應用至資訊系統平台時,智慧選擇方法與第一服務和第2服務相對應的系統運作概念圖。
30:流程圖
S31~S33:步驟

Claims (10)

  1. 一種智慧選擇方法,用於資訊系統平台中一第一服務呼叫一第二服務執行具有多筆工作的服務時決定溝通的方式,包括: 計算該第一服務先前呼叫該第二服務的未完成工作量、和該第二服務最近完成一筆工作的完成時間;以及 依據該未完成工作量、和該完成時間,決定該第一服務目前呼叫該第二服務時,選擇要使用一第一方式或一第二方式來進行該第一服務和該第二服務之間的溝通,並將選擇結果通知該第一服務。
  2. 如請求項1所述之智慧選擇方法,其中 依據該未完成工作量、和該完成時間來決定該第一方式或該第二方式,更包括: 當該未完成工作量未超過一工作量閥值、且該完成時間未超過一完成時間閥值時,選擇該第一方式; 當該未完成工作量未超過該工作量閥值、但該完成時間已超過該完成時間閥值時,選擇該第二方式;以及 當該未完成工作量已超過該工作量閥值時,選擇該第二方式。
  3. 如請求項1所述之智慧選擇方法,其中 對該多筆工作之任一筆,接收由該第一服務傳來的由該第二服務執行該筆工作的一起始時間、和該第二服務透過該第一服務傳來的該筆工作的完成時間。
  4. 如請求項3所述之智慧選擇方法,其中 進一步利用該完成時間和該起始時間計算該工作完成時間,以更新該工作完成時間。
  5. 如請求項1所述之智慧選擇方法,其中 接收由該第一服務傳來的資訊,判斷該第一服務的呼叫該第二服務所進行的工作是否成功完成; 若判斷為成功,則增加該工作量閥值;以及 若判斷不成功,且是以該第一方式進行的話,則改以該第二方式重新執行該第一服務的呼叫該第二服務所進行的工作。
  6. 如請求項5所述之智慧選擇方法, 在以該第二方式重新執行工作後,判斷工作是否成功完成; 若判斷為成功,則減少該工作量閥值。
  7. 如請求項6所述之智慧選擇方法,其中 在以該第二方式重新執行工作後,接收由該第一服務傳來該重新工作的起始時間,以及該第二服務傳來的該重新工作的完成時間,以更新該工作完成時間。
  8. 如請求項1所述之智慧選擇方法,其中 該工作量閥值的初始值為任意值,取決於實際運行後所累的經驗值; 該完成時間閥值的初始值為表現層狀態轉換應用程式介面(Restful API)的暫停(timeout)設定值。
  9. 如請求項5或6所述之智慧選擇方法,其中 增加該工作量閥值或減少該工作量閥值,係增加或減少該工作量閥值的5%~15%,較佳為10%。
  10. 一種資訊系統平台,包括: 一第一服務、和一第二服務,以及 一智慧選擇模組,用於決定該第一服務呼叫該第二服務執行具有多筆工作的服務時的溝通方式; 其中,該智慧選擇模組,執行,包括: 計算該第一服務先前呼叫該第二服務的未完成工作量、和該第二服務最近完成1筆工作的完成時間;以及 依據該未完成工作量、和該完成時間,決定該第一服務目前呼叫該第二服務時,選擇要使用一第一方式或一第二方式來進行該第一服務和該第二服務之間的溝通,並將選擇結果通知該第一服務。
TW113124249A 2024-06-28 2024-06-28 智慧選擇方法以及應用此方法的資訊系統平台 TWI878165B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
TW113124249A TWI878165B (zh) 2024-06-28 2024-06-28 智慧選擇方法以及應用此方法的資訊系統平台

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
TW113124249A TWI878165B (zh) 2024-06-28 2024-06-28 智慧選擇方法以及應用此方法的資訊系統平台

Publications (1)

Publication Number Publication Date
TWI878165B true TWI878165B (zh) 2025-03-21

Family

ID=95830813

Family Applications (1)

Application Number Title Priority Date Filing Date
TW113124249A TWI878165B (zh) 2024-06-28 2024-06-28 智慧選擇方法以及應用此方法的資訊系統平台

Country Status (1)

Country Link
TW (1) TWI878165B (zh)

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200828871A (en) * 2006-12-27 2008-07-01 Univ Nat Taipei Technology A software deployment management system with adjustable process functionality
US20130247034A1 (en) * 2012-03-16 2013-09-19 Rackspace Us, Inc. Method and System for Utilizing Spare Cloud Resources
TW201541281A (zh) * 2014-04-22 2015-11-01 晨星半導體股份有限公司 計算裝置及計算裝置之處理安全服務之方法
US20200226009A1 (en) * 2019-04-02 2020-07-16 Intel Corporation Scalable and accelerated function as a service calling architecture
CN111711694A (zh) * 2020-06-16 2020-09-25 成都卓杭网络科技股份有限公司 一种网络通信处理方法、装置及系统
CN111752723A (zh) * 2020-06-06 2020-10-09 中国科学院电子学研究所苏州研究院 一种可视化的多源服务管理系统及其实现方法
CN111813573A (zh) * 2020-06-29 2020-10-23 中国平安人寿保险股份有限公司 管理平台与机器人软件的通信方法及其相关设备
US20210112640A1 (en) * 2018-09-04 2021-04-15 Lutron Technology Company Llc Communicating with and Controlling Load Control Systems

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TW200828871A (en) * 2006-12-27 2008-07-01 Univ Nat Taipei Technology A software deployment management system with adjustable process functionality
US20130247034A1 (en) * 2012-03-16 2013-09-19 Rackspace Us, Inc. Method and System for Utilizing Spare Cloud Resources
TW201541281A (zh) * 2014-04-22 2015-11-01 晨星半導體股份有限公司 計算裝置及計算裝置之處理安全服務之方法
US20210112640A1 (en) * 2018-09-04 2021-04-15 Lutron Technology Company Llc Communicating with and Controlling Load Control Systems
US20200226009A1 (en) * 2019-04-02 2020-07-16 Intel Corporation Scalable and accelerated function as a service calling architecture
CN111752723A (zh) * 2020-06-06 2020-10-09 中国科学院电子学研究所苏州研究院 一种可视化的多源服务管理系统及其实现方法
CN111711694A (zh) * 2020-06-16 2020-09-25 成都卓杭网络科技股份有限公司 一种网络通信处理方法、装置及系统
CN111813573A (zh) * 2020-06-29 2020-10-23 中国平安人寿保险股份有限公司 管理平台与机器人软件的通信方法及其相关设备

Similar Documents

Publication Publication Date Title
US6230183B1 (en) Method and apparatus for controlling the number of servers in a multisystem cluster
US7165129B1 (en) Method and apparatus for self-tuning transaction batching
US11418550B1 (en) Service-mesh session prioritization
CN114217993A (zh) 线程池拥塞的控制方法、系统、终端设备以及存储介质
JP2009259209A (ja) データ通信制御装置、データ通信制御方法およびそのためのプログラム
WO2023193527A1 (zh) 线程执行方法、装置、电子设备及计算机可读存储介质
TWI878165B (zh) 智慧選擇方法以及應用此方法的資訊系統平台
CN120223700A (zh) 一种私有云智能负载均衡方法、系统、设备及存储介质
US10929191B2 (en) Loading models on nodes having multiple model service frameworks
CN116483549B (zh) 智能相机系统的任务调度方法、装置、相机及存储介质
US8555285B2 (en) Executing a general-purpose operating system as a task under the control of a real-time operating system
JP2001350639A (ja) ソフトリアルタイムにおけるスケジューリング方法
CN102567006A (zh) 应用业务的扩展方法、装置及系统
CA2533773C (en) Transparent session migration across servers
CN121239779A (zh) 智能选择方法以及应用此方法的信息系统平台
CN113900781B (zh) 一种DevOps平台自反馈任务调度方法
CN102595003B (zh) 一种呼叫中心及其实现方法
CN111629056B (zh) 一种网络请求处理方法及应用
CN115118769B (zh) 一种业务系统参数配置、微服务执行方法及装置
CN120123105B (zh) 一种性能调控方法、装置、设备、程序产品及存储介质
JPS6368934A (ja) タスクスケジユ−ル方式
CN119179593B (zh) 大模型服务调用方法、装置和计算机设备
CN118805158A (zh) 处理计算系统中事件的方法和控制器
CN119576546A (zh) 计算节点的管理方法、装置、设备、介质和产品
CN110109760B (zh) 一种内存资源控制方法及装置