組件的分布式部署系統和方法

2023-06-22 09:15:41

專利名稱：組件的分布式部署系統和方法
技術領域：
本發明涉及組件部署技術，具體而言，涉及組件的分布式部署系統和方法。
背景技術：
基於組件編程一直是增強軟體可重用性、擴展性、提高軟體開發效率及質量的一個重要方法，但是對於不同語言、不同平臺往往需要不同的組件模型，不同實現模型的組件間無法直接交互。SCA的目的是使用戶在構建企業應用時有一個不再直接面對具體的技術細節的層次，而是通過服務組件的方式來構建應用。這種方式也使得客戶的企業應用具有良好的分層架構，能夠很好的分離應用的業務邏輯和IT邏輯，不但易於應用的構建，也易於應用的更改和部署。SCA全稱Service Component Architecture，S卩服務組件框架。服務組件體系結構(SCA)是一個規範，它描述用於使用SOA構建應用程式和系統的模型。SCA 可大大簡化使用SOA進行的應用程式開發和實現工作，已成為SOA體系架構中最重要的規範之一。一個組件通常由下列屬性描述服務描述了該類型的組件所能提供的功能；引用描述了該類型的組件相關功能的依賴性；屬性定義了配置參數，控制程序邏輯如何實現，例如，支付服務中使用何種貨幣；策略描述了組件行為策略，主要有兩種策略實現策略對組件實現施加影響，例如事務、監視以及日誌；互動策略定義組件如何互動，例如安全。如圖1所示，一個典型的組件100包括組件屬性102、組件策略、服務106和引用 108。一個組件可以使用任何用戶想要的程式語言去實現，例如用BPEL去實現業務流程控制，XSLT實現轉換，RUBY來編寫腳本，也可以使用純JAVA。這些服務、引用、屬性以及策略如何去定義界定了一個組件的是具體實現類型。組件是最基本的單元，實際企業應用中，很少有如此簡單的業務通過一個單一的組件即可滿足，而是通過將多個組件組裝在一起，形成複合組件，還可以將複合組件和單一組件繼續組合，通過不斷組裝、重用已有組件，形成更大粒度的組件，滿足更高層面、更複雜的業務需求，真正實現軟體人一直追求的搭積木一樣構建應用的夢想。隨著組件被不斷的組裝和復用，組件間隨之產生越來越複雜的依賴關係。最簡單的部署方案就是將這些有依賴關係的組件全部部署在一個伺服器節點上，但隨著組件數量的增多以及不同組件對應用伺服器的要求各有不同，集中部署往往無法保證組件所提供服務的質量(高並發性和高可用性)。此時一般採取的方案是根據組件對伺服器的性能要求，將組件部署到性能指標相匹配的伺服器上，比如做成本運算的組件相比一般網頁檢索的組件來說就需要性能更好的伺服器。另外一種情況則是由於被組裝的組件屬於不同的部門或者組織，處於保護組件版權或者為了便於就近維護和管理組件，以及為了組件能夠就近和本地資料庫及其他遺留系統交互，各部門及組織的組件一般會被部署到本地的伺服器上。基於上述的分析，複雜的有依賴關係的組件在特定的業務場景需要分布部署到不同的伺服器節點上，這就需要解決組件分布式部署的一序列問題，如組件依賴關係分析，透明部署，錯誤恢復等。
SCA規範的參考實現Tuscany項目中通過域管理器，可以系統的管理組件分布式部署。具體配置的時候，物理部署包(contribution)、組件組裝配置文件(composite)、運行節點(Node)、組件組裝配置文件部署配置(Cloud)等均須手工註冊，這不但增加了軟體的運維成本，還容易出錯，即伺服器真正運行的狀態和配置容易出現不一致。另外在組件實例管理方面，現有技術存在一個問題，就是一旦通過域管理器將組件組裝配置文件註冊到特定的運行節點，則節點啟動時，相應的組件實例便被創建，而不是基於組件間的依賴關係去動態創建和啟動相應的組件實例，這就造成有些根本就沒有被引用的組件也會被創建並啟動服務，造成寶貴的伺服器資源浪費。同樣當某個組件停止運行時，其單線依賴的組件實例也不能自動停止服務並銷毀實例，而那些反向依賴此組件的組件也無法做相應的處理(比如也採取停止服務的策略)。此外在分布式環境中，有時根據安全及管理需要會修改伺服器節點的配置，現在的技術框架在處理這類問題時，除了要求人工去重啟部署在被修改配置的伺服器節點上的所有組件，還必須通過人工重啟所有引用了這些組件的其他組件，這些組件可能分布在不同的伺服器節點上，在組件間有複雜依賴關係時，這是一件非常困難的工作，管理成本很高，導致管理員往往會重啟所有伺服器，導致其他本可以正常運行的服務中斷。因此，需要一種新的組件部署技術，可以實現在分布式環境下對有複雜依賴關係的組件的方便部署和對實例的精細化管理，同時實現按需創建和啟動，避免對整體系統的影響。

發明內容
本發明正是基於上述問題，提出了一種新的組件部署技術，可以實現在分布式環境下對有複雜依賴關係的組件的方便部署和對實例的精細化管理，同時實現按需創建和啟動，避免對整體系統的影響。有鑑於此，本發明提出了一種組件的分布式部署系統，包括客戶端、存儲裝置和伺服器，其中，所述客戶端包括第一生成模塊，利用配置完成的組件項目生成組件部署包； 第一通信模塊，連接至所述存儲裝置，用於將部署信息發送至所述存儲裝置，所述部署信息包括所述組件項目的信息、所述組件項目中的至少一個組件的信息、多個組件之間的關聯信息以及所述組件部署包的信息；所述存儲裝置，連接至所述客戶端和所述伺服器，存儲所述部署信息；所述伺服器包括第二通信模塊，連接至所述客戶端，用於接收所述組件部署包；掃描模塊，掃描所述第二通信模塊接收到的所述組件部署包，並獲取所述組件部署包中的組件的狀態屬性；部署模塊，在所述狀態屬性為靜態的情況下，所述組件為靜態組件，將所述靜態組件部署於對應的伺服器節點，在所述狀態屬性為動態的情況下，所述組件為動態組件，將所述動態組件部署於對應的伺服器節點，並將所述組件與所述伺服器節點的對應關係存儲在所述存儲裝置中；創建模塊，為組件創建實例。在該技術方案中，客戶端為組件生成部署包後，由伺服器對包中的組件進行分析，若為靜態組件，則可以自行生成實例， 對系統無影響，若為動態組件，則常常與其他組件有著複雜的依賴關係，需要進行記錄，如將組件的標識與被部署的節點的標識進行關聯後存儲這兩者之間的對應關係，則後續可以通過查詢該對應關係，在相應的節點上創建相應的動態組件實例。同時，通過將組件與節點的對應關係進行存儲，便於在組件出現問題或需要進行檢測、重啟等時，對單個組件或部分組件進行操作，而不必對整個系統進行重啟，減少對其他組件的影響，降低系統的維護成本。在上述技術方案中，優選地，所述客戶端的所述第一通信模塊還用於將所述組件部署包發送至伺服器節點上。在該技術方案中，客戶端在生成部署包後，後續的工作如部署通常由伺服器來完成，並且首先需要伺服器從客戶端獲取其生成的部署包，但也可以由客戶端在生成部署包後，直接將部署包傳輸至需要被部署的節點或其他預定的位置，方便伺服器進行部署操作。在上述技術方案中，優選地，所述伺服器還包括第二生成模塊，為動態組件生成加載器，所述加載器用於加載所述動態組件中的資源。在該技術方案中，伺服器可以在檢測到動態組件後，為其生成加載器，以便對其進行加載，加載過程可以在OSGI (Open Service Gateway Initiative)框架下準確進行。在上述技術方案中，優選地，所述伺服器還包括解析模塊，用於解析組件的配置文件，並對所述組件進行第一判斷，所述第一判斷包括判斷所述組件是否由其他組件構成， 若判斷結果為否，則為所述組件創建實例，若所述判斷結果為是，則進行第二判斷，所述第二判斷包括判斷所述其他組件是否位於本地，若所述其他組件位於本地，則對所述其他組件進行所述第一判斷，若所述其他組件不位於本地，則通過查詢模塊查詢所述存儲裝置中存儲的所述其他組件的部署信息；所述查詢模塊，用於對存儲在所述存儲裝置中的部署信息進行查詢；檢測模塊，根據所述查詢模塊查詢到的所述部署信息，獲取部署有所述其他組件的伺服器節點，並檢測部署於所述伺服器節點上的所述其他組件是否被正常部署，若是， 則通過所述創建模塊為所述其他組件創建實例。在該技術方案中，主要是為靜態組件創建實例的過程，該組件若與其他組件沒有依賴關係，這裡的依賴關係，主要是指該組件是否由其他組件構成，若沒有，則可以直接創建實例，若有依賴關係，如組件A和組件B —同構成了組件C，此時對於組件C而言，其實例的創建需要涉及組件A和組件B，此時應查詢組件A和組件B的位置，若在本地，則從本地進行加載，或不是，則從之前存儲的組件與節點的對應關係中查找其所在的節點，並對其進行查詢。此處的處理方式，主要就是一層一層地，將處於上層構建的組件進行分析，從最底層的組件開始創建實例，並一層層地被上層組件引用。 此外，這裡解析的配置文件位於組件項目中，且每一個組件對應一個配置文件。在上述技術方案中，優選地，在所述創建模塊為所述其他組件創建實例前，還包括所述伺服器通過所述第二通信模塊連接至所述伺服器節點，並通過所述檢測模塊獲取所述伺服器節點上發起調用的實例的標識，然後通過所述查詢模塊查詢存儲在所述存儲裝置中的對應於所述其他組件的部署信息，並獲取與所述其他組件存在調用關係的調用組件的標識，以及所述伺服器還包括比較模塊，所述比較模塊用於比較所述實例的標識和所述調用組件的標識，若所述實例的標識中沒有所述調用組件的標識，則由所述創建模塊為所述調用組件創建實例。在該技術方案中，位於底層的組件可能被多個組件使用，因而一些組件在引用時，該底層組件可能已經被引用過而已經創建了實例，此時該實例可以直接被後來的組件所引用，而對於尚未創建實例的底層組件，則可以在被查詢時進行實例的創建。通過這種查詢方式，可以避免已經創建的實例經歷重複操作，簡化上層組件的實例創建。根據本發明的又一方面，還提出了一種組件的分布式部署方法，包括步驟202， 利用配置完成的組件項目生成組件部署包，並存儲部署信息，所述部署信息包括所述組件項目的信息、所述組件項目中的至少一個組件的信息、多個組件之間的關聯信息以及所述組件部署包的信息；步驟204，掃描所述組件部署包，獲取所述組件部署包中的組件的狀態屬性，若所述狀態屬性為靜態，所述組件為靜態組件，將所述靜態組件部署於對應的伺服器節點，若所述狀態屬性為動態，所述組件為動態組件，將所述動態組件部署於對應的伺服器節點，並存儲所述組件與所述伺服器節點的對應關係。在該技術方案中，客戶端為組件生成部署包後，由伺服器對包中的組件進行分析，若為靜態組件，則可以自行生成實例，對系統無影響，若為動態組件，則常常與其他組件有著複雜的依賴關係，需要進行記錄，如將組件的標識與被部署的節點的標識進行關聯後存儲這兩者之間的對應關係，則後續可以通過查詢該對應關係，在相應的節點上創建相應的動態組件實例。同時，通過將組件與節點的對應關係進行存儲，便於在組件出現問題或需要進行檢測、重啟等時，對單個組件或部分組件進行操作，而不必對整個系統進行重啟，減少對其他組件的影響，降低系統的維護成本。在上述技術方案中，優選地，所述步驟202還包括將所述組件部署包發送至伺服器節點上。在該技術方案中，客戶端在生成部署包後，後續的工作如部署通常由伺服器來完成，並且首先需要伺服器從客戶端獲取其生成的部署包，但也可以由客戶端在生成部署包後，直接將部署包傳輸至需要被部署的節點或其他預定的位置，方便伺服器進行部署操作。在上述技術方案中，優選地，所述步驟204還包括為動態組件生成加載器，所述加載器用於加載所述動態組件中的資源。在該技術方案中，伺服器可以在檢測到動態組件後，為其生成加載器，以便對其進行加載，加載過程可以在OSGI框架下準確進行。在上述技術方案中，優選地，在所述步驟204之後，還包括步驟206，解析組件的配置文件，並對所述組件進行第一判斷，所述第一判斷包括判斷所述組件是否由其他組件構成，若判斷結果為否，則為所述組件創建實例，若所述判斷結果為是，則進行第二判斷，所述第二判斷包括判斷所述其他組件是否位於本地，若所述其他組件位於本地，則對所述其他組件進行所述第一判斷，若所述其他組件不位於本地，則查詢存儲的所述其他組件的部署信息；步驟208，根據所述其他組件的所述部署信息，獲取部署有所述其他組件的伺服器節點，並在檢測到部署於所述伺服器節點上的所述其他組件被正常部署時，為所述其他組件創建實例。在該技術方案中，主要是為靜態組件創建實例的過程，該組件若與其他組件沒有依賴關係，這裡的依賴關係，主要是指該組件是否由其他組件構成，若沒有，則可以直接創建實例，若有依賴關係，如組件A和組件B —同構成了組件C，此時對於組件C而言，其實例的創建需要涉及組件A和組件B，此時應查詢組件A和組件B的位置，若在本地，則從本地進行加載，或不是，則從之前存儲的組件與節點的對應關係中查找其所在的節點，並對其進行查詢。此處的處理方式，主要就是一層一層地，將處於上層構建的組件進行分析，從最底層的組件開始創建實例，並一層層地被上層組件引用。此外，這裡解析的配置文件位於組件項目中，且每一個組件對應一個配置文件。在上述技術方案中，優選地，在所述步驟208中，所述創建實例的過程還包括連接至所述伺服器節點，記錄所述伺服器節點上發起調用的實例的標識，並查詢存儲的對應於所述其他組件的部署信息，獲取與所述其他組件存在調用關係的調用組件的標識，若所述實例的標識中沒有所述調用組件的標識，則為所述調用組件創建實例。在該技術方案中， 位於底層的組件可能被多個組件使用，因而一些組件在引用時，該底層組件可能已經被引用過而已經創建了實例，此時該實例可以直接被後來的組件所引用，而對於尚未創建實例的底層組件，則可以在被查詢時進行實例的創建。通過這種查詢方式，可以避免已經創建的實例經歷重複操作，簡化上層組件的實例創建。通過以上技術方案，可以實現在分布式環境下對有複雜依賴關係的組件的方便部署和對實例的精細化管理，同時實現按需創建和啟動，避免對整體系統的影響。


圖1示出了相關技術的組件的構成示意圖；圖2示出了根據本發明的實施例的組件的分布式部署系統的框圖；圖3示出了根據本發明的實施例的組件的分布式部署方法的流程圖；圖4示出了根據本發明的實施例的組件的分布式部署的示意圖；圖5示出了根據本發明的實施例的客戶端運作的流程圖；圖6示出了根據本發明的實施例的組件的分布式部署的流程圖；圖7示出了根據本發明的實施例的組件依賴關係的示意圖；圖8示出了根據本發明的實施例的伺服器節點通信裝置的框圖；圖9示出了根據本發明的實施例的為組件創建實例的流程圖；圖10示出了根據本發明的實施例的為組件創建實例的流程圖；以及圖11示出了根據本發明的實施例的為組件創建實例的示意圖。
具體實施例方式為了能夠更清楚地理解本發明的上述目的、特徵和優點，下面結合附圖和具體實施方式
對本發明進行進一步的詳細描述。在下面的描述中闡述了很多具體細節以便於充分理解本發明，但是，本發明還可以採用其他不同於在此描述的其他方式來實施，因此，本發明並不限於下面公開的具體實施例的限制。圖2示出了根據本發明的實施例的組件的分布式部署系統的框圖。如圖2所示，根據本發明的實施例的組件的分布式部署系統200，包括客戶端 202、存儲裝置204和伺服器206，其中，所述客戶端包括第一生成模塊208，利用配置完成的組件項目生成組件部署包；第一通信模塊210，連接至存儲裝置204，用於將部署信息發送至存儲裝置204，部署信息包括組件項目的信息、組件項目中的至少一個組件的信息、多個組件之間的關聯信息以及組件部署包的信息；存儲裝置204，連接至客戶端202和伺服器206，存儲部署信息；伺服器206包括第二通信模塊212，連接至客戶端202，用於接收組件部署包；掃描模塊214，掃描第二通信模塊212接收到的組件部署包，並獲取組件部署包中的組件的狀態屬性；部署模塊216，在狀態屬性為靜態的情況下，組件為靜態組件，將靜態組件部署於對應的伺服器節點，在狀態屬性為動態的情況下，組件為動態組件，將動態組件部署於對應的伺服器節點，並將組件與伺服器節點的對應關係存儲在存儲裝置204中； 創建模塊218，為組件創建實例；第二生成模塊220，為動態組件生成加載器，加載器用於加載動態組件中的資源；解析模塊222，用於解析組件的配置文件，並對組件進行第一判斷， 第一判斷包括判斷組件是否由其他組件構成，若判斷結果為否，則為組件創建實例，若判斷結果為是，則進行第二判斷，第二判斷包括判斷其他組件是否位於本地，若其他組件位於本地，則對其他組件進行第一判斷，若其他組件不位於本地，則通過查詢模塊224查詢存儲裝置204中存儲的其他組件的部署信息；查詢模塊224，用於對存儲在存儲裝置204中的部署信息進行查詢；檢測模塊226，根據查詢模塊224查詢到的部署信息，獲取部署有其他組件的伺服器節點，並檢測部署於該伺服器節點上的其他組件是否被正常部署，若是，則通過創建模塊218為其他組件創建實例。在該技術方案中，客戶端202為組件生成部署包後，由伺服器206對包中的組件進行分析，若為靜態組件，則可以自行生成實例，對系統無影響，若為動態組件，則常常與其他組件有著複雜的依賴關係，需要進行記錄，如將組件的標識與被部署的節點的標識進行關聯後存儲這兩者之間的對應關係，則後續可以通過查詢該對應關係，在相應的節點上創建相應的動態組件實例。同時，通過將組件與節點的對應關係進行存儲，便於在組件出現問題或需要進行檢測、重啟等時，對單個組件或部分組件進行操作，而不必對整個系統200進行重啟，減少對其他組件的影響，降低系統的維護成本。在上述技術方案中，客戶端202的第一通信模塊208還用於將組件部署包發送至伺服器節點上。在該技術方案中，客戶端202在生成部署包後，後續的工作如部署通常由伺服器206來完成，並且首先需要伺服器206從客戶端202獲取其生成的部署包，但也可以由客戶端202在生成部署包後，直接將部署包傳輸至需要被部署的節點或其他預定的位置， 方便伺服器206進行部署操作。在上述技術方案中，伺服器206可以在檢測到動態組件後，為其生成加載器，以便對其進行加載，加載過程可以在OSGI (Open Service Gateway Initiative)框架下準確進行。在上述技術方案中，在為靜態組件創建實例的過程，該組件若與其他組件沒有依賴關係，這裡的依賴關係，主要是指該組件是否由其他組件構成，若沒有，則可以直接創建實例，若有依賴關係，如組件A和組件B —同構成了組件C，此時對於組件C而言，其實例的創建需要涉及組件A和組件B，此時應查詢組件A和組件B的位置，若在本地，則從本地進行加載，或不是，則從之前存儲的組件與節點的對應關係中查找其所在的節點，並對其進行查詢。此處的處理方式，主要就是一層一層地，將處於上層構建的組件進行分析，從最底層的組件開始創建實例，並一層層地被上層組件引用。在上述技術方案中，在創建模塊218為其他組件創建實例前，還包括伺服器206 通過第二通信模塊212連接至伺服器節點，並通過檢測模塊226獲取伺服器節點上發起調用的實例的標識，然後通過查詢模塊224查詢存儲在存儲裝置204中的對應於其他組件的部署信息，並獲取與其他組件存在調用關係的調用組件的標識，以及伺服器202還包括比較模塊228，用於比較實例的標識和調用組件的標識，若實例的標識中沒有調用組件的標識，則由創建模塊218為調用組件創建實例。在該技術方案中，位於底層的組件可能被多個組件使用，因而一些組件在引用時，該底層組件可能已經被引用過而已經創建了實例，此時該實例可以直接被後來的組件所引用，而對於尚未創建實例的底層組件，則可以在被查詢時進行實例的創建。通過這種查詢方式，可以避免已經創建的實例經歷重複操作，簡化上層組件的實例創建。圖3示出了根據本發明的實施例的組件的分布式部署方法的流程圖。如圖3所示，根據本發明的實施例的組件的分布式部署方法，包括步驟302，利用配置完成的組件項目生成組件部署包，並存儲部署信息，部署信息包括所述組件項目的信息、組件項目中的至少一個組件的信息、多個組件之間的關聯信息以及組件部署包的信息； 步驟304，掃描組件部署包，獲取組件部署包中的組件的狀態屬性，若狀態屬性為靜態，則組件為靜態組件，將靜態組件部署於對應的伺服器節點，若狀態屬性為動態，則組件為動態組件，將動態組件部署於對應的伺服器節點，並存儲組件與伺服器節點的對應關係。在該技術方案中，客戶端為組件生成部署包後，由伺服器對包中的組件進行分析，若為靜態組件， 則可以自行生成實例，對系統無影響，若為動態組件，則常常與其他組件有著複雜的依賴關係，需要進行記錄，如將組件的標識與被部署的節點的標識進行關聯後存儲這兩者之間的對應關係，則後續可以通過查詢該對應關係，在相應的節點上創建相應的動態組件實例。同時，通過將組件與節點的對應關係進行存儲，便於在組件出現問題或需要進行檢測、重啟等時，對單個組件或部分組件進行操作，而不必對整個系統進行重啟，減少對其他組件的影響，降低系統的維護成本。在上述技術方案中，步驟302還包括將組件部署包發送至伺服器節點上。在該技術方案中，客戶端在生成部署包後，後續的工作如部署通常由伺服器來完成，並且首先需要伺服器從客戶端獲取其生成的部署包，但也可以由客戶端在生成部署包後，直接將部署包傳輸至需要被部署的節點或其他預定的位置，方便伺服器進行部署操作。在上述技術方案中，步驟304還包括為動態組件生成加載器，加載器用於加載動態組件中的資源。在該技術方案中，伺服器可以在檢測到動態組件後，為其生成加載器，以便對其進行加載，加載過程可以在OSGI框架下準確進行。在上述技術方案中，在步驟304之後，還包括步驟306，解析組件的配置文件，並對組件進行第一判斷，第一判斷包括判斷組件是否由其他組件構成，若判斷結果為否，則為組件創建實例，若判斷結果為是，則進行第二判斷，第二判斷包括判斷其他組件是否位於本地，若其他組件位於本地，則對其他組件進行所述第一判斷，若其他組件不位於本地，則查詢存儲的其他組件的部署信息；步驟308，根據其他組件的部署信息，獲取部署有其他組件的伺服器節點，並在檢測到部署於伺服器節點上的其他組件被正常部署時，為其他組件創建實例。在該技術方案中，主要是為靜態組件創建實例的過程，該組件若與其他組件沒有依賴關係，這裡的依賴關係，主要是指該組件是否由其他組件構成，若沒有，則可以直接創建實例，若有依賴關係，如組件A和組件B —同構成了組件C，此時對於組件C而言，其實例的創建需要涉及組件A和組件B，此時應查詢組件A和組件B的位置，若在本地，則從本地進行加載，或不是，則從之前存儲的組件與節點的對應關係中查找其所在的節點，並對其進行查詢。此處的處理方式，主要就是一層一層地，將處於上層構建的組件進行分析，從最底層的組件開始創建實例，並一層層地被上層組件引用。在上述技術方案中，在步驟208中，創建實例的過程還包括連接至伺服器節點， 記錄伺服器節點上發起調用的實例的標識，並查詢存儲的對應於其他組件的部署信息，獲取與其他組件存在調用關係的調用組件的標識，若實例的標識中沒有調用組件的標識，則為調用組件創建實例。在該技術方案中，位於底層的組件可能被多個組件使用，因而一些組件在引用時，該底層組件可能已經被引用過而已經創建了實例，此時該實例可以直接被後來的組件所引用，而對於尚未創建實例的底層組件，則可以在被查詢時進行實例的創建。通過這種查詢方式，可以避免已經創建的實例經歷重複操作，簡化上層組件的實例創建。圖4示出了根據本發明的實施例的組件的分布式部署的示意圖。
如圖4所示，根據本發明的實施例的組件的分布式部署主要由部署管理客戶端裝置402、部署管理服務端裝置404和部署資源註冊中心406構成，其中，部署管理客戶端裝置402用於將開發配置完成的組件項目導出為運行環境可識別的組件部署包(本發明採用 OSGI Bundle格式)，該組件部署包可以直接由部署管理客戶端裝置402發送至需要被安裝的伺服器節點上，也可以僅僅生成，之後由部署管理服務端裝置404獲取並進行部署，同時，部署管理客戶端裝置402還將第一部署信息發送至部署資源註冊中心406，其中，第一部署信息中包括部署包基本信息和組件部署包所含組件信息，以及在部署管理客戶端裝置 402直接將組件部署包發送至節點時，第一部署信息中還包括伺服器節點信息。然後，部署管理服務端裝置404用於將組件部署包部署在伺服器節點上，在部署過程中，對於部署包中的動態組件，還需要將包含該動態組件與其被部署的伺服器節點的信號作為第二部署信息發送至部署資源註冊中心406，以及在對具有依賴關係的靜態組件進行實例的創建時，還需要由部署管理服務端裝置404在部署資源註冊中心406中查詢第一部署信息和第二部署 fn息ο圖5示出了根據本發明的實施例的客戶端運作的流程圖。如圖5所示，進行組件的分布式部署時，客戶端運作的流程如下步驟502，伺服器節點發布，這裡是指由管理客戶端裝置選擇伺服器節點並進行發布，其中，伺服器節點是分布式環境中伺服器管理的基本單元，用於安裝組件部署包，是組件運行的載體和容器。伺服器節點對應獨立的伺服器進程，在基於java實現的伺服器中， 對應一個獨立的JVM,可配置管理埠，用於伺服器節點間通信。步驟504，告知部署資源註冊中心，這裡是指將步驟502中選擇出的節點信息配置到部署資源註冊中心。步驟506，組件發布，這裡是指選擇組件項目，用該組件項目生成組件部署包並進行發布，以及發布組件部署包內的所有組件，其中，組件項目主要用於在開發形態下管理和組件開發相關的資源，比如組件配置文件，服務定義文件(如wsdl或者java接口)，實體定義文件(xsd或者javaPOJO類)、組件實現文件(java原始碼、groovy腳本或者bpel流程定義文件，取決於組件具體依賴何種技術實現)。步驟508，告知部署資源註冊中心，這裡是指將步驟506中生成的組件部署包的信息配置到部署資源註冊中心。經過部署管理客戶端裝置和部署管理服務端裝置的信息配置，在部署資源註冊中心中可能包括的信息為伺服器節點信息主要包括伺服器節點編號，是否主節點，節點配置(如HTTP服務埠 )，管理埠等信息；組件部署包信息主要記錄部署bundle的標識名，包版本，包路徑等；組件配置信息包括組件標識，組件路徑，組件所屬部署包，組件類型，組件實現類型等；組件部署包和伺服器節點關聯信息包括組件部署包標識、伺服器節點標識。步驟510，部署方案設置，這裡的部署方案定義了一個分布式伺服器節點集群中， 組件項目和具體伺服器節點的對應關係。步驟512，部署方案執行，即由部署管理服務端裝置根據步驟510中的部署方案進行組件部署包在對應的伺服器節點上的部署。
圖6示出了根據本發明的實施例的組件的分布式部署的流程圖。如圖6所示，部署管理服務端裝置在對組件部署包進行部署時，具體步驟如下步驟602，掃描組件配置文件，這裡的組件掃描和啟動裝置基於OSGI動態化的生命周期管理機制，通過對OSGI Bundle格式的組件部署資源包的啟動、停止事件的監控，實現對部署資源包內組件配置文件的動態掃描。步驟604，根據步驟602的掃描結果判斷組件的狀態屬性，若為靜態組件，則進入步驟606，若為動態組件，則進入步驟618，其中，靜態組件是指那些直接可配置具體綁定信息，部署後直接被啟動對外提供服務的組件，而動態組件是指那些無法直接配置綁定信息， 部署後如果沒有被引用則不會創建實例及啟動的組件。同時，靜態組件和動態組件分別又分為複合組件和原子組件。所以組件總共有如下四種類型靜態原子組件，設定其配置文件擴展名為scomp ；靜態複合組件，設定其配置文件擴展名為icomp ；動態原子組件，設定其配置文件擴展名為comp ；動態複合組件，設定其配置文件擴展名為ccomp。此外，動態原子組件和動態複合組件只有被靜態複合組件直接或者間接使用時才會相應的創建實例並啟動服務。步驟606，將組件配置文件加入OSGI服務掃描路徑。步驟608，OSGI框架掃描並啟動靜態組件服務。步驟610，判斷該靜態組件是否存在依賴組件，這裡的依賴組件是指與其他組件存在依賴關係，這裡的組件依賴關係主要由兩種，如圖7所示，其中的複合組件A702由動態原子組件B704、動態原子組件C706和動態複合組件D708構成，那麼稱複合組件A702依賴了動態原子組件B704、動態原子組件C706和動態複合組件D708，這是第一種依賴關係，而第二種依賴關係為在複合組件A702內部，動態原子組件B704分別通過特定的服務調用了動態原子組件C706和動態複合組件D708，此處稱動態原子組件B704依賴了動態原子組件C706和動態複合組件D708。當複合組件A702啟動時，會通過對依賴關係的分析，啟動依賴的所有組件對應的服務。此外，本發明中組件的配置文件採用XML格式定義，具有第一種依賴關係的動態組件在配置文件裡通過〈import〉元素導入，比如對於上述的複合組件A702，引用部分定義如下〈import resource = " classpath:com/ufida/eip/test/componentD. ccomp" />其中 classpath 路徑"classpath:com/ufida/eip/test/componentB. comp，，為 B 組件704的唯一性路徑，可認為是B組件704的id，通過此路徑便可從部署資源註冊中心查詢組件配置，組件部署所在的伺服器節點等信息。第二種依賴關係則通過wire方式定義，同樣對於上述的複合組件A702，B組件704 對C組件706的調用依賴定義如下<bean
>
〈property/>
〈property/>
〈property value="componentB.queryReferen
ce"/>
〈property/
>
從上面的定義可以看出，組件的調用依賴是通過關聯一個組件上的引用和另一個組件上的服務建立起來的。調用依賴根據組件類型不同，可分為動態_靜態調用依賴和動態_動態調用依賴， 上面的定義中B704和C706均為動態組件，所以B704對C706的調用依賴為動態-動態調用依賴類型。明確定義組件依賴類型和具體依賴定義後，組件依賴關係的分析可採用通用技術實現，比如XML解析技術，Spring IOC技術等等，此處不再贅述。依賴關係的處理涉及到組件實例創建及啟動管理，故放到圖9中進行進一步說明。步驟612，在步驟610判斷為存在依賴組件時，分析得到依賴的遠程組件。步驟614，創建或啟動該遠程組件實例，對於步驟612得到的遠程組件可能是動態組件或是靜態組件，若為動態組件，則可以直接進行創建或啟動實例，而對於靜態組件，其創建或啟動實例的過程又將從步驟610開始，也就是進行下一層的解析，而且之後出現的每個靜態組件都將這樣處理，以層層解析的方式，直至得到最底層的組件。步驟616，若步驟610判斷靜態組件沒有遠程依賴組件時，啟動原靜態組件。步驟618，將步驟604中判斷出的動態組件註冊至部署資源註冊中心，登記組件所在的伺服器節點，這是為了之後在被其他組件調用時，方便進行查找。步驟620，註冊動態組件類加載器，該加載器便於在OSGI框架裡準確的加載組件內資源。圖8示出了根據本發明的實施例的伺服器節點通信裝置的框圖。如圖8所示，伺服器節點通信裝置800主要負責伺服器節點間通信，當機及網絡中斷檢測；可支持按組件進行實例管理。在伺服器節點如節點A啟動時，會通過伺服器節點通信裝置800註冊一個節點A 通信管理器806，該節點A的通信管理器806 —旦和其他節點如節點B的通信管理器812建立連接，則以後只要節點B或其他節點出現當機或者網絡異常，與其發生過連接的節點通信管理器如節點A的通信管理器806就會得到通知事件，並由其他部分如組件實例管理器根據此通知事件進行組件實例的清理。每個動態組件啟動時，都會通過伺服器節點通信裝置向其所部署的伺服器節點註冊一個用於遠程組件管理的組件管理器，如對於節點A處的組件1和組件2會分別註冊得到組件1管理器808和組件2管理器810，而對於節點B處的組件3和組件4會分別註冊得到組件3管理器814和組件4管理器816，則如組件1可以通過節點A通信管理器806遠程訪問節點B處的組件3，通過對組件管理器的利用，從而可以創建、初始化及停止遠程組件實例。圖9示出了根據本發明的實施例的為組件創建實例的流程圖。如圖9所示，為組件創建實例的流程如下步驟902，解析組件配置文件，分析組件的構成，圖6中提到靜態組件會被觸發而創建實例，並啟動服務，而動態組件則不會，動態組件只有在被靜態組件組裝依賴的時候， 才會創建相應的實例，所以組件實例創建流程從最開始的時候，接收的是靜態組件配置文件。步驟904，判斷該組件是否由其他組件構成，也就是說分析該組件與其他組件是否存在上述的第一種依賴關係，若存在則進入步驟912，否則，進入步驟906。步驟906，判斷該組件是否為靜態組件，若是，則進入步驟908，否則進入步驟910。步驟908，為該靜態組件創建實例並啟動靜態組件。步驟910，為該動態組件創建動態組件實例，在圖6中，對於動態組件只是進行信息註冊等，而既不創建實例也不啟動服務，而這裡，已經判斷了其沒有依賴關係，且由配置文件解析得到，則直接創建實例。步驟912至步驟928，都是對導入的組件列表中的每一個組件路徑進行的操作，其中，組件列表為步驟904中判斷由其他組件構成時，將參與構成的組件的標識記錄在組件列表中得到的。步驟912，通過路徑在本地加載導入的組件，這裡由於需要依賴其他的組件，因此系統被依賴的組件能夠存在於本地。步驟914，判斷該組件是否存在於本地，若是，則返回步驟902，對該組件的狀態屬性和是否依賴於其他組件進行解析，否則進入步驟916。步驟916，判斷部署資源註冊中心是否存在相關信息，在生成部署包後，部署管理客戶端裝置會向部署資源註冊中心發送第一部署信息，且部署管理服務端裝置會在部署上述部署包時，向部署資源註冊中心發送第二部署信息，從而可以通過對部署資源註冊中心的查詢，得到組件的信息。在判斷為是是，進入步驟920，否則進入步驟918。步驟918，提示依賴的組件沒有發布，然後結束。步驟920至步驟926為對每一個部署有該組件的伺服器節點的操作。步驟920，通過伺服器通信裝置裡的遠程組件管理器查詢目標伺服器節點，這裡的通信過程已經通過圖8進行了詳細說明。步驟922，判斷組件是否正常部署，若正常，則進入步驟926，否則進入步驟924。步驟924，通過記入日誌以警告管理員伺服器節點上的組件部署不正常。步驟926，記入有效組件部署信息列表，這裡是指在查詢到所依賴的組件，並且該組件被正常部署的話，將該組件的標識進行記錄，並形成有效組件部署信息列表。步驟928，生成遠程組件實例代理，這裡將結合圖10對遠程組件實例的創建過程進行分析，具體過程如下步驟1002，連接遠程伺服器節點，這是根據步驟926中形成的有效組件部署信息列表中的信息，連接到相關聯的組件所在的伺服器節點。步驟1004，獲取遠程組件管理器，該管理器用於管理對應的組件的實例創建過程。步驟1006，調用創建命令，用於進行實例的創建。步驟1008，記錄發起調用的組件實例，將向該組件發起過調用的組件記錄下來，也就是說，對於組件之間的調用，需要進行記錄和存儲，方便之後的查找和使用。步驟1010，分析組件間調用依賴關係，對於調用該組件且具有依賴關係的組件，需要進行步驟1012的操作。步驟1012，從組件管理器中按組件實例ID查找組件實例，對於創建的實例，都擁有唯一對應的ID，則可以通過ID查找已經創建的組件實例。步驟1014，根據查找結果，判斷實例是否存在，若存在，則可以對該實例直接進行引用，否則進入步驟1016。步驟1016，創建組件實例，可以看出，圖10的過程，是為了對依賴的組件進行分析，並對已經創建實例的組件進行直接引用，而沒有創建的再進行創建，從而節省資源和時間，方便管理。步驟930，創建複合靜態組件實例並啟動。圖11示出了根據本發明的實施例的為組件創建實例的示意圖。如圖11所示，組件實例創建流程主要利用的是上述第一種依賴關係，解決的是按需創建組件實例的問題，並沒有說明動態組件實例上的綁定服務是如何被啟動的。遠程組件實例管理裝置基於組件正向的調用型依賴關係，可有效解決按需啟動組件實例上綁定服務的問題；基於組件反向的調用依賴關係，可解決伺服器節點配置變化而導致的人工重啟問題，還可解決因為整個組件依賴鏈中因為某個組件實例失效，其他組件實例雖然正常運行但卻無法提供有效服務的問題。下面基於圖11詳細描述基於正反向調用型依賴關係解決以上問題的工作原理假設複合靜態組件S 1102通過上述第一種方式依賴了動態複合組件A 1104， 基於組件實例創建流程，創建複合靜態組件S 1102的實例Si，相應的會創建複合組件A 1104、動態原子組件B 1106、動態原子組件C1108及動態複合組件D 1110的組件實例，分別記為Ai，Bi，Ci及Di，其中，Ai記錄了反向組裝依賴關係{Si組裝依賴Ai}；Bi記錄了反向組裝依賴關係{Ai組裝依賴Bi}；Ci記錄了反向組裝依賴關係{Ai組裝依賴Ci}，同時記錄了反向調用依賴關係{Bi 組裝依賴Ci}；Di記錄了反向組裝依賴關係{Ai組裝依賴Di}，同時記錄了反向調用依賴關係{Bi 組裝依賴Di}。組件掃描和啟動裝置啟動Si上的服務Ssi，服務Ssi實際上由服務Asi提供，SCA裡稱這種自身並不真正提供服務實現的服務為升級服務(Promoting Service)，同樣Asi由Bsi 提供，所以啟動Ssi時會根據服務依賴關係去啟動BS1。當服務啟動時，通過對組件調用依賴的分析，即查詢引用Bei和引用Be2分別連接的服務Csi及服務Dsi，並啟動Csi和Dsi ；如果組件C1108和組件D 1110同樣有調用依賴存在，則按同樣方法遞歸處理即可，通過這種方法可有效解決不被弓I用的服務也被啟動的問題。
現在假設組件C 1108部署在伺服器節點NodeC上，因為管理需要，NodeC的配置發生變化，比如原來Csi提供http服務地址為http://192. 168. 1. 122 :8080/csl，現在修改 http服務埠為8088。NodeC配置一旦修改，需要重啟NodeC，組件C 1108相應也被重啟， 而組件C重啟時，組件管理器基於持久化機制恢復之前的組件實例Ci。組件實例Ci通過綁定信息版本，判斷是否服務綁定信息發生變化，如果沒有變化，則直接略過，如果綁定信息變化了，則取得記錄的反向依賴關係，得知Bi調用依賴了 Ci，取得Bi對應的組件管理器，通過組件管理器更新組件Bi的服務綁定信息並重啟Bi。通過以上方法，可有效解決伺服器節點配置變化而導致的人工重啟問題。另外如果整個組件依賴鏈中因為某個組件實例失效，也是通過同樣的反向調用依賴關係的分析而實現的，工作原理相同，此處不再贅述。以上結合附圖詳細說明了本發明的技術方案，考慮到相關技術中，容易造成寶貴的伺服器資源浪費，而當某個組件停止運行時，往往導致管理員會重啟所有伺服器，導致其他本可以正常運行的服務中斷。因此，本發明通過提出了一種組件部署系統和一種組件部署方法，可以實現在分布式環境下對有複雜依賴關係的組件的方便部署和對實例的精細化管理，同時實現按需創建和啟動，避免對整體系統的影響。以上所述僅為本發明的優選實施例而已，並不用於限制本發明，對於本領域的技術人員來說，本發明可以有各種更改和變化。凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護範圍之內。
權利要求
1.一種組件的分布式部署系統，其特徵在於， 包括客戶端、存儲裝置和伺服器，其中，所述客戶端包括第一生成模塊，利用配置完成的組件項目生成組件部署包；第一通信模塊，連接至所述存儲裝置，用於將部署信息發送至所述存儲裝置，所述部署信息包括所述組件項目的信息、所述組件項目中的至少一個組件的信息、多個組件之間的關聯信息以及所述組件部署包的信息；所述存儲裝置，連接至所述客戶端和所述伺服器，存儲所述部署信息； 所述伺服器包括第二通信模塊，連接至所述客戶端，用於接收所述組件部署包； 掃描模塊，掃描所述第二通信模塊接收到的所述組件部署包，並獲取所述組件部署包中的組件的狀態屬性；部署模塊，在所述狀態屬性為靜態的情況下，所述組件為靜態組件，將所述靜態組件部署於對應的伺服器節點，在所述狀態屬性為動態的情況下，所述組件為動態組件，將所述動態組件部署於對應的伺服器節點，並將所述組件與所述伺服器節點的對應關係存儲在所述存儲裝置中；創建模塊，為組件創建實例。
2.根據權利要求1所述的組件的分布式部署系統，其特徵在於，所述客戶端的所述第一通信模塊還用於將所述組件部署包發送至伺服器節點上。
3.根據權利要求1所述的組件的分布式部署系統，其特徵在於，所述伺服器還包括 第二生成模塊，為動態組件生成加載器，所述加載器用於加載所述動態組件中的資源。
4.根據權利要求1至3中任一項所述的組件的分布式部署系統，其特徵在於，所述伺服器還包括解析模塊，用於解析組件的配置文件，並對所述組件進行第一判斷，所述第一判斷包括判斷所述組件是否由其他組件構成，若判斷結果為否，則為所述組件創建實例，若所述判斷結果為是，則進行第二判斷，所述第二判斷包括判斷所述其他組件是否位於本地，若所述其他組件位於本地，則對所述其他組件進行所述第一判斷，若所述其他組件不位於本地，則通過查詢模塊查詢所述存儲裝置中存儲的所述其他組件的部署信息；所述查詢模塊，用於對存儲在所述存儲裝置中的部署信息進行查詢； 檢測模塊，根據所述查詢模塊查詢到的所述部署信息，獲取部署有所述其他組件的伺服器節點，並檢測部署於所述伺服器節點上的所述其他組件是否被正常部署，若是，則通過所述創建模塊為所述其他組件創建實例。
5.根據權利要求4所述的組件的分布式部署系統，其特徵在於，在所述創建模塊為所述其他組件創建實例前，還包括所述伺服器通過所述第二通信模塊連接至所述伺服器節點，並通過所述檢測模塊獲取所述伺服器節點上發起調用的實例的標識，然後通過所述查詢模塊查詢存儲在所述存儲裝置中的對應於所述其他組件的部署信息，並獲取與所述其他組件存在調用關係的調用組件的標識，以及所述伺服器還包括比較模塊，所述比較模塊用於比較所述實例的標識和所述調用組件的標識，若所述實例的標識中沒有所述調用組件的標識，則由所述創建模塊為所述調用組件創建實例。
6.一種組件的分布式部署方法，其特徵在於，包括步驟202，利用配置完成的組件項目生成組件部署包，並存儲部署信息，所述部署信息包括所述組件項目的信息、所述組件項目中的至少一個組件的信息、多個組件之間的關聯信息以及所述組件部署包的信息；步驟204，掃描所述組件部署包，獲取所述組件部署包中的組件的狀態屬性，若所述狀態屬性為靜態，則所述組件為靜態組件，將所述靜態組件部署於對應的伺服器節點，若所述狀態屬性為動態，則所述組件為動態組件，將所述動態組件部署於對應的伺服器節點，並存儲所述組件與所述伺服器節點的對應關係。
7.根據權利要求6所述的組件的分布式部署方法，其特徵在於，所述步驟202還包括將所述組件部署包發送至伺服器節點上。
8.根據權利要求6所述的組件的分布式部署方法，其特徵在於，所述步驟204還包括為動態組件生成加載器，所述加載器用於加載所述動態組件中的資源。
9.根據權利要求6至8中任一項所述的組件的分布式部署方法，其特徵在於，在所述步驟204之後，還包括步驟206，解析組件的配置文件，並對所述組件進行第一判斷，所述第一判斷包括判斷所述組件是否由其他組件構成，若判斷結果為否，則為所述組件創建實例，若所述判斷結果為是，則進行第二判斷，所述第二判斷包括判斷所述其他組件是否位於本地，若所述其他組件位於本地，則對所述其他組件進行所述第一判斷，若所述其他組件不位於本地，則查詢存儲的所述其他組件的部署信息；步驟208，根據所述其他組件的所述部署信息，獲取部署有所述其他組件的伺服器節點，並在檢測到部署於所述伺服器節點上的所述其他組件被正常部署時，為所述其他組件創建實例。
10.根據權利要求9所述的組件的分布式部署方法，其特徵在於，在所述步驟208中，所述創建實例的過程還包括連接至所述伺服器節點，記錄所述伺服器節點上發起調用的實例的標識，並查詢存儲的對應於所述其他組件的部署信息，獲取與所述其他組件存在調用關係的調用組件的標識，若所述實例的標識中沒有所述調用組件的標識，則為所述調用組件創建實例。
全文摘要
本發明提供了一種組件的分布式部署系統和方法，包括步驟202，利用配置完成的組件項目生成組件部署包，並存儲部署信息，部署信息包括組件項目的信息、組件項目中的至少一個組件的信息、多個組件之間的關聯信息以及組件部署包的信息；步驟204，掃描組件部署包，獲取組件部署包中的組件的狀態屬性，若狀態屬性為靜態，則將靜態組件部署於對應的伺服器節點，若狀態屬性為動態，則將動態組件部署於對應的伺服器節點，並存儲組件與伺服器節點的對應關係。通過本發明的技術方案，可以實現在分布式環境下對有複雜依賴關係的組件的方便部署和對實例的精細化管理，同時實現按需創建和啟動，避免對整體系統的影響。
文檔編號H04L29/08GK102360308SQ20111029558
公開日2012年2月22日 申請日期2011年9月29日 優先權日2011年9月29日
發明者程操紅 申請人:用友軟體股份有限公司