PaaS環境的軟體設計模式

備註：Codename:BlueMix 是一款 Beta 級產品，隨著我們不斷讓功能更加完善和更便於使用，它也將不斷改進。 我們將竭盡全力保持本文最新，但它並不總是完全跟上現狀。 感謝大家的理解！

有效的、創新性的應用程式甚至都有可能被破壞或在市場上遭遇失敗，因為它們無法滿足性能、回應時間和總體可靠性等 NFRs。 在傳統上，架構師通過修改基礎架構的形狀和大小來回應 NFRs。 併發使用者數量通過將使用者會話分區到多個並行運行的系統上來處理；回應時間可通過消除性能瓶頸（常常在資料庫和存儲使用上）來改善；服務需求通過添加能夠快速執行大容量事件記錄的新服務來滿足；等等。 但在雲環境中，架構師管理 NFRs 的方法方面的選擇更加有限。

雲基礎架構即服務 (IaaS) 平臺使得基礎架構的修改更經濟、更輕鬆（這解釋了 IaaS 環境在快速變化、快速擴展的工作負載中流行的原因），而且架構師的選擇也相應地減少了。 雲平臺即服務 (PaaS) 環境在此範例上更進一步，從使用者角度講消除了水準擴展、元件放置、日誌記錄和系統管理。 這些操作都會發生，但作為 IT 架構師，您無法控制（或幾乎無法控制）它們。

但是，架構師對 NFR 的管理不會在雲環境中消失。 相反，它們轉移到了應用程式的內部機制中，轉變為了一些應用程式設計模式。 這些模式的實現可確保雲應用程式是雲操作環境 (CloudOE) 中的 「良民」，它們不會連接 CloudOE 機制並與 CloudOE 的工作方式保持一致。 本文將介紹它們在 PaaS 環境中解決的 NFRs 模式和類型，還會介紹 IBM Codename: BlueMix，這是一個開放標準 PaaS CloudOE，您可以在其中讓設計模式生效。

NFRs 和應力案例

功能性需求和非功能性需求在概念上不同。 二者都表示定義的系統的利益相關者或影響者的動機。 隨著 IT 技術和角色的演變，軟體系統會繼續增加利益相關者的數量和他們的請求的複雜性。 除了系統的使用者之外，利益相關者和它們各自的需求包括：

開發人員：代碼的結構和清晰度 維護人員：記錄和調試工具 測試人員：跟蹤和提供的其他問題判定工具 供應商：應用程式使用培訓的簡單性 運營商：提供的資訊水準 運營經理：解決方案的可伸縮性 建構管理專家：支援的中介軟體包裝和級別 資料庫管理員資料庫資源使用和優化 服務經理：監視操作所需的技能和工作 網路和系統管理專家：支援的工具 企業架構師：與公司標準架構的合規性 安全官員：實現的安全類型 採購人員：解決方案的可伸縮性和適應性 評估人員：審核工具 支援人員：使用者操作的複雜性： 溝通人員：介面的清晰性

這種情況考慮了具有困難的功能性需求和嚴苛的 NFRs 的複雜系統，這些 NFRs 包括非常高的可用性、快速的性能和挑戰性的安全需求等。 雲計算還增加了對極高的靈活性和地理分散性的需求 — 隨時隨地都可用。

IT 架構師如何確保系統的架構能夠令人滿意地包含了所有這些需求？ 這裡的危機在於，需求的解決是相互隔離的，沒有考慮到一種需求的解決可能對其他需求帶來什麼樣的影響。

要從整體上考慮需求，可將它們構想為相對的 「力（force）」，如圖 1 所示。 IT 解決方案可能以最優方式解決這些力。

圖 1. 需求是相對力

在圖 1 中，這些力量包括：

功能性需求 我們在 IT 系統上施加的品質需求和約束 (NFRs)： 運行時品質 非運行時品質 業務約束 技術約束

特別重要的是可能在任何給定時刻一起運行的相對力的組合。 此外，一些同時作用的力也會相互加強。 也就是說，它們的影響會增加系統的特定部件上的應力。 舉例而言，大量併發使用者與發生錯誤後較短的恢復時間相結合，可能在系統發生故障後給使用者識別子系統帶來壓力，從而導致產生大量操作和實際阻止操作運行。 類似地，嚴格的回應時間和具有有限資源的資料庫相結合，可能帶來無法處理的請求組合，除非應用程式是專為處理它而設計的（舉例而言，通過使用緩存機制）。 就像在土木工程中一樣，我們使用詞彙應力案例 來識別這些同時作用、相互加強的力。

雲供應商的服務水準協定 (SLA) 是解決方案的需求（約束）之一，可能影回應力案例。 例如，如果 IaaS 合同指定了一定容量的虛擬網路，託管應用程式的內部輸送量上的這種潛在約束可能需要特定的機制來實現外部輸送量目標。

有時，一種應力案例可能使得無法同時滿足所有需求。 在這些情況下，可能必須設定一組更加受限的需求，以便為使用者維護合理的服務水準。 我們將這些案例稱為降級的操作。 降級的操作在雲應用程式中可能無法避免，所以小心地設計它們並在它們出現時與使用者溝通很重要。

降級操作的一個簡單、普遍的示例與分片資料庫的最終一致性 機制由關。 這些資料庫在雲中提供了多個讀取實例來確保性能和可靠性，而特定資料元素的寫入始終在同一個實例上完成（為了保持寫入一致性）。 因為複製新資料所花費的時間有限，所以某個資料庫實例中的資訊可能在讀取時不一致；它只是最終 一致的。 使用最終一致的資料的應用程式必須能夠支援降級的操作，通過做笑話使用者感知到的不一致性（例如，通過顯示仍在緩衝區中，還未提交的更新），或者（如果沒有活動資料可用）通過在資料庫最後更新時提醒使用者。

一個示例

為了説明解釋如何處理 CloudOE PaaS 環境中的 NFRs，我們將基於虛構的 AMGRO.cloud 公司開發一個示例，這家零售商通過獲取傭金的獨立兼職銷售人員網路來銷售其商品。

AMGRO 決定通過提供一個目錄來購買應用程式，開始進入線上銷售市場。 為了加速部署，AMGRO 計畫在一個雲供應商的 PaaS 環境中開發了該應用程式（該供應商將提供 Web UI、安全服務和存取控制），並且連結到在交付服務和支付服務方面的市場領導者的線上服務。 新應用程式還必須與現有的 AMGRO 企業資源規劃 (ERP) 平臺相集成，以便用於會計和倉庫管理。

AMGRO 的新應用程式的 NFRs 包括：

併發使用者數量預計約為 10,000。 所有目錄檢視預計在常規 ADSL 連接或高速蜂窩網路上只需不到 1 秒即可獲得。 AMGRO 的雲環境和支付服務預計具有 24x7 的可用性。 AMGRO 和交付服務提供者通過常規的 Internet 連接。

對交付服務請求的回應具有 2 小時的承諾 SLA。 此外，交付服務的可用性目標在晚上、他們執行系統維護期間有所不同。 出於合同原因，此 SLA 不應更改。

因為新的 PaaS 應用程式將連接 AMGRO ERP 系統，所以此介面是高度敏感的，必須得到足夠的保護。

圖 2 演示了 AMGRO 示例。 （此圖和本文後面的大部分圖都採用了 TOGAF ArchiMate 概念。 ）

圖 2. AMGRO 示例

在 AMGRO 的系統中，以下 NFR 組合一定屬於應力案例：

案例 1：亞秒級回應時間，但系統載入了：

10,000 個併發使用者 亞秒級回應時間

案例 2：亞秒級回應時間，但外部系統緩慢或不可靠：

亞秒級回應時間 通過常規 Internet 連接交付和支付服務

案例 3：應用程式應該是可用的，但外部系統是非同步，或者具有不匹配的 SLA：

24x7 可用性 Internet 連接 可用性 SLA 不匹配 離線流程

案例 4：混合雲：

安全的連接

PaaS 應用程式、NFRs 和架構師的角色

一個基於雲操作環境的 PaaS 解決方案會利用 CloudOE 程式設計模型來管理 NFRs，為應用程式架構師減輕了一些任務：

在水準範圍上管理使用者負載：CloudOE 根據工作負載在虛擬機器中添加和刪除元件實例，從而進行進行相應調整。 應用程式架構師不再需要處理可伸縮性，但現在必須理解哪些元件必須同時擴展，以及如何管理通信的元件之間的不同擴展水準。 為關鍵的路徑利用最新的技術：在內部部署的解決方案中，架構師在系統的關鍵區段（資料庫、消息骨幹等）中利用了最新的技術。 在雲計算中，您採用了標準技術並擁有有限數量的基本選擇。 消除了硬體或軟體技術上的不一致，但關鍵的路徑必須通過設計模式來處理。 通過放在同一位置可消除性能瓶頸：將具有高交互程度的工件相鄰放置，是一種改善性能的常見做法。 您仍然可以對 CloudOE 中的應用程式這麼做（假設這種捆綁不會妨礙水準擴展），但您可能無法控制具有多個分散式副本的應用程式和技術服務（例如 MongoDB）的協同定位。 控制 SLA：在 CloudOE 中，沒有應用程式是孤立的。 出於增強系統總體可靠性的用途，涉及的元件可以在任何地方。 另一方面，（應用程式）本地的雲供應商提交的 SLA 可能與不同雲平臺上的另一個連接的元件提交的 SLA 不同。 應用程式架構師無法假設具有統一的 SLA，必須考慮回應丟失或延遲的可能性。

PaaS NFRs 管理模式

如果繪製 PaaS 的 操作上下文圖，我們可確定 4 種類型的外部角色：

應用程式本身的使用者（應用程式服務的消費者）：這些角色同行具有與應用程式的回應時間和可用性相關的需求。 此外，由於併發使用者數量的不同，典型的雲應用程式常常具有無法預測的複雜性。 外部系統：這些是雲外部的物理系統，不在應用程式架構師的控制之下。 事件驅動的服務：一些服務可能實現長期運行的流程或一個非同步介面。 內部部署的系統（混合服務）：內部部署系統的雲元件和內部元件都在應用程式架構師的控制之下，因此架構師可根據 NFRs 來調節它們。

與 4 種 PaaS 角色對應，我們確定了 4 種與 NFR 相關的設計模式：

無狀態應用程式模式，管理使用者數量的擴展、高可用性和對短回應時間的支援，甚至在系統具有負載時亦可執行此操作。 非同步應用程式模式，在長期運行的服務需要參與應用程式流程時，管理回應時間和持續可用性。 外部 API 模式，在流程流涉及到外部系統時管理高可用性和擴展。 安全 VPN 模式，安全地集成內部部署的系統。

圖 3 演示了 4 種模式和它們與 4 種角色的關係。

圖 3. PaaS 模式

無狀態應用程式模式

無狀態應用程式模式的目標是，確保系統可同時擴展，服務大量請求並保持執行路徑盡可能短。 圖 4 演示了無狀態應用程式模式。

圖 4. 無狀態應用程式模式

使用的基本機制是 CloudOE 水準擴展功能。 水準擴展功能通過執行環境實例的動態打開和關閉，以及系統級路由器/平衡元件來提供。

要高效地使用動態擴展，應用程式元件必須完全是無狀態的。 通常在傳統的 Web 應用程式中，所有來自某個使用者的請求都會路由到同一個應用伺服器實例，該實例會將會話資料和對話狀態保存在記憶體中。 會話 cookie 被用作從記憶體檢索會話資料和處理請求的金鑰。 在雲計算中，大多數託管雲實現都無法保證，是同一個應用程式實例將為一個會話服務。 會話請求必須由面向 Internet 的路由器路由到不同的應用程式實例。 因此，在此模式中，要保持執行實例完全無狀態，會在外部使用記憶體存儲，並作為服務在託管雲提供的所有實例之間共用。 （否則，在一個實例的所有會話關閉之前，不可能進行向下調整。 ）