TWI644571B - 一種多重分流策略的負載平衡分流器及其方法 - Google Patents

Abstract

本案是由一種服務最佳化的電腦系統及其方法所分割之案件，主要包含有：一分流器，提供多重分流機制以提供更適合請求分派及更佳的負載平衡，其策略包括有：最新版本分流、依指定版本、依服務範疇分流、依請求處理總筆數最少、依待請求總筆數最少、依服務平台記憶體存量最多等等分流策略。

Description

一種多重分流策略的負載平衡分流器及其方法

本發明係一種服務最佳化的電腦系統及其方法之分割案，目前以爪哇程式語言企業版(Java 2 Platform,Enterprises Edition，J2EE)實現該方法(但不限定任何程式語言)，運用於雲端技術，平台即服務(PaaS)Platform as a Service。

分散式系統有很多不同的定義，一般認為：“一個分散式系統是一些獨立的電腦集合，但是對這個系統的用戶來說，系統就像-臺電腦一樣。”這個定義有兩方面的含義：第一，從硬體角度來講，每台電腦都是自主的；第二，從軟體角度來講，用戶將整個系統看做是-臺電腦。這兩者都是必需的，缺一不可。雲端運算Cloud Computing的本質其實就是分散式運算Distributed Computing。以習知的架構而言是由一循環分流器做為負載平衡器，將請求以輪替分式分派到應用伺服器(AP Sever)，進言之，負載平衡演算法包括有：Least Connection為依照連線數來判斷，連線數越少代表該主機負載越低；Weighted Least Connection與Least Connection相同，但是會再依據權重來做調整。Round Robin以輪替式的方式做負載平衡，例如有三台真實主機，第一條連線導至第一台真實主機，第二條連線導至第二台真實主機，第三條連線導至第三台真實主機，第四條連線導至第一台真實主機，依此類推；Weighted Round Robin與Round Robin相同，但是會再依據權重來做調整；Source Hash以來源IP位址做為判斷負載狀況，當客戶端主機連線至Virtual Server時，會使用客戶端主機的來源位址經由Hash函式，算出應由後端真實主機接受服務，而將連線導至該真實主機。而一般運行於應用伺服器的程式架構是以MVC架構為基礎，即將一程式分為視圖層(View)及控制層(Controller)、商務邏輯層(BusinessLogic)及資料儲存層(DAO)而為了維持分散式系統提供最佳化維運服務，尚有以下議題。

1.熱部署(Hot Deployment，Hot Swap)：即模組程式更新時，系統不須停機，提供同樣服務。一般系統程式開發皆以MVC架構為基礎，而視圖層(View)依規範，可自動重新編譯，更新而不須重新開機故不須考量；若將控制層設計為模組之單一入口，撰寫該模組共用且極少更動之功能；則控制層亦不需因修改而部署，而最常須要更動之程式為商務邏輯層(BusinessLogic)，資料存取層(DAO)及其他相關檔案，故須解決熱部署之問題為此部分之程式。

1.1目前雖然J2EE有所謂熱部署(Hot Deployment)的機制，可用以減少版本更新時的停機時間，但使用者仍須重新登入；又由於一般設計、開發時將各獨立模組(子系統)合為臺模組，以致於熱部署時，整個系統需要重新啟動，因重新部署之程式太多而造成記憶體不足已致於無法運作(當機)(註：模組有時亦稱為子系統，為功能之集合；臺模組為多個獨 立模組(子系統)由同一個會談(Session)存取)。

1.2已知相似之發明尚有如中國申請號CN201010114369实現软件***热部署的方法及***，其所提出之發明方法包括：(1)在軟體系統中設置用以處理核心業務的第一業務處理引擎和第二業務處理引擎，該第一業務處理引擎連接對應的第一業務規則儲存單元，第二業務處理引擎連接對應的第二業務規則儲存單元；(2)設置第一業務處理引擎和第二業務處理引擎的其中之一為運行狀態，另一個處於等待狀態；(3)當軟體系統的處理設置發生變化時，更新處於等待狀態的業務處理引擎對應的處理設置；及(4)將處於等待狀態的業務處理引擎設定為運行狀態，並將原處於運行狀態的業務處理引擎設定為等待狀態。

簡言之是以切換的方式來解決實現熱部署，但與本案之方法不同。

1.4在中國專利申請號為为200610123883.0的中提到一種實現熱部署的方法，就是將升級前的伺服器進行備份，同時對外提供服務，等升級完畢後再切換到升級後的web伺服器，從而對外表現為熱部署。但這種實現熱部署的方法需要提供兩台伺服器來實現熱部署。其不適之處有以下兩點。

1.4.1將整個伺服器備份為另一個伺服器來實現熱部署的方法，需要增設新的伺服器，由此增加成本。

1.4.2引入開放式服務閘道架構來實現熱部署，需要將模式層設置在開放式服務閘道架構的各個子模組當中，當模式層發生改變時，雖然web應用的類載入器能夠實現熱部署，但是開放式服務閘道架構的各個子模組同樣需要重新啟動，不能完全意義上實現熱部署。而且，需要對現有的系統進行大量的改動，存在穩定性不高，安全性差的問題，只適合在沒有運行的業務系統上適用，不適合現已運行的系統上的應用(引用申請號CN201010114369之論述)。

2.除熱部署外，部署後之議題尚有二，新舊版本是否應同時並存，或只執行最新版本。

3.容錯應用，一個單元或資源(軟體或硬體)的故障或部署不影響其他資源的正常功能。故應該在部署時提供量化式部署(即可使臺模組分割後、量化為各自獨立之模組，即以一類別載入器一模組的方式部署)。

4.為使系統之運行環境免於因部署，或因其他因素如：請求量迅增、某一請求不當執行等因素造成系統記憶體存量不足以致系統無法運作，故應提供監控機制以防止此一問題發生並且使模組可即插即用、自動擴充以保全系統之運行。

5.更佳之分散方式應可將商務邏輯層(BusinessLogic)及資料存取層(DAO)再予以分散至其他電腦，且能配合當代主流開發架構完成分散運算。

6.習知系統架構皆是設計以一循環(Round-Robin)分流器，將請求以輪替的方式分派至應用伺服器，因無足夠之資訊，以致無法更精準達到負載平衡，以Least Connection為例，若一連線帶有大量資料處理，則Least Connection之負載平衡並不準確；再以Round Robin為例，若主機有兩台，而請求所需處理的筆數依序為100筆，10筆，100筆，10筆，就會造成分派不均的情況。

7.應能提供特定族群專屬之執行環境(如專屬之CPU或CPU之核心、記憶體空間)。

8.應能提供系統開發人員分類管理模組並升級模組程式庫之功能。

本案的目的在於提供一種服務最佳化的電腦系統及其方法，即能對一般使用者提供多重分流以達更佳之負載平衡，亦能對系統開發人員提供熱部署(包括模組的新增、移除以及修改)、以及熱備援以達永續服務的系統，以及良善模組分類管理功能。

本案主要以分流器及服務平台之組合而提供一種服務最佳化的電腦系統，分流器之結構為一選擇器、一平台註冊中心、一網路伺服器；服務平台之結構為一量化式部署器、一模組過載保全機制、一零請求監控機制、一熱部署監控機制、一資訊記錄器、一服務平台目錄、一請求過載保全機制及一網路伺服器。

分流器藉由平台註冊中心所提供的服務平台資訊及模組資訊以提供分流策略達成更佳之負載平衡；服務平台提供保全機制使得於部署及請求時，免於因服務平台記憶體存量不足而無法運作，而且以量化式(熱)部署器部署模組以縮短部署時間，並加入一訊息通知器以同步服務平台資訊及模組資訊於平台註冊中心，使分流器得以運用熱部署模組名稱關連相同功能之模組及版本，以分流策略中最新版本分流方式達成永續服務；並於分流器中加入一平台監控機制以提供熱備援機制及服務平台中加入一模組程式庫優先機制、一模組分類管理機制以達成服務最佳化的電腦系統。接下來，以實施方式藉由介紹分流器結構及其運作方式，所提供的相關機制及功能；服務平台結構及其運作方式，所提供的相關機制及功能，並透過請求過程說明分流器及服務平台如何達成永續服務及服務最佳化的理由。

第一圖：是分散式系統架構及運作示意圖。

第二圖：是分流器結構及其運作示意圖。

第三圖：是服務平台結構及運作示意圖。

第四圖：是服務平台目錄結構圖。

第五圖：是請求過程及請求保全機制運作示意圖。

請參考第一圖：分散式系統架構及運作示意圖，此圖是藉由習知的元件及開發架構加以改良而成。習知的元件包括有：一網路應用程式(客戶端)、一循環分流器(Round-Robin)(伺服端)、一網路伺服器(伺服端)，並將本案所發明之元件分流器及服務平台分別安裝在個別的網路伺服器，以及將習知開發架構的非視圖層及控制層的程式及相關檔案移至服務平台執行，而成為分散式系統架構，並提供服務最佳化的電腦系統。其能提供服務最佳化的理由有以下七點。

一、提供服務平台記憶體存量管控機制，以保全系統運作。

二、提供多種分流策略，以達更精準的負載平衡。

三、提供特定族群專屬之執行環境(如專屬之CPU或CPU之核心、記憶體空間)。

四、提供自動即時(熱)備援之機制，增強系統之服務，以保全系統運作。

五、提供模組分類管理功能並升級模組程式庫之功能。

六、提供服務不中斷(熱部署及請求時皆能保全系統運作，但有瞬時即逝的暫停服務)。

七、提供永續之服務(熱部署及請求時皆能保全系統運作且持續服務)。而能實現上述之功能，主要為本案所發明之元件：一分流器及一服務平台。

請參考第二圖：分流器結構及其運作示意圖，分流器，包含有：一選擇器、一平台註冊中心、一平台監控機制及網路伺服器(習知元件)。

1.選擇器：用以依分流策略，分派請求。

2.平台註冊中心：用以提供登錄或同步服務平台及模組資訊之記錄。

3.平台監控機制：用以監控服務平台狀態，並依設定自動啟動備援服務平台。

4.網路伺服器：用以安裝並啟動分流器，以使分流器可接收請求，為一習知元件。

5.運作方式：藉由網路伺服器之啟動，讀取分流器配置檔各參數值(請參考分流器配置檔說明)，並啟動分流器，創建選擇器及平台註冊中心以待服務平台及模組註冊，於註冊完成後，啟動平台監控機制，等待請求。

註：網路伺服器為一上位概念，為一可接收請求的伺服器或容器，可為應用伺服器，EJB容器等等。

請參考第三圖：服務平台結構及其運作示意圖，服務平台，包含有：一模組管理員，包含有：1.量化式部署機制、2.模組程式庫優先機制、3.模組過載保全機制、4.零請求監控機制、5.熱部署監控機制、6.資訊記錄器、7.訊息通知器、8.模組委任機制、9.請求過載保全機制(請求超時超量保全機制及請求量迅增保全機制)，及一網路伺服器(習知元件)。

1.模組管理員：

1.1.量化(細粒化)部署機制：用以進行各種模式的部署(請參考部署模式 說明)，使設計者可依模組功能或數量，規劃出獨立的模組(單一功能至多個功能)，其用意在於使系統之各功能模組可依相互獨立，完全窮盡(MECE)的思考原則下設計，促使各模組獨立，以利移植、安裝並縮短啟動時間。

1.2.模組程式庫優先機制：用以優先取得不同版本之相同程式庫，相較於存在共用程式庫目錄下相同程式庫，有利於讓新模組得以使用新版程式庫部署而不影響原系統運作，有助於系統技術升級。

1.3.模組過載保全機制：用以保全服務平台免於部署時因服務平台記憶體存量不足而無法運行。

1.4.零請求監控機制：用以防止因模組需要重新部署或移除而中斷尚在執行中之請求。

1.5.熱部署監控機制：用以監控運行中之模組及模組目錄之相關檔案異動以及模組之新增，並調用量化式部署機制完成熱部署。

1.6.資訊記錄器：用以提供於量化式部署機制及熱部署監控機制記錄平台資訊及模組資訊。

1.6.1平台資訊，包含有：服務平台名稱、狀態、服務平台記憶存量、服務平台位址、服務平台保全定量、模組部署預估量、平台註冊中心位址、請求過載保全定量、請求期限定量、及模組監控間隔時間。

1.6.2模組資訊，包含有：模組名稱(實體名稱)、版本、模組狀態、類別載入器、待請求總筆數、待請求處理總筆數、熱部署模組名稱(邏輯名稱)、模組實際部署所需量等資訊。

1.7.訊息通知器：用以向平台註冊中心登錄及同步服務平台及模組資訊，由量化式部署機制、熱部署監控機制及請求過載保全機制所觸發。

1.8.模組委任機制：用以將請求委任該模組執行請求。

1.9.請求過載保全機制：用以保全系統免於因請求過載而無法運行。

2.網路伺服器(習知元件)：用以安裝並啟動服務平台，以使服務平台可接收請求。

3.運作方式：藉由網路伺服器之啟動讀取服務平台配置檔各參數值(請參考服務平台配置檔說明)，依初始化部署(流程)，完成模組之初始化而成為運行中之模組，並同步服務平台及模組資訊於資訊記錄器(平台/模組)，之後啟動熱部署監控機制，以執行監控部署(流程)，而完成服務平台之啟動。啟動後，等待客戶端請求或觸發訊息通知器藉由平台註冊中心位址登錄服務平台及模組資訊，並使分流器利用服務平台位址與該服務平台建立連結，而完成服務平台及模組的註冊，等待由分流器分派請求。

註：服務平台之網路伺服器可由分流器啟動或人工啟動；分流器與服務平台亦可安裝於同一台網路伺服器，為分散系統之緣故而分別安裝於不同之網路伺服 器。

接下來說明服務平台的初始化部署(流程)、監控部署(流程)、請求過程以及保全機制，並藉此說明服務最佳化的各點理由。

請參考第三圖：服務平台結構及其運作示意圖、第四圖：服務平台目錄結構圖。

1.初始化部署(流程)：量化式部署機制依部署模式在系統目錄下的平台目錄，依序搜尋各模組(即第三圖中系統目錄/平台目錄下之MA、MB、MC、MD)並依目錄層次及目錄名稱之關係及服務平台名稱創建各模組的名稱，之後以模組程式庫優先機制建立各模組檔案資訊(依序為模組程式集合、熱部署版本檔案、模組檔案集合、模組程式庫集合以及共用程式庫集合)後，創建各模組之類別載入器，並通過模組過載保全機制之檢核以完成部署，完成後，同步該平台資訊及其所有模組資訊，並啟動熱部署監控機制。

運作狀態說明：

1.1依據服務平台保全定量及模組部署預估量之設定，由模組過載保全機制判斷目前系統記憶體存量是否足以完成部署。

1.1.1若足夠則啟動且設定該模組狀態為啟動中，完成部署後設定模組狀態為運行中(即第三圖中運行中的模組MA、MB、MC、MD)且同步該模組資訊。

1.1.1.1若啟動失敗，則設定該模組狀態為待啟動(由熱部署監控機制再啟動)且同步該模組資訊。

1.1.2若不足夠則不啟動，並設定該模組狀態為待啟動(由熱部署監控機制再啟動)且同步該模組資訊。

註：1.同步平台資訊及模組資訊之對象為資訊記錄器及平台註冊中心。

2.藉由模組程式庫優先機制升級模組程式庫之功能。

2.監控部署(流程)：熱部署監控機制於平台目錄中依序監控搜尋各模組的模組程式集合、模組檔案集合、模組程式庫集合及共用程式庫集合是否異動、或已移除並監控檢查運行中之各模組之模組狀態，藉由量化式部署機制、模組程式庫優先機制、模組過載保全機制及零請求監控機制完成重新部署或移除以及模組之新增，於完成所有模組檢查後，同步該平台資訊及其所有模組資訊，並依模組監控間隔時間再監控。

運作狀態說明：

2.1若該模組狀態待啟動，則依步驟1.1重新部署該模組。

2.2若該模組目錄為新增，則依步驟1.1部署該模組。

2.3若該模組目錄已移除且無請求，則設定模組狀態為待移除且立即 同步該模組資訊後執行移除該模組，完成後，設定模組狀態為已移除立即同步該模組資訊。

2.3.1若有請求則設定該模組狀態為待移除(請求中)且立即同步該模組資訊，於該模組之請求皆已執行完成後(零請求)執行移除該模組，完成後，設定模組狀態為已移除立即同步該模組資訊。

2.4若該模組相關檔案異動且無請求，設定該模組狀態為待更新且立即同步該模組資訊後依步驟1.1重新部署該模組，並於完成部署設定該模組狀態為運行中且立即同步該模組資訊。

2.4.1若有請求則設定該模組狀態為待更新(請求中)且立即同步該模組資訊，使其不得再接受請求，於該模組之請求皆已執行完成後(零請求)，執行該模組之重新部署，並於完成部署設定該模組狀態為運行中且立即同步該模組資訊，以接收請求。

註：藉由監控部署(流程)達成提供服務不中斷。

請參考第五圖：請求過程及請求保全機制運作流程圖。

3.於請求時，選擇器藉由請求資訊(熱部署模組名稱、版本、服務範疇名稱、請求處理筆數、請求內容)之熱部署模組名稱(邏輯名稱)，至平台註冊中心，在相同之熱部署模組名稱中依所設定之分流策略(依最新版、或依指定版本、或依服務範疇、或依待請求處理總筆數最少、或依待請求總筆數最少、或依服務平台記憶體存量存量最多、或依上述分流策略組合)選擇狀態為運行中之模組名稱及服務平台位址。

再將模組名稱、請求內容、請求處理筆數，藉由服務平台位址轉傳至該模組之服務平台，並藉由模組委任機制，以模組名稱於資訊記錄器中，取得該模組執行請求，並將累計請求數及累計請求處理筆數記錄於資訊記錄器中，於請求完成後，扣除該請求筆數及該請求處理筆數，同時取得服務平台記憶存量並將請求結果、待請求處理總筆數、待請求總筆數及服務平台記憶體存量回傳選擇器，同步於平台註冊中心(供下一個請求參考)，最後回傳請求結果。

註：請求處理筆數為請求內容須要商務邏輯處理之筆數。

待請求處理總筆數=累計請求處理筆數加上或扣除該請求處理筆數。

待請求總筆數=累計請求筆數加上或扣除該請求筆數(一般而言，該請求筆數=1)。

若請求筆數為1，而該請求處理筆數可為1至多筆。

註：藉依待請求處理總筆數最少、或依待請求總筆數最少、或依服務平台記憶體存量最多之分流方式達成提供多種分流策略及更精準之負載平衡。

註：藉由依服務範疇之分流方式達成為特定族群提供專屬之執行環境，為服務平台服務範疇，進言之，藉由預先將一服務平台設定供其所執行之 記憶體量及CPU或CPU之核心，若請求資訊中附帶有服務範疇名稱並與服務平台名稱相同，則分派至該服務平台；另一種服務範疇為模組服務範疇，分流方式為將服務範疇名稱與模組名稱比對，找出合適的模組名稱集合(可能一或多個模組名稱)，或再依其他分流策略分派請求。

註：藉由分流策略中依最新版之分流方式，而達成永續之服務，進言之，以第三圖中系統目錄/模組目錄下之MA、MB為例，假設服務平台名稱為S1，若以熱部署模組名稱為MX，將功能相同之兩模組S1.MA及S1.MB建立關連(建立關連方式可採用任何可供記錄的電子檔如：檔案、多層次目錄之名稱等等)，而於S1.MA重新部署前，立即同步模組狀態為待更新，使請求皆由S1.MB完成，於S1.MA完成部署後，同步模組狀態為運行中且其版本為最新版，而使得請求皆由S1.MA完成，待S1.MB亦完成部署並與S1.MA為相同的版本，再依其他分流方式完成請求之分派。

4.保全機制說明：

4.1模組過載保全機制

4.1.1初始化部署時須滿足下列條件：該服務平台記憶體存量須大於該服務平台保全定量+該模組部署預估量，始可部署。

4.1.2監控部署時須滿足下列條件：該服務平台記憶體存量須大於該服務平台保全定量+該模組實際部署所需量，始可部署。

4.2請求過載保全機制

4.2.1請求超時超量保全，設定該服務平台一請求期限定量及請求過載保全定量，於該服務平台的模組委任機制委任該模組執行該請求時，同時啟動一保全監控機制，定期檢查該請求所使用之記憶量，及所花費之時間，若有超時超量則中斷該請求之執行，並回報中斷原因，以保全該服務平台免於因請求過載而無法運行。

4.2.2請求量迅增保全，設定該服務平台一服務平台保全定量，定期與該服務平台記憶體存量相比較，若該服務平台記憶體存量低於所設定的服務平台保全定量，則同步該服務平台狀態為暫停服務，待該服務平台記憶體存量高於所設定之服務平台保全定量時，再同步該服務平台狀態為服務中。

註：藉由4.1及4.2達成服務平台記憶體存量管控機制，保全系統運作。

4.3平台監控機制，依平台監控間隔時間，監控服務平台為服務中之數量，若服務平台之狀態為服務中之量數低於服務平台服務定量時，則啟動備援服務平台啟動設定檔，以達成備援服務平台之自動擴充；若大於或等於服務平台服務定量時則啟動備援服務平台關閉設定檔。

註：藉由4.3達成自動即時(熱)備援之機制，增強系統之服務，保全系統運作。

5.配置檔說明：

5.1分流器配置檔參數說明，包含有：

5.1.1服務平台設定檔：包含各服務平台啟動及關閉檔路徑之記錄。

5.1.2備援服務平台設定檔：包含各備援服務平台啟動及關閉檔路徑之記錄。

5.1.3服務平台服務定量：保全該分散式系統所需服務平台之數量。

5.1.4平台監控間隔時間：提供於平台監控機制再監控平台註冊中心之間隔時間。

5.2服務平台配置檔參數說明，包含有：

5.2.1系統名稱：用以定義系統名稱。

5.2.2系統目錄：如D：\abc\system。

5.2.3服務平台名稱：該服務平台名稱，如：S1。

5.2.4服務平台位址：該服務平台位址，提供分流器連接該服務平台。

5.2.5平台註冊中心位址：提供登錄及同步該服務平台資訊、模組資訊之平台註冊中心的位址。

5.2.6平台目錄名稱：用以定義存放各模組的目錄名稱。

5.2.7部署模式：如部署模式說明。

5.2.8服務平台保全定量：保全服務平台運行之記憶體定量。

5.2.9模組部署預估量：模組部署時，預估所需之記憶體基本量。

5.2.10請求過載保全定量：該服務平台之請求可執行最大記憶體使用量。

5.2.11請求期限定量：該服務平台之請求可執行的最久時間。

5.2.12模組監控間隔時間：提供於熱部署監控機制再監控之間隔時間。

6.部署模式說明：假設一系統目錄(如c：\system)下，有一包含各模組之平台目錄(如：module)，若有一模組，置於一名為MA的目錄，則依不同之部署模式(Module、Package、Operation)，其所呈現之目錄結構層次及其模組名稱(實體名稱)，如下所示：

6.1 Module模式：平台目錄下包含一層目錄，該模組所有相關檔案置於此目錄中，以此方式部署之目錄結構為系統目錄+平台目錄+該模組目錄。如例，則其目錄結構為c：\system\module\MA，該模組之模組名稱為：MA，配合服務平台名稱(若為S1)，則模組名稱為：S1.MA。

6.2 Package模式：平台目錄下包含二層目錄，該模組所有相關檔案置於該模組目錄之第二層目錄，以此方式部署之目錄結構為系統目錄+平台目錄+該模組目錄之第一層目錄+該模組目錄之第二層目錄。如例，則其目錄結構可為c：\system\module\X\MA，該模組之模組名稱則為：X.MA，配合服務平台名稱(若為S1)，則模組名稱為：S1.X.MA。

6.3 Operation模式：平台目錄下包含三層目錄，該模組所有相關檔案置於該模組目錄之第三層目錄，以此方式部署之目錄結構為系統目錄+平台目錄+該模組目錄之第一層目錄+該模組目錄之第二層+該模組目錄之第三 層目錄。如例，則其目錄結構可為c：\system\module\X\Y\MA，該模組之模組名稱則為：X.Y.MA，配合服務平台名稱(若為S1)，則模組名稱為：S1.X.Y.MA。

註：藉由部署模式所提供之多層目錄結構命名模組名稱而達成模組分類管理；亦可以以此建立模組關連的熱部署模組名稱，如以S1.X.1及S2.X.2，即可視為不同平台下X模組的不同版本。

7.服務平台目錄說明(請參考第四圖：服務平台目錄結構圖)：

7.1系統目錄/平台目錄：即服務平台配置檔參數所設定之系統目錄名稱及平台目錄名稱，各模組至於平台目錄中。

7.2模組目錄：為一模組之相關檔案存放目錄。

7.2.1模組程式集合：為該模組之應用程式集合如商業邏輯程式、資料存取物件(DAO)等。

7.2.2熱部署版本檔案：提供設定熱部署模組名稱(邏輯名稱)、版本(註：熱部署模組名稱用以關連相同功能之模組，而視為同一模組；版本用以設定該模組版本)。

7.2.3模組相關檔案目錄：即存放該模組設定檔、多國語言檔等等之目錄。

7.2.4模組檔案集合：為該模組設定檔、多國語言檔等等。

7.2.5模組程式庫目錄：為只提供該模組所需參考程式庫之目錄。

7.2.6模組程式庫集合：為只提供該模組所需參考之程式庫。

7.3共用程式庫目錄：為提供各模組所需參考程式庫之目錄。

7.3.1共用程式庫集合：為提供各模組所需參考之各類程式庫。

8.以上所述僅為本發明之較佳實施例，並將方法(機制)，流程名詞化以便說明，任何名詞之修改但其功能相似或依本發明申請專利範圍所做之均等變化與修飾，皆應屬本發明之涵蓋範圍。

Claims (3)

1. 一種提供多重分流策略的負載平衡分流器，包含有：一選擇器，用以配置分流策略，分派請求，其分流策略之配置，主要有：依服務平台服務範疇、或依服務平台記憶體存量存量最多、或依待請求總筆數最少、或依待請求處理總筆數最少、或上述分流策略之組合、或輔依模組服務範疇、或依最新版本、或依指定版本、或上述之綜合組合；一平台註冊中心，主要以提供服務平台之登錄或服務平台資訊之同步，以提供選擇器分流策略之資訊，或輔以模組資訊之記錄與同步，以達成模組服務範疇、最新版本、指定版本之分流。
2. 如請求項第1項所述的多重分流策略其服務平台或模組資訊之同步的方法，包含：藉由或定期、或不定期之方式、透過網路伺服器傳送平台資訊，包含有：服務平台名稱、狀態、服務平台記憶存量、服務平台位址、服務平台保全定量、模組部署預估量、請求過載保全定量、請求期限定量、及模組監控間隔時間，或模組資訊，包含有：模組名稱(實體名稱)、版本、模組狀態、待請求總筆數、待請求處理總筆數、熱部署模組名稱(邏輯名稱)、模組實際部署所需量；或於請求時，更新/同步請求筆數，請求處理筆數於一平台註冊中心；或於回應時更新/同步服務平台或模組資訊於一平台註冊中心。
3. 如請求項第1項所述之依服務平台服務範疇分流，其達成專屬的執行環境的方法，包含：藉由預先將一服務平台設定其所將執行之記憶體量及CPU或CPU之核心，並使請求資訊中附帶有服務範疇名稱並主要與服務平台名稱比對，輔以模組名稱比對，或再配合其他分流策略，以找出該服務平台以分派請求。