web 應用程序轉化為多租戶 SaaS 解決方案
https://www.ibm.com/developerworks/cn/cloud/library/cl-multitenantsaas/index.html
想象一下，您有一個一直在市場上出售的 web 應用程序。您了解到雲基礎架構中的軟件即服務 (SaaS) 是行業的未來趨勢。您意識到您需要它，並且您的客戶也要求您提供 SaaS 版本的產品。
問題是，您需要快速、有效地轉換為 SaaS，並且最好能夠維持或增強您的盈利能力。
SaaS 應用程序和常規的 web 應用程序之間存在許多差異需要加以考慮。一些與技術有關，而另一些與業務模型的變化有關，公司在交付 SaaS 時必須能夠適應這種變化。
典型的 web 應用程序和 SaaS
SaaS 區別於其他應用程序的主要特征就是能夠使客戶在使用應用程序時按照使用量付費。他們不需要為軟件購買許可，也不需要安裝、托管和管理它。這方面的操作全部由提供 SaaS 軟件的組織負責。
多租戶是實現成功 SaaS 的關鍵
盡管訂閱應用程序的能力已經最低程度地滿足 SaaS 的基本條件，但是在實際中仍然不能滿足要求。實際上，SaaS 應用程序必須同時也是一種多租戶應用程序。
歸根結底都是與經濟方面的因素有關。主要的 SaaS 公司的 CEO 們都一致認為，如果沒有多租戶，那么發展 SaaS 業務是絕無可能的。（參見邊欄）。
一致意見：SaaS 需要使用多租戶
多租戶是 SaaS 供應商獲得成功的關鍵因素。— Marc Benioff，Salesforce 的 CEO
如果沒有多租戶的話，SaaS 不可能取得成功。— Treb Ryan，OpSource 的 CEO
我們實現了超低的計算成本 ... 我們在 SaaS 行業內擁有最低的成本（這是使用多租戶的結果）。— Lars Dalgaard，SuccessFactors 的 CEO
如今，ASP 試圖東山再起。然而，雲數據中心方法仍然使用單租戶模型來隔離用戶，這意味着它的運營成本將很高，因此價格也會很貴— Zach Neson，NetSuite 的 CEO — 我們的毛利潤超過 70%（因為使用了多租戶）。
多租戶對於我們來說真的非常重要 ... 它實現了一個非常高效的模型 — Tim Wallace，iPipeline 的 CEO
在 SaaS 這場競賽中，多租戶就是贏得這場勝利的籌碼。— Henry Olson，Edge Dynamics 的前 CEO
多租戶為整個訂閱模型提供支持...— Jeff Kaplan，THINKStrategies 的 CEO
多租戶體現了 SaaS 的效率水平
影響效率的主要因素來自於多租戶，即能夠容納應用程序的不同用戶，同時使用戶覺得應用程序完全服務於他們。我們已經習慣這種概念，因為它應用於系統中的各個用戶，但是與 SaaS 環境仍然有些細微的差別。在一個典型的企業 SaaS 環境中，用戶是指某個特定組織的員工組成的多個組，這個組織就是所謂的租戶。這類似於您在一個普通的 web 應用程序中看到的一樣，如果組織購買了這個應用程序的話；組織的員工就是應用程序的用戶，而該組織就是所有者。在 SaaS 模型中，組織是租戶，而非所有者，但是組織的員工仍然是用戶的身份。每名用戶都具體關聯到一個特定租戶（組織），而 SaaS 為每個租戶分別提供一份應用程序的副本，以供他們的用戶使用。
雲中的虛擬化影響 SaaS
簡單 web 應用程序和支持雲的 SaaS 應用程序之間的區別涉及 IT 行業目前最主要的兩個容量利用特性：
多租戶（之前引入）
硬件虛擬化。
雖然應用程序的效率主要取決於應用程序的多租戶架構，然而第二個影響效率的因素是硬件虛擬化。通過利用虛擬化技術，減少在使用普通的數據中心物理機器方法時產生的未使用的容量，雲環境極大地提高了給定數量的硬件的利用率。
此外，雲還提供了根據資源需求動態地為應用程序重新分配硬件的潛力。在較短的時間（幾分鍾）或從長遠來看（幾個月），這種靈活性都有助於將硬件與單一應用程序分離開來，然后再將它們分散到大量應用程序中，從而消除了差異，使硬件投資變得更加容易預測和管理。
現在，讓我們看一下將一個比較傳統的 web 應用程序轉換為一個支持 SaaS 的應用程序通常需要執行哪些步驟。
將 web 應用程序轉換為 SaaS 應用程序
要將您的 web 應用程序轉換為 SaaS 應用程序，需要滿足以下 7 個條件：
應用程序必須支持多租戶
應用程序必須具備某種程度的自助注冊功能。
必須具備訂閱/記賬機制。
應用程序必須能夠有效地擴展。
必須能夠監視、配置和管理應用程序和租戶。
必須有一種機制能夠支持惟一的用戶標識和身份驗證。
必須有一種機制能夠支持對每個租戶進行某種程度的自定義。
讓我們逐個地詳細了解這 7 個條件。
支持多租戶
多租戶是決定 SaaS 效率的關鍵因素。通常，應用程序支持多個用戶，但是前提是它認為所有用戶都來自同一個組織。這種模型適用於未出現 SaaS 的時代，組織會購買一個軟件應用程序供自己的成員使用。但是在 SaaS 和雲的世界中，許多組織都將使用同一個應用程序；他們必須能夠允許自己的用戶訪問應用程序，但是應用程序必須只允許每個組織自己的成員訪問其組織的數據。
能夠讓多個組織（SaaS 中的術語稱為租戶）共存於相同的應用程序，同時不會破壞這些組織的數據的安全性，具備這種能力的應用程序就可以稱之為多租戶應用程序。
多租戶可以分為幾個不同的類別（如列表下方的圖所示）：
雲中的簡單虛擬化，其中只對硬件進行共享。
共享應用程序，對每個租戶使用不同的數據庫。
共享應用程序和數據庫（效率最高，真正的多租戶）。
多租戶模型
多租戶模型
可以認為，第一個模型根本算不上是真正的多租戶，但是在雲環境中，它經常與虛擬化服務器配合使用，並被認為是一種多租戶形式。在實際應用中，這種模型無法滿足需求，並且僅僅比使用專用硬件的舊的 ASP 模型稍微好用一些。
效率最高的模型就是應用程序充分地共享數據庫和應用程序的業務邏輯。實現這種模型非常的困難，因為需要修改數據庫模式，向每個表和視圖添加一個租戶標識符，以及重寫每一個 SQL 訪問，向過濾器添加租戶過濾條件。如果代碼中任何必要的部分缺少這一邏輯，那么都將損害應用程序的數據安全性。
除了應用程序中出現的數據訪問實例外，還存在其他一些應用程序，比如報告編寫器（writer）和工具應用程序，必須修改這些應用程序來包含必需的租戶過濾功能，從而確保各個租戶的數據只能由這些特定的租戶訪問。如果訪問類型並不是直接來自於應用程序本身，那么就會產生問題，必須對這類問題進行控制。如果任何已授權的用戶可以編寫報告，那么必須阻止他們訪問不屬於其所屬租戶的數據。
自助注冊
應用程序必須具備某種程度的自助注冊功能，即便僅僅是一種請求機制，即產生一種向應用程序添加租戶的業務流程。
訂閱和記賬
必須提供訂閱和記賬機制。因為 SaaS 應用程序被設計為根據各種因素進行支付，如每個租戶的用戶數、應用程序選擇，還可能包括使用時間等，必須通過某種方式來跟蹤和管理應用程序的使用，然后生成可由租戶管理人員訪問的記賬信息。
擴展和管理應用程序
必須能夠隨着訂閱的增長進行擴展。雲基礎架構是實現這一目的的邏輯方式，因為它嵌入了許多功能，可以支持您實現有效的、高效的擴展。
同樣，必須提供治理和應用程序管理功能，以監視、配置和管理應用程序及所有租戶。
用戶 ID 和身份驗證
需要提供一種機制以支持用戶標識和身份驗證，允許用戶擁有惟一的身份標識。由於多租戶要求識別注冊到系統中的所有用戶，從而確定他們所屬的租戶，因此必須有一種明確的關系來將用戶識別為屬於某個特定租戶。這種用戶與租戶的關系是非常重要的信息，用於限制用戶可以訪問的數據。
電子郵件地址是實現這一目的的一種典型方法，通過這種方式可以確保惟一性，每個用戶可以被識別和標識為屬於某個特定租戶。
有多種身份驗證機制和集成方法，因此必須具備一種靈活的機制來識別用戶。通常，某個特定的租戶需要能夠利用其現有的 LDAP 或其他目錄服務或身份驗證機制來支持對 SaaS 應用程序的單點登錄。盡管這種外部的用戶身份驗證非常重要，但是，需要由 SaaS 應用程序確定已識別的用戶是屬於它們所宣稱的租戶的成員。
對每個租戶進行自定義
必須提供一種機制來支持對每個租戶進行一定程度的基本自定義，從而使它們具有惟一的 URL、登入頁面、標識、配色方案、字體，甚至包括語言。
對每個租戶的基本配置是預期的功能，但是要真正地滿足多租戶的需求，必須在基本配置的基礎上對每個租戶實現一定程度的自定義。
所需的典型定制類似於租戶對內部應用程序版本所作出的定制。包括添加字段甚至是表格，設置特殊的業務邏輯，或集成另一種應用程序。在每個租戶的基礎上能夠進行這類自定義，同時無需建立單獨的實例（否則會降低多租戶設計的效率），這就是高性能 SaaS 架構的典型特征。
需要考慮的性能問題
多租戶 SaaS 應用程序的性能問題通常與那些容納同樣數量的用戶、具備相同的活動程度的 web 應用程序所遇到的問題相同。有許多不錯的方法可以解決 web 應用程序中日益增長的容量需求問題；通常來講，這些方法也都適用於多租戶 SaaS 應用程序。這些技巧通常包括橫向/縱向擴展和在一組服務器之間實現負載均衡。
橫向/縱向擴展
雲基礎架構提供了許多以動態的、自動化的方式實現這種可擴展性的機會，從而能夠在需要時提供資源，以及在使用更少的資源就可以滿足性能服務水平協議（SLA）的情況下相應地減少資源。可以對這種靈活的能力進行調整，從而能夠在提供服務的同時避免造成資源浪費：
橫向擴展通常用於應用服務器層。
縱向擴展通常用於數據庫層。
數據庫集群化
對於 SaaS 應用程序，成功產品的用戶總數可能會非常的高；在某些情況下，對數據庫進行縱向擴展可能並不是一種好方法。許多數據庫技術都能夠提供一種集群化的數據庫模型，允許對同一個數據庫提供更多的容量。DB2® 提供的一些選項可以很好地應用於這種模型，並且可以用來創建數據庫集群。
地理、分區和同步
然而，取決於 SaaS 應用程序及其用戶群，其他一些技術也許更加合適。由於 SaaS 可以從世界上的任何位置訪問，因此其用戶群可能位於非常遠的地方；這種距離會由於較長的網絡拓撲而導致性能下降。
對於這類情況，使用分布在不同地區的雲、對數據進行分區或使用同步維護一致性的效果可能會更好一些。究竟選擇哪一種方法取決於具體應用程序的性質。一些用戶可能無法接受長距離的同步。
獨立的數據庫
當然，在數據庫容量無法滿足需求時，最根本的方法（至少對於 SaaS 應用程序是這樣）是建立單獨的數據庫。任何希望獲得多租戶 SaaS 應用程序的人都必須考慮到這種方式會導致不太可靠的解決方案，即需要針對每個租戶提供數據庫支持，這將直接導致效率低下，而這正是多租戶力求避免的問題。
如果必須分割應用服務器以便只為一個數據庫提供服務，那么多租戶的高效率特性將進一步被折損。在競爭激烈的市場中，多租戶的這些高效率特性對於 SaaS 公司獲得成功至關重要。
在設計中利用負載均衡
在不得不使用獨立數據庫的情況下（不管出於什么原因），盡可能保持高效率的一種方法就是采用一種特殊的多租戶設計，能夠允許負載均衡的集群中的任何應用服務器訪問多個數據庫中最合適的那個數據庫。通過這種方式，負載均衡的集群的效率就可以得到保持，所有應用服務器都能夠連接到任意數據庫以完成它們所支持的用戶會話。這在多數據庫的限制下實現了最大程度的效率。
容量並不是惟一的要求
除了滿足容量需求外，使用多個數據庫還出於正當理由，比如要求對某些高度安全的租戶使用加密的數據庫。容量不是問題，因此重要的是采用一種可以最大化效率的設計，即使需要一種本身比較低效的模型。
需要考慮的安全性問題
大量調查顯示，SaaS 應用程序的用戶通常將安全性排在首位，或至少非常接近首位。任何 SaaS 提供商都不能忽視安全性。但是，數據安全性的概念常常被局限於 SaaS 應用程序本身的上下文內。
大多數 SaaS 應用程序架構采取了一些保護數據安全性的措施，將阻止一個租戶查看另一個租戶的數據作為一個基本要求。但是：
SaaS 應用程序必須具備的一種能力就是與其他應用程序集成並交互。
這些所謂的其他應用程序中的其中一些可能位於應用程序的外部（不受 SaaS 提供商的控制）。
並不是所有 SaaS 應用程序都被設計為對外部應用程序具有訪問性。
這些其他應用程序可以是需要訪問或共享數據的內部應用程序；也可以是對數據進行挖掘以獲得趨勢的分析或報告編寫工具。即使是數據庫管理員使用的實用工具也會引起安全問題，如果租戶可以使用它們訪問，或者更糟，操作不屬於它們的數據的話。
面向 SaaS 的最佳實踐架構必須考慮到並不是所有數據訪問都在應用程序的控制之下；必須有一些機制來確保為每個租戶提供數據保護，不管是通過 SaaS 應用程序還是通過一些外部應用程序實現訪問。
選擇技術堆棧
在選擇技術堆棧時經常需要進行一些權衡；對於 SaaS 應用程序尤其如此，因為要對所有租戶作出決策。讓我們看看在這個過程中需要考慮的一些問題。
操作系統考慮
web 應用程序中的操作系統也許是與用戶最不相干的，因為用戶是通過瀏覽器進行交互的。然而，一些經濟和技術方面的因素可能會有一些影響：
如果需要依賴特定的代碼，而這些代碼又依賴於操作系統，那么在做選擇時需要考慮這種約束。
如果存在集成外部應用程序的普遍需求，而在某種操作系統上進行這種集成要比在另外一種操作系統上更好，那么在選擇時也要考慮到。
考慮到雲的經濟效益，人們總是傾向於那些性能良好、許可費更低的操作系統。擴展 web 應用程序的主要方法就是橫向擴展；這意味着隨着 SaaS 應用程序的發展，web 應用服務器實例的總數也將隨之增加，這將產生直接的操作成本。
數據庫考慮
web 應用程序中的數據庫對於最終用戶來說可能也不是一個關鍵的考量因素，因為他們的交互是通過瀏覽器完成的，並且只要應用程序能夠存儲和檢索其數據，那么數據庫與他們就沒有多大的關系。
經濟和技術方面的因素再一次對應用程序開發人員產生了影響。如果應用程序需要依賴數據庫的一些特殊特性，那么在做選擇時就會受到限制。
數據庫的選擇對於應用程序的許多設計都非常重要，對 SaaS 環境的特殊需求也會影響數據庫的選擇。
在 SaaS 應用程序中，由於最終的用戶數的原因，對數據庫的要求會更高一些；因此數據庫的可擴展性非常重要。數據庫可擴展性通常在一個單獨的實例上實現，同時使用越來越強大的數據庫服務器滿足要求更加苛刻的應用程序。但是 SaaS 應用程序要求的可擴展性可能會超出縱向可擴展性的極限，因此，數據庫可擴展性的下一步是采用集群化功能。
在雲環境中實現這種集群化的能力可能會影響對數據庫的選擇。例如，可能會選擇 DB2，因為它能夠運行在廣泛的操作系統上，提供縱向可擴展性，以及它可以靈活地選擇通過多實例集群和冗余實現可擴展性。例如，可以在雲中建立一個 DB2 HADR（高可用性災難恢復）集群。
應用服務器考慮
和選擇其他技術堆棧一樣，選擇應用服務器也是一項與 SaaS 應用程序開發人員有關的決策，因為最終用戶交互只通過瀏覽器完成。但是，出於許多應用程序設計方面的考慮，應用服務器的選擇存在很重要的差別，對 SaaS 環境的特殊要求也會影響它的選擇。
使用了特殊特性或 WebSphere® 之類的應用服務器的插件（add-on）組件的應用程序將需要在雲中使用這種應用服務器。
選擇應用服務器的基本原則通常是在應用程序生命周期的早期作出的，因為應用程序可能會因為某些特性而受益，或者某些第三方插件或集成功能對於應用程序來說非常重要。有些時候，可能僅僅是因為組織的專有技術和內部標准要求在技術堆棧中使用特定的組件。
在選擇和配置用於 SaaS/雲環境的技術堆棧時，決策點包括平衡技術和經濟方面的力量，從而實現一個較好的結果。
靈活性是技術演化的關鍵
在 SaaS 架構中，擁有對將要使用的技術堆棧作出決策和權衡的能力，以及在稍后的階段重新審視這些決策的能力是非常寶貴的。隨着技術的不斷變化，領先的雲提供商將並入新的中間件應用程序和功能，能夠為您的 SaaS 應用程序采用這些應用程序和功能的能力也是一種優勢。
強制您作出選擇並使您鎖定到某種特定的技術堆棧，這種 SaaS 應用程序架構將不利於 SaaS 應用程序的未來演變和適應能力。面向服務架構的核心概念十分適合於提供 SaaS 應用程序所需的敏捷性和靈活性。降低耦合程度將提供靈活性，而這種靈活性使實現戰略戰術演變成為可能。
在本文的其余部分中，我們將使用 Corent 的多租戶服務器（Multi-Tenant Server™）提供一個示例，演示如何通過最少的步驟將一個 Java™ 開源記賬 web 應用程序轉換為一個多租戶 SaaS 應用程序。
使用 Corent 的多租戶服務器自動轉換為 SaaS 應用程序
雲提供商提供了一系列廣泛的功能，可以容納幾乎任何 web 應用程序。要將這種應用程序完全轉換為一個多租戶 SaaS 應用程序，通常需要對應用程序代碼作出大量修改，並重新設計和配置數據庫。
Corent 的多租戶服務器使 ISV 能夠采用一種不同的方法，使用中間件層提供關鍵的多租戶特性（從而保護對現有代碼的投資）。我將描述如何通過 4 個步驟將一個典型的單租戶應用程序轉換為一個多租戶 SaaS 應用程序。我們將要轉換的應用程序就是 jBilling，這是一個流行的開源 Java web 應用程序。
步驟 1. 將數據庫模式轉換為一個抽象模型
web 應用程序的典型堆棧如圖 1 所示；應用程序與數據庫通信，通常通過 Hibernate 這樣的數據持久化層完成。
圖 1. 雲中的典型 web 應用程序堆棧
雲中的典型 web 應用程序堆棧
要將應用程序轉換為多租戶應用程序，必須重新設計數據庫以添加更多的字段來管理租戶身份識別數據，在根據租戶進行數據過濾時需要用到這些數據。
SaaS-Factory™ 應用程序用於讀取現有應用程序數據庫的模式。隨后，它將為這個數據庫創建一個模型，該模型稍后用來在 MySQL 中生成一個新的數據庫，該數據庫在表中新增了 TenantID 字段。此時，用於多租戶服務器的幾個額外的表（包括租戶信息表）就創建好了。
圖 2. 創建 MetaModel 數據庫模式
創建 MetaModel 數據庫模式
由於 MetaModel 數據庫看上去與原始應用程序完全相同，具有相同的表和字段，因此原始應用程序可以繼續與 MetaModel 數據庫交互，就好象和此前的 MySQL 數據庫交互一樣。隱藏在模型下的真正的數據庫可以用多租戶應用程序所需的 TenantID 字段生成。
MetaModel 數據庫僅僅是一種抽象，並沒有實際保存任何數據：它只是一個模型。因此，在生成真正的數據庫時，沒有理由不可以在任何受支持的關系數據庫管理系統（RDBMS）中生成。在 ISV 希望通過選擇不同的 RDBMS（比如 DB2）而修改技術堆棧，以利用某些特性或為應用程序實現更好的性能時，這種抽象性就可以派上用場。
步驟 2. 擴展用戶身份驗證流程
任何多租戶 SaaS 應用程序必須能夠為通過身份驗證的用戶管理必要的會話信息，從而建立用戶所屬的租戶。應用程序可以采用多種方法進行身份驗證；因此，對於進行轉換的任何應用程序，必須進行分析並理解其身份驗證方法。
Corent 的多租戶服務器
Corent 的多租戶服務器使我們的客戶能夠將現有的單租戶 web 應用程序快速轉換為完整的多租戶 SaaS 解決方案，並且可以與雲兼容，不需要重寫應用程序。Corent 提供了效率最高、最經濟有效的多租戶方法。這種實現多租戶的插件式中間件解決方案具有安全性、可擴展性，可以極大地降低服務交付的成本。
您可以靈活地選擇自己喜愛的技術堆棧，自主選擇要使用的操作系統、數據庫和應用程序。借助多租戶服務器的靈活架構，您可以自己決定如何部署您的 SaaS 應用程序，自己構建或是在任何雲中構建。這使得 SaaS 應用程序可以部署為公共服務或私有 SaaS™，后者為一個有限的群體提供服務，比如一個大型企業，其中的各個部門就是租戶。
多租戶服務器附帶了 SaaS-Cockpit™，支持您配置、管理和監視您的 SaaS 用戶，還提供了 SaaS-Factory™，支持對 SaaS 應用程序進行基於租戶的自定義和增強。通過使用 Corent 的全套解決方案，大大提高了將應用程序轉換為 SaaS 的速度。
Corent 和 IBM® 目前都提供了有限的、符合要求的產品，提供免費的、概念驗證的轉換，將把 ISV 的 web 應用程序轉換為一個運行在 IBM SBDT 雲中的多租戶 SaaS 解決方案，並允許 ISV 試運行最終的 SaaS 解決方案。
步驟 1 向您展示了如何建立一個多租戶表以及添加一個用戶表，從而在應用程序數據中維護這種關系。我們的目標是實現一種方法來擴展應用程序的用戶身份驗證流程，從而使用戶在登錄后即可與對應的租戶匹配，而 TenantID 則成為會話信息的一部分。
可以通過許多方式實現這一點；這取決於應用程序的實現。如果使用 Tomcat 作為應用程序 servlet 容器，那么可以利用容器托管式身份驗證來發起一條業務規則，該業務規則運行在多租戶服務器之上，用於查找與用戶關聯的 TenantID。或者，使用一個 servlet 過濾器來檢測並設置線程本地變量 TenantID。對於本例中的 jBilling，應用程序直接對其用戶表進行驗證來完成身份驗證。因此，要提供增強的身份驗證，需要對身份驗證代碼進行一些簡單的修改，添加一些流程來查找存儲在新表中的用戶的租戶信息。
用戶經過身份驗證，並且知道了他們所屬的 TenantID，現在已經具有足夠多的信息來過濾數據，從而使用戶只能夠訪問其所屬的租戶的數據。
步驟 3. 配置數據庫連接
Corent 多租戶服務器構建在面向服務的架構之上，使用了一個 MetaModel 數據庫（如 步驟 1 所述）。該 MetaModel 被用作一個抽象層，建模應用程序的原始數據庫，而應用程序的數據庫通信被重定向到 MetaModel 抽象而不是實際的數據庫實現。方法就是重新配置 jBilling 的 JDBC 連接以訪問 MetaModel 數據庫而不是實際的 MySQL 數據庫。對於使用 Hibernate 的應用程序，配置 Hibernate 的 Corent 方言（dialect）。
在作出這些修改后，應用程序數據庫調用現在被指向到 MetaModel 數據庫。這些 SQL 事件被 Corent Agile Controller™ 截獲並被傳遞給 Corent 的 ADBC™（敏捷數據庫連接器，Agile DataBase Connector）。ADBC 獲得應用程序提交給 MetaModel 數據庫的 SQL 語句並進行解析，然后為在會話中提交了 SQL 的用戶的 TenantID 添加過濾條件（例如，TenantID =
由於對 SQL 語句的處理是在將它們提交給 MetaModel 數據庫后完成的，並且用戶所屬的租戶已知，Corent Agile Controller 將截獲並執行更加復雜的操作，包括查找特定於租戶的流程和配置。因此，可以針對每個租戶執行一些具體的操作，甚至是替換不同的數據庫連接，從而使某個租戶可以使用 DB2 數據庫，即使所有其他租戶使用一個 MySQL 數據庫。或者，某個租戶可以進行額外的 SQL 操作，將它們可以檢索的數據限制為最近 90 天以內輸入的記錄。所有這些基於每個租戶作出的自定義都可以通過多租戶服務器內置的 Agile Rules Engine™ 實現，不需要對原始的應用程序代碼做任何修改。
圖 3. 基於每個租戶的自定義結構
基於每個租戶的自定義結構
完成 jBilling 應用程序的全部轉換只需要對應用程序做一些細微的修改，增強身份驗證的最主要問題是在會話信息中包括租戶信息，以及修改數據庫連接以指向多租戶服務器。您可以看到對 jBilling 的修改總結為以下幾條：
原始應用程序
源文件數：897（Java 和 jsp）
總的代碼行數：76,621
轉換后的應用程序
增加的源文件的數量：2（標准模板）
修改的代碼的行數：少於 100
應用程序業務邏輯修改：0
包括所有分析和准備工作（判斷哪些位置需要修改代碼）在內，對 jBilling 的轉換只用了不到一周的時間。許多修改就是在用於 JDBC 訪問的 Java 代碼片段中重復修改某個行，如果使用的是 Hibernate 之類的數據庫持久層，那么這些修改都是可以省去的。
步驟 4. 將新的多租戶 SaaS 應用程序部署到雲中
現在，可以使用 SaaS-Factory 將 SaaS 應用程序部署到一個指定的服務器中，包括雲中的服務器。
為應用程序和數據庫選擇了一個服務器后，將生成目標數據庫（例如，對於我們的 jBilling 應用程序，就是在 Windows® 服務器上使用 MySQL 數據庫），並將進行充分配置的多租戶服務器應用程序以一組 .WAR 文件的形式部署到所選的應用服務器。多租戶服務器可以使用任何現代的 J2EE Servlet 容器，而且還針對 WebSphere 應用服務器進行了認證。
部署后的應用程序現在已經能夠處理多個租戶。然而，原始應用程序現在缺少一個治理或管理界面來管理租戶或監視多租戶應用程序。
SaaS-Factory 還可以生成並安裝一個稱為 SaaS-Cockpit™ 的配套應用程序，該應用程序提供了這些基礎的多租戶服務。它可以像主應用程序那樣訪問 MetaModel 數據庫並具有一個管理屏幕，用於指配租戶、分配 Tenant Administrator 帳戶和為各種可用的基於每租戶的應用程序配置設置基本參數。還提供了一些管理工具，用於監視租戶及其用戶並進行報告。由於 SaaS 應用程序的典型特征之一就是需要跟蹤租戶訂閱和記賬，因此將出現一些用於記賬的工具或與外部記賬系統的集成。
圖 4. 將新的 SaaS 應用程序部署到雲中的結構
將新的 SaaS 應用程序部署到雲中的結構
就 SaaS 應用程序部署而言，這種程度的部署是相當基礎的。應用程序的特征在轉換后仍然保持不變，標准的部署場景，包括使用雲管理工具創建模板和傳播應用程序實例，可以用於部署滿足應用程序對可擴展性、靈活性、彈性和冗余性的要求的運行架構。
一個典型的 SaaS 應用程序可能會允許通過一個負載均衡器訪問一組應用服務器並連接到數據庫服務器。數據庫服務器本身可以作為一個集群部署，同時使用多個數據庫服務器提供冗余和可擴展性。
IBM DB2 提供了一些技術和配置，可用於實現彈性和有保障的恢復時間，以及允許對數據庫上的負載進行分配：
通過使用備用模式（secondary mode）作為只讀數據庫，DB2 HADR（高可用性災難恢復）配置可以同時提供具有彈性的可用性和一些負載均衡。
IBM pureScale 技術和 Tivoli System Automation (TSA) 支持集群化的數據庫環境，該環境中的多個節點共享處理負載，但是對硬件和操作系統配置的限制較多。
對於 SaaS 應用程序，數據庫可用性和故障轉移正變得越來越復雜，因為與傳統的客戶端軟件（圖 5）相比，任何一次宕機對客戶/租戶產生的影響的范圍都會更大。
圖 5. SaaS 部署架構，實現可擴展的彈性雲運行
SaaS 部署架構，實現可擴展的彈性雲運行
未來的發展趨勢將是那些使應用程序能夠持續運行的能力，即使出現數據離線重組、模式演變、版本升級和高負載變化。IBM 的 pureScale 技術正在從 z System 遷移到 AIX® 和 Linux®，並支持以前專門針對專用大型機環境的容量處理和正常運行時間。
結束語
信息技術產業正在向 SaaS 演變，正如您所臆測的一樣，該領域已經開始出現一些顯著的變化。雲計算正在蓬勃發展，其發展速度遠遠超過了其他任何 IT 浪潮，而 SaaS 正是背后驅動這種增長的因素。這種轉變要求公司重新考慮他們的業務組織，並通過一些新的思路思考以雲為中心的 IT 世界中的服務交付。對於軟件供應商，需要更加迫切地理解、准備和實現這種轉變，否則就會被遠遠地拋在后面，它們的產品也會過時，成為數字垃圾。
雲中的 SaaS 在技術和業務方面都與傳統的軟件供應商模型有着顯著的不同。這些差異增加了 ISV 過渡到 SaaS 的風險。要緩解這種風險並縮短面市時間，ISV 可以利用一些可靠的技術、產品和合作伙伴來實現這種轉變。