| 導購 | 订阅 | 在线投稿
分享
 
 
 

實現高可用性設計的奧秘

來源:互聯網  2008-05-31 22:07:16  評論

高可用性要求一種合適的基礎結構,但是,假如沒有將該基礎結構與J2EE應用程序設計策略進行協調平衡,性能很可能就會受損。

假如您在高可用性硬件和軟件基礎結構方面投資了一筆數目可觀的資金,您就必須保證應用程序具備高可用性-至少應保證J2EE(Java 2平台企業版)中普遍存在的做法可保證應用程序具備高可用性。別忘了,當您將數據庫和應用程序服務器的群集與群集軟件進行組合時,您將會獲得一個相當有效的組合。這裏的群集軟件包括Oracle9i數據庫和Oracle9i應用程序服務器(Oracle9iAS)中的軟件,這些群集軟件既可以將請求自動發送到可用的服務器,還可以提供透明的應用程序失敗處理。當您在J2EE體系結構中增加這類數目衆多的混合狀態治理機制(具有狀態的Web會話和無狀態Web會話,具有狀態的商業組件和無狀態商業組件,自動複制或備份beans等等)時,您應該同時保證具備高可用性。

不幸地是,這種普遍的做法並非完全正確。盡管服務器與相應軟件的群集可以提供高可用性,但是它們卻無法保證高可用性。事實上,某些高可用性功能(如J2EE的狀態治理機制)的過度使用就可能會降低應用程序的性能,進而降低整體的可用性。

即便使用最好的體系結構,要真正實現高可用性,其中的要害一步就是從一開始就把高可用性考慮到應用程序的設計中來。因此,您需要從以下幾個方面來非凡關注應用程序的設計:

· 便捷的狀態治理

投入一定時間來識別並確定應用程序的狀態,然後將狀態精確映射到各種可用的狀態治理機制,避免過度使用某一類型的機制而導致性能降低。

· 仔細的層次設計

分析應用程序是否真正需要很多層。層次會增加複雜性、導致性能劣化並且降低可用性。

· 失敗處理策略

確定並處理那些基礎結構無法自動檢測和修複的失敗。

假如在應用程序設計的各個步驟中額外多投入一些時間,同時應用本文所描述的各種策略,那麽應用程序的可用性將會顯著增強。

便捷的狀態治理

要確保實現高可用性,您就需要具備有效的狀態恢複機制。假如一個組件失敗,系統在處理新的請求之前,必須先恢複該組件所保持的狀態。

J2EE提供多種便捷的狀態治理機制,但是這些機制經常被過度使用,而過度使用這些機制經常帶來一些不幸的結果。包括 JavaServer Pages (jsp)頁中的會話範圍的JavaBeans、HTTP會話對象servlets以及用于商業組件的有狀態會話bean等在內的這些狀態治理機制,可以識別並確定失敗時必須保持的狀態。所有這些機制都使用存儲在內存中的Java 對象來表示應用程序的狀態。在HTTP會話過程中以Java形式來保存這些對象可以爲編程人員提供必要的便捷,但是卻很輕易會忘記進行相關備份所需的代價。

應用程序服務器(如Oracle9iAS)通過在數據庫、文件或者備份服務器的有效內存中對這些存儲在內存中的Java 對象的副本進行備份,就可以在必要時積極采取相應的恢複措施。對Java 對象進行備份時經常要求使用代價昂貴的 Java 串行操作。假如將許多大型的Java 對象用于狀態治理(這是一種常見的應用程序設計策略),就會使J2EE 狀態治理機制負載過重。因此,應用程序的性能將會劣化到極低的級別,這會讓人無法接受。當然,這也與高可用性的目標背道而馳(我們認爲一個速度極慢的應用程序不具有高可用性)。

作爲這種 J2EE 標准方法的另一可選方法,您應該關注多數大型 Web 站點(這些站點同時又具備高可用性)所使用的模型。在該模型中,應用程序的狀態主要保存在持久穩固的存儲器(如數據庫)中,同時在內存中進行了緩存處理以便改善響應時間(這與J2EE模型不同,J2EE模型中一開始就將狀態存儲在內存中,然後由應用程序服務器進行備份)。這裏,最要害的不同之處就是:對于大型的Web站點模型,應用程序的寫進程已投入一定時間來識別並確定應用程序狀態的要害片斷,同時還設計了一種有效機制(緩存),用于從應用程序對緩存進行訪問。因而,中間層組件的失敗並不需要恢複中間層的狀態,而僅需重新啓動緩存,這是因爲需要時可以從後端再次導入相關的狀態。

一些大型的 Web站點更進一步,它們對應用程序的狀態進行分離,然後將其分別存儲在穩固持久的後端存儲器和客戶端浏覽器中。一些狀態以cookie的形式保存在浏覽器中,這樣就隱藏了 Html 形式的元素或 URL 參數。

這種技術不僅提供了更高的可用性,而且還提高了應用程序的整體品質。假如浏覽器處于未連接狀態,這種技術答應終端用戶很輕易地重新開始連接會話。

現在很清楚了:J2EE應用程序開發人員需要預先投入一定時間來分析應用程序狀態,然後根據特定策略將其映射到適當的可恢複存儲器中。

接下來的一個問題就是如何確定哪些狀態應該映射到後端數據庫而哪些狀態應該映射到浏覽器。幸運地是,這個問題的答案通常是相當簡單直接的,它取決于所要映射的狀態信息的類型。

應用程序的狀態通常可分爲下面三種類型:

· 頁狀態:此種類型的狀態在一頁中是有效的,例如,搜索查詢返回的一系列結果的開始索引。

· 會話狀態:此種類型的狀態通常在一次會話的整個過程中是有效的,例如,運行應用程序的末端用戶的身份。

· 持久狀態:此種類型的狀態的生命周期爲端用戶會話,例如,購物報表或開支報告的內容。在常見的典型應用程序中,大多數應用程序狀態都是這種持久狀態類型的。

一旦您將應用程序的狀態劃分爲上述三種類型,您就可以將狀態映射到適當的持有器中。請您在腦中牢記:您的目標之一就是通過一種J2EE 機制使在中間層內存器中保存的狀態盡可能少。

映射頁狀態。處理頁狀態的最佳方式就是將其存儲隱藏形式的元素或URL參數中,這些元素或參數嵌套在該頁中。因爲此狀態需要在該頁面對浏覽器可用的整個期間中始終保持,因而它並不會産生恢複問題。諸如 Oracle9iAS 的J2EE MVC 框架之類的模型查看控制器(Model View Controller)框架,使用隱藏形式的元素將頁面流信息保存在每一個Web頁面中。

映射會話狀態。您可以保存一些會話狀態,如用戶身份和in cookies;身份驗證系統(如Oracle9iAS Single Sign-On)就使用此種方法。然而,您需要在中間層內存中保存會話狀態的其他一些部分。假如cookie 的數目過多或者內容過大,就無法進行高效操作。在這些情況下,您就應該使用之前已提及的一種 J2EE狀態治理機制。把使用這些機制的情形限制到這些場合有助于保持較高的可用性。

映射持久狀態。您應該非常明確地將持久狀態保存在後端數據庫中。您可以在中間層內存中對其進行緩存以便提高效率(Oracle9iAS 中的非凡JSP 標記庫可以在 Web 緩存和 J2EE 容器中對頁片斷進行緩存)。然而,您可能希望數據庫成爲真實數據的來源以便中間層失敗時避免出現恢複問題。請注重:強烈建議顯式標識狀態並且通過正規的數據庫訪問機制(如實體 beans或 Java Database Connectivity (JDBC))將狀態顯式存儲在數據庫中.

通過此種方式來映射這三種類型的狀態,就可以創建狀態安全的應用程序。狀態安全的應用程序可以避免無狀態應用程序的局限性,而可用性並不差。

仔細的層次設計

層次設計是獲得可用性的另一領域。在J2EE中,通常有這樣一個共識:應用程序應該由多種層次組成。然而,假如您使用過多的層次,不僅不會增強可用性,反而還可能會阻礙了可用性。

使用多種層次的原因是相當明顯的。首先,仔細的多層設計有助于隔離各種故障,例如,商業組件雖然失敗但並不會影響Web前端的可用性,這一點可持續至前端需要使用該組件爲止。而且,在一些情況下,每一層中運行更少的邏輯可以使每一層變得更健壯。

但是,使層的數目盡可能保持最低具有非常顯著的優勢。這使應用程序可以更輕易地進行治理和監控,爲那些負責實現高可用性的操作組提供巨大的幫助。而且,假如一個應用程序具有層數不多,通常就更易于設計,因而整體上就更加健壯。最後,設計一個層數不多的應用程序(例如,使用Enterprise JavaBeans (EJB) 2.0 本地接口)可以獲得更優的性能,這也同時會大大增強可用性。

假如您將目標鎖定爲高可用性,但又無法確定選用的層數應該多一些還是少一些,請您相信,使用更少的層數,出錯的可能性就會更低。

失敗處理策略

與狀態治理和層次設計一樣,我們在失敗處理方面過分依靠于常規的方法和高可用性基礎結構的實際能力。因爲現在的應用程序服務器能夠自動檢測和修複許多組件失敗,我們就不必投入太多的精力,以便我們的應用程序能夠處理那些不能自動修複的失敗。但是我們並沒有意識到:真正的高可用性則要求應用程序和應用程序服務器之間能夠相互協作。

雙重事務是一種常見的失敗類型,這種類型的失敗很難做到自動修複。終端用戶兩次單擊Bill Me 按鈕就是該類失敗的一個示例。由于雙重事務的産生因素在于不同層之間的通信失敗,所以修複就可能會涉及一些位于應用程序服務器內嵌的修複機制範圍之外的問題。請這樣一種簡單的情形,一個JSP 頁面通過JDBC 提交事務,但是卻收到了網絡通信錯誤。那麽應用程序服務器如何才能確定在通信失敗之前該事務是否已經提交?應用程序服務器是否應該自動再重複先前的操作?這類問題在層次緊密的體系結構中更加難以解決,其中JSP頁調用在多個分布式容器中運行的EJB。通信錯誤表示bean 調用根本就沒有執行完畢,在這種情況下再次進行調用就非常合適。可是,相同的錯誤也可能是起因于這樣一種情況,調用本身已取得成功但是

  高可用性要求一種合適的基礎結構,但是,假如沒有將該基礎結構與J2EE應用程序設計策略進行協調平衡,性能很可能就會受損。      假如您在高可用性硬件和軟件基礎結構方面投資了一筆數目可觀的資金,您就必須保證應用程序具備高可用性-至少應保證J2EE(Java 2平台企業版)中普遍存在的做法可保證應用程序具備高可用性。別忘了,當您將數據庫和應用程序服務器的群集與群集軟件進行組合時,您將會獲得一個相當有效的組合。這裏的群集軟件包括Oracle9i數據庫和Oracle9i應用程序服務器(Oracle9iAS)中的軟件,這些群集軟件既可以將請求自動發送到可用的服務器,還可以提供透明的應用程序失敗處理。當您在J2EE體系結構中增加這類數目衆多的混合狀態治理機制(具有狀態的Web會話和無狀態Web會話,具有狀態的商業組件和無狀態商業組件,自動複制或備份beans等等)時,您應該同時保證具備高可用性。      不幸地是,這種普遍的做法並非完全正確。盡管服務器與相應軟件的群集可以提供高可用性,但是它們卻無法保證高可用性。事實上,某些高可用性功能(如J2EE的狀態治理機制)的過度使用就可能會降低應用程序的性能,進而降低整體的可用性。      即便使用最好的體系結構,要真正實現高可用性,其中的要害一步就是從一開始就把高可用性考慮到應用程序的設計中來。因此,您需要從以下幾個方面來非凡關注應用程序的設計:      · 便捷的狀態治理      投入一定時間來識別並確定應用程序的狀態,然後將狀態精確映射到各種可用的狀態治理機制,避免過度使用某一類型的機制而導致性能降低。      · 仔細的層次設計      分析應用程序是否真正需要很多層。層次會增加複雜性、導致性能劣化並且降低可用性。      · 失敗處理策略      確定並處理那些基礎結構無法自動檢測和修複的失敗。      假如在應用程序設計的各個步驟中額外多投入一些時間,同時應用本文所描述的各種策略,那麽應用程序的可用性將會顯著增強。         便捷的狀態治理         要確保實現高可用性,您就需要具備有效的狀態恢複機制。假如一個組件失敗,系統在處理新的請求之前,必須先恢複該組件所保持的狀態。      J2EE提供多種便捷的狀態治理機制,但是這些機制經常被過度使用,而過度使用這些機制經常帶來一些不幸的結果。包括 JavaServer Pages (jsp)頁中的會話範圍的JavaBeans、HTTP會話對象servlets以及用于商業組件的有狀態會話bean等在內的這些狀態治理機制,可以識別並確定失敗時必須保持的狀態。所有這些機制都使用存儲在內存中的Java 對象來表示應用程序的狀態。在HTTP會話過程中以Java形式來保存這些對象可以爲編程人員提供必要的便捷,但是卻很輕易會忘記進行相關備份所需的代價。      應用程序服務器(如Oracle9iAS)通過在數據庫、文件或者備份服務器的有效內存中對這些存儲在內存中的Java 對象的副本進行備份,就可以在必要時積極采取相應的恢複措施。對Java 對象進行備份時經常要求使用代價昂貴的 Java 串行操作。假如將許多大型的Java 對象用于狀態治理(這是一種常見的應用程序設計策略),就會使J2EE 狀態治理機制負載過重。因此,應用程序的性能將會劣化到極低的級別,這會讓人無法接受。當然,這也與高可用性的目標背道而馳(我們認爲一個速度極慢的應用程序不具有高可用性)。      作爲這種 J2EE 標准方法的另一可選方法,您應該關注多數大型 Web 站點(這些站點同時又具備高可用性)所使用的模型。在該模型中,應用程序的狀態主要保存在持久穩固的存儲器(如數據庫)中,同時在內存中進行了緩存處理以便改善響應時間(這與J2EE模型不同,J2EE模型中一開始就將狀態存儲在內存中,然後由應用程序服務器進行備份)。這裏,最要害的不同之處就是:對于大型的Web站點模型,應用程序的寫進程已投入一定時間來識別並確定應用程序狀態的要害片斷,同時還設計了一種有效機制(緩存),用于從應用程序對緩存進行訪問。因而,中間層組件的失敗並不需要恢複中間層的狀態,而僅需重新啓動緩存,這是因爲需要時可以從後端再次導入相關的狀態。      一些大型的 Web站點更進一步,它們對應用程序的狀態進行分離,然後將其分別存儲在穩固持久的後端存儲器和客戶端浏覽器中。一些狀態以cookie的形式保存在浏覽器中,這樣就隱藏了 Html 形式的元素或 URL 參數。 這種技術不僅提供了更高的可用性,而且還提高了應用程序的整體品質。假如浏覽器處于未連接狀態,這種技術答應終端用戶很輕易地重新開始連接會話。      現在很清楚了:J2EE應用程序開發人員需要預先投入一定時間來分析應用程序狀態,然後根據特定策略將其映射到適當的可恢複存儲器中。      接下來的一個問題就是如何確定哪些狀態應該映射到後端數據庫而哪些狀態應該映射到浏覽器。幸運地是,這個問題的答案通常是相當簡單直接的,它取決于所要映射的狀態信息的類型。      應用程序的狀態通常可分爲下面三種類型:      · 頁狀態:此種類型的狀態在一頁中是有效的,例如,搜索查詢返回的一系列結果的開始索引。      · 會話狀態:此種類型的狀態通常在一次會話的整個過程中是有效的,例如,運行應用程序的末端用戶的身份。      · 持久狀態:此種類型的狀態的生命周期爲端用戶會話,例如,購物報表或開支報告的內容。在常見的典型應用程序中,大多數應用程序狀態都是這種持久狀態類型的。      一旦您將應用程序的狀態劃分爲上述三種類型,您就可以將狀態映射到適當的持有器中。請您在腦中牢記:您的目標之一就是通過一種J2EE 機制使在中間層內存器中保存的狀態盡可能少。      映射頁狀態。處理頁狀態的最佳方式就是將其存儲隱藏形式的元素或URL參數中,這些元素或參數嵌套在該頁中。因爲此狀態需要在該頁面對浏覽器可用的整個期間中始終保持,因而它並不會産生恢複問題。諸如 Oracle9iAS 的J2EE MVC 框架之類的模型查看控制器(Model View Controller)框架,使用隱藏形式的元素將頁面流信息保存在每一個Web頁面中。      映射會話狀態。您可以保存一些會話狀態,如用戶身份和in cookies;身份驗證系統(如Oracle9iAS Single Sign-On)就使用此種方法。然而,您需要在中間層內存中保存會話狀態的其他一些部分。假如cookie 的數目過多或者內容過大,就無法進行高效操作。在這些情況下,您就應該使用之前已提及的一種 J2EE狀態治理機制。把使用這些機制的情形限制到這些場合有助于保持較高的可用性。      映射持久狀態。您應該非常明確地將持久狀態保存在後端數據庫中。您可以在中間層內存中對其進行緩存以便提高效率(Oracle9iAS 中的非凡JSP 標記庫可以在 Web 緩存和 J2EE 容器中對頁片斷進行緩存)。然而,您可能希望數據庫成爲真實數據的來源以便中間層失敗時避免出現恢複問題。請注重:強烈建議顯式標識狀態並且通過正規的數據庫訪問機制(如實體 beans或 Java Database Connectivity (JDBC))將狀態顯式存儲在數據庫中.      通過此種方式來映射這三種類型的狀態,就可以創建狀態安全的應用程序。狀態安全的應用程序可以避免無狀態應用程序的局限性,而可用性並不差。         仔細的層次設計         層次設計是獲得可用性的另一領域。在J2EE中,通常有這樣一個共識:應用程序應該由多種層次組成。然而,假如您使用過多的層次,不僅不會增強可用性,反而還可能會阻礙了可用性。      使用多種層次的原因是相當明顯的。首先,仔細的多層設計有助于隔離各種故障,例如,商業組件雖然失敗但並不會影響Web前端的可用性,這一點可持續至前端需要使用該組件爲止。而且,在一些情況下,每一層中運行更少的邏輯可以使每一層變得更健壯。      但是,使層的數目盡可能保持最低具有非常顯著的優勢。這使應用程序可以更輕易地進行治理和監控,爲那些負責實現高可用性的操作組提供巨大的幫助。而且,假如一個應用程序具有層數不多,通常就更易于設計,因而整體上就更加健壯。最後,設計一個層數不多的應用程序(例如,使用Enterprise JavaBeans (EJB) 2.0 本地接口)可以獲得更優的性能,這也同時會大大增強可用性。      假如您將目標鎖定爲高可用性,但又無法確定選用的層數應該多一些還是少一些,請您相信,使用更少的層數,出錯的可能性就會更低。         失敗處理策略         與狀態治理和層次設計一樣,我們在失敗處理方面過分依靠于常規的方法和高可用性基礎結構的實際能力。因爲現在的應用程序服務器能夠自動檢測和修複許多組件失敗,我們就不必投入太多的精力,以便我們的應用程序能夠處理那些不能自動修複的失敗。但是我們並沒有意識到:真正的高可用性則要求應用程序和應用程序服務器之間能夠相互協作。      雙重事務是一種常見的失敗類型,這種類型的失敗很難做到自動修複。終端用戶兩次單擊Bill Me 按鈕就是該類失敗的一個示例。由于雙重事務的産生因素在于不同層之間的通信失敗,所以修複就可能會涉及一些位于應用程序服務器內嵌的修複機制範圍之外的問題。請這樣一種簡單的情形,一個JSP 頁面通過JDBC 提交事務,但是卻收到了網絡通信錯誤。那麽應用程序服務器如何才能確定在通信失敗之前該事務是否已經提交?應用程序服務器是否應該自動再重複先前的操作?這類問題在層次緊密的體系結構中更加難以解決,其中JSP頁調用在多個分布式容器中運行的EJB。通信錯誤表示bean 調用根本就沒有執行完畢,在這種情況下再次進行調用就非常合適。可是,相同的錯誤也可能是起因于這樣一種情況,調用本身已取得成功但是
󰈣󰈤
王朝萬家燈火計劃
期待原創作者加盟
 
 
 
>>返回首頁<<
 
 
 
 
 熱帖排行
 
 
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有