第4章 部署模式 Deployment Plan（部署規劃）

已開發了基于組件的應用程序，該應用程序在邏輯上構造為多層結構，如 Three-Layered Services application. 中所述。您希望將它分布到一組在物理上為多級結構的服務器上，如 Tiered Distribution 中所述。

圖 1: 三層服務應用程序

影響因素

確定將組件部署到哪一級時，必須在實際環境的上下文中考慮下列影響因素：

• Layered Application 主要涉及對組件之間的設計依賴性進行管理，而"分級分布"則涉及對運行時服務器配置進行優化以滿足系統級的運行要求。因此，將應用程序組織成多層結構所基 于的標準在根本上與優化物理組件部署所使用的標準是不同的。例如，將組件分配到不同的層的主要驅動力之一是盡量減少不同層中的組件之間的依賴性。相反，優 化組件部署的主要驅動因素是將組件的資源消耗配置文件與適當的服務器進行匹配。這意味著直接將層與級進行對應通常不是最優的分布策略。例如，開放系統互聯 (OSI) 網絡協議棧參考模型的構造為七層結構。沒有人會要求甚至推薦在七臺不同的服務器上分別駐留一層。
• 構造多層應用程序與構造硬件基礎結構通常要分別由不同的兩類人來完成的。這兩類人通常具有不同的技能，而他們所共有的技能則會很少。例如，應用程序體系結構側重于應用程序組件以及組件之間的關系，而系統體系結構側重于服務器以及連接它們的網絡。
• 部 署組件的硬件每增一級，復雜性、部署工作量和成本都將相應增加。將所有組件部署到同一級相對比較簡單。隨著級數的增加，確定應將哪些組件部署到哪一層也就 越發困難。同樣，將所有組件部署到一個位置所需的工作量相對較少；而在添加更多的級后，必須在構建和部署過程后投入額外的工作量，以確定應將哪些組件部署 到哪一層。最后，每增加一級，都增加了組成該級的附加硬件的固定成本和重復成本。
• 組成應用程序的每個組件都消耗不 同數量的資源，如內存、處理器使用率、文件句柄、IO 套接字以及磁盤空間。根據這一影響因素，為各級分配組件有兩種方法：專用級和通用級。專用級為駐留具有特定資源使用配置文件的組件而進行優化。由于專用級 中的服務器針對特定的配置文件進行優化，因此對于滿足該配置文件的組件，每個服務器的駐留容量要遠遠大于按常規方法配置的服務器。因此，使用專用級通常會 導致較多的級數，但每級的服務器數較少。另一方面，通用級中的服務器是按常規方法配置的，因此部署決策主要考慮到下列因素：在給定的系統資源被完全耗盡之 前，每個服務器可以存放多少組件。使用通用級通常會導致較少的級數，但每級的服務器數較多。
• 不同的組件具有不同的 運行要求，如安全性、可用性和容錯。例如，從 Web 與從外圍網絡（也稱 DMZ、網絡隔離和屏蔽子網）的公司一側訪問的組件具有不同的安全要求。前一影響因素的兩種方法在此處也同樣適用。可以增加專用級以駐留具有特定運行要求 的組件，或者配置通用級以滿足所有運行要求。
• 安全要求通常驅使您增加級，并使每級駐留具有共同安全要求的組件。每增加一級，除了前面提到的增加復雜性、部署工作量和成本外，還會增加總體安全風險。每增加一級還會增加需要進行安全保護的新服務器和其他基礎設施。
• 業務、政治和法律上的考慮可能要求將解決方案的特定組件駐留于特定的地理位置。例如，包含公司敏感信息的數據庫可能需要駐留在安全的公司數據中心，而包含業務邏輯的應用程序服務器可能駐留在第三方駐留設備中。
• 組件調用所跨越的每個進程和服務器邊界都會對響應時間造成不利的影響。跨越進程邊界的組件調用比進程內調用的速度慢幾倍，而跨越網絡的組件調用的速度比同一進程內的組件調用慢一個數量級。

解決方案

應用程序體系結構設計者必須與系統體系結構設計者共同創建部署規劃，以說明每個應用程序組件將部署到哪一級。溝通成功的關鍵是雙方都從明確指定的一組高質量 要求開始，并向下細化到可測試級別。例如，"應用程序必須可伸縮"要求對于可測試性而言還不夠具體。更具可測試性的要求可能為："應用程序在啟動時必須支 持 50 個響應時間為兩秒的并發用戶，并且必須可擴展為支持 500 個響應時間為三秒的并發用戶。"這一要求還應以系統和應用程序體系結構設計者都能理解的方式簡練表述出來。除了從特定的要求開始外，雙方還必須透徹了解將 對解決方案施加的技術、法律和業務約束。

基于這些要求和約束，應用程序設計者定義一組組件（在 Three-Layered Services Application 中指定），而系統設計者定義一組級（在"分級分布"中指定）。執行此映射的過程時，在雙方之間的討論中，由于每一方都知曉了另一方的觀點而時常導致組件和級發生重大更改。

要展開此項溝通活動，應將前述影響因素作為指南，將 Three-Layered Services Application 中指定的組件角色映射為級。例如，用戶界面組件可以映射為 Web 級，而業務組件幾乎總是映射為應用程序級。

下 一步是考慮應用程序中的每個組件，并將它分配到某一級。在大多數情況下，通過確定組件在應用程序中所扮演的角色，然后將它分配給在上一步中為該角色確定的 相應級來將該組件分配給某一級。但是，有些組件不可避免地具有獨特的運行或資源要求，從而導致其映射到交替的多級。雖然這些特殊情況是預料中的，但是如果 數量過多，您可能需要修改角色與級之間的初始映射關系。

將組件分配到級時，可能找不到與某個組件較好匹配的級。如果發生這種情況，那么兩個團隊必須協同工作，從修改組件以便更好地適合基礎結構或修改基礎結構以便更好地適合組件中進行選擇，以確定其成本和優點。

基于 Three-Layered Services Application，目前已確定了幾種常見的企業應用程序部署規劃模型：簡單 Web 應用程序、復雜 Web 應用程序、擴展企業應用程序以及智能客戶端應用程序。

簡單 Web 應用程序

簡單 Web 應用程序配置將所有組件部署到一個通用級。此配置（如圖 2 所示）從理解上是復雜程度最低且最簡單的配置。

圖 2: 簡單 Web 應用程序部署

復雜 Web 應用程序

復雜 Web 應用程序配置（如圖 3 所示）將表示組件和域組件進行分離，并將其部署到不同級（已專業化以處理其獨特要求）。

圖 3: 復雜 Web 應用程序部署

用 戶界面組件 (UIC) 和用戶界面進程組件 (Uip) 是對 Internet 公開的，并且可能潛在地與許多客戶端交互。由于這些表示層組件通常公開于公司防火墻外部，因此其安全要求通常比未公開的組件具有多得多的限制。此外，許多 組織要求公開于 Internet 中的服務器不能包含任何敏感數據。因此，通過將表示層組件單獨放入一級并配置該級使其具有最高安全性，可顯著提高解決方案的總體安全性，同時可盡量降低對 安全性要求相對較低的組件的影響。

由于表示層組件公開于 Internet 中，因此其性能和可伸縮性要求通常不同于域和數據訪問層組件的性能和可伸縮性要求。表示層組件通常為處理以突發方式與組件交互的許多并發用戶而進行優化。 域和數據訪問層組件通常為處理來自相對較少的源所發出的穩定請求流而進行優化。配置一個可充分支持這兩組優化的級可能是非常困難的。因此，解決方案是使用 兩級，并使每一層針對所駐留的組件類型進行優化。

擴展的企業應用程序

擴展的企業應用程序使用其他應用程序所提供的服務，并且還可能將功能作為服務公開，以供其他應用程序使用。圖 4 顯示此部署配置。

圖 4: 擴展的企業應用程序部署

將服務網關 (SG) 和服務接口 (SI) 放入 Web 級的原因與將表示組件放入 Web 級的原因相同，后者已在本模式中的前面部分討論。

智能客戶端應用程序

智能客戶端配置將用戶界面組件部署到客戶端級而不是 Web 級。之所以將表示組件移動到客戶端級，主要動機是豐富的用戶界面需要具有與用戶進行高度交互的能力。主流 Web 技術不支持這些豐富的用戶界面需求。圖 5 顯示具有其他級的智能客戶端配置。

圖 5: 智能客戶端應用程序部署

注意 : 大型企業應用程序通常看起來好像由本模式中討論的一個或多個模型組 成。例如，雖然擴展企業應用程序中的大多數業務組件都運行在應用程序服務器中，但是由于性能原因，可能有幾個組件運行在 Web 場中，并且可能有一個或兩個運行在瀏覽器中。

結果上下文

應用程序開發和系統基礎結構團隊之間的溝通，對于應用程序的成功部署至關重要。最終的部署規劃具有下列優點：

• 將組件分配到級以滿足兩個團隊的要求。
• 促進兩個團隊之間的通信，并詳細訂立兩個團隊同意遵守的合約。如果其中某個團隊無法實現其承諾，那么兩個團隊必須聚集在一起并重新訂立新的合約。

注意 : 除非公司文化認為應用程序和系統基礎結構觀點同等重要，否則應用 程序開發團隊和系統基礎結構團隊之間的溝通將不會產生最優的部署規劃。兩個團隊必須很靈活，并愿意達成妥協以使雙方都能實現其要求。