如何構建可伸縮和可用的雲計算多租戶架構？

雲計算多租戶幾乎用於所有軟體即服務(Software as a Service,SaaS)應用程式，因為計算資源是可伸縮的，而且這些資源的分配由實際使用決定。 話雖如此，使用者可以通過Internet訪問多種類型的SaaS應用程式，從小的基於Internet的小部件到大型企業軟體應用程式。 根據存儲在商業網路之外的軟體供應商的基礎架構上的資料不同，安全需求也在不斷增長。 應用程式需要多租戶是有許多原因的，其中最明顯的原因就是成本：在大多數情況下，為每個客戶增加幾個伺服器和一個資料庫是遠遠不夠的，儘管在安全要求很高的情況下這麼做有點用處。

本文是一篇概述性文章，調查並描述了可用的多租戶的類型，並提供了實現用例。

多租戶概念

多租戶的概念包含三層使用者集成：

資料中心層

基礎架構層

應用程式層

雲計算技術設計中的重要內容是多租戶的基礎架構和應用程式層集成。 此集成經過特別的調整，可節約成本和開發具有高度可伸縮性的SaaS應用程式，而這是以犧牲安全性和客戶隔離需求(segregation requirement)為代價。 很多情況下，這樣的設計都是有效的，儘管可能不太適用于金融應用程式。

在資料中心租用空間並提供伺服器、路由器和線纜以支援多個客戶軟體，這項功能自從矽谷創立初期就已經存在，因此使用者對於資料中心層多租戶應該並不陌生。 如果正確實現此配置，則該配置能夠提供最高級別的安全需求，它用防火牆和存取控制來滿足業務需求，還定義了對提供SasS的基礎架構的物理位置的安全控制。 大多數情況下，可以將資料中心層多租戶用作服務供應商，向公司提供場地來安置硬體、網路以及軟體。

基礎架構層的多租戶是最簡單軟體棧概念，一個棧專用於一個特定客戶。 與資料中心層多租戶相比，此配置更節約成本，因為棧是根據實際的客戶帳戶部署的。 在這種情況下，可以根據實際的服務使用來增加硬體需求。 另外，基礎架構層的每個使用者都可以選擇高可用性。 每個客戶都知道棧，所以軟體和硬體最佳實踐提供了一些實現選項。

應用程式層多租戶需要在軟體層和基礎架構層基礎上進行架構實現。 需要修改現有軟體架構，包括應用程式層的多租戶模式。 例如，多租戶應用程式需要一些應用程式方法和資料表來訪問和存儲不同使用者帳戶的資料，這會犧牲安全性。 但如果正確實現此操作，就可以節省成本。 對於小部件和簡單的Web應用程式，應用程式層多租戶是一個可行的解決方案，因為單個開發人員可以更快地開發軟體，也負擔得起調整規模的費用。 不足之處在于更複雜的應用程式架構和實現；與基礎架構處理多租戶不同的是，如果基礎架構發生變化，應用程式團隊需要保持程式設計模式的可伸縮性和可靠性，而且在未來可用。

服務

多租戶服務指定從在軟體應用程式中構建並直接存取的HTTP RESTful介面或WSDL Web服務終端訪問。 這些服務是建立多租戶模式的面向服務的應用程式的關鍵，因為它們可重用於多種事務類型。 例如，多租戶應用程式層服務的客戶可以通過調用URL來調用服務，它的返回結果會產生XML作為回應碼：

以下是引用片段：


HTTPs://visa.com/services/paymentOverview?account=OnlineShoesInc&pass=1234&range=1_month  


<Response >


   < Report >


    <Title >Online Shoes Inc Report</Title>


   <Data><x>01/01/2011</x><y>20.11</y></Data>


<Data><x>02/01/2011</x><y>22.24</y></Data>


  <Data><x>03/01/2011</x><y>20.21</y></Data>


  </Report>


</Response>

多租戶的最關鍵區段是在URL中設置帳戶參數，讓基礎架構知道哪個客戶在請求訪問資料。 這是服務層的多租戶的路由機制。

應用伺服器

應用伺服器是應用程式和基礎架構層多租戶的關鍵部件，因為多租戶會影響安裝、配置和應用程式代碼。 對於基礎架構層，應用伺服器的多租戶意味著調整更快、更廣，它配置了額外的伺服器，其中包括應用伺服器安裝、配置和應用程式代碼。 多租戶層不需要更改代碼（除非應用程式設定了特別的需求），調整也很簡單，一般由 IT 運營機構完成，而不是由開發人員重新設計應用程式原始程式碼。 通常，如果添加了新客戶，則需要添加一個相同配置的棧，以便更輕鬆地滿足安全需求。

以一個棧為例，假設該棧具有預先配置好的Web層（HTTP伺服器）、應用程式層（應用伺服器）和資料庫層（資料庫伺服器），這些層既可以部署到物理硬體，也可以部署到作業系統的虛擬實例。 這是對基於Web的應用程式增長進行規劃的一種典型方法，因為使用者對應用程式的需求可能是今天高、明天低的。 可以在容量小的時候調低這些實例，然後再根據需要增加實例。 在基礎架構的預防維修過程中（從需求收集的增加到運行實際的客戶事務），在大多數情況下，幾乎可以立即完成調整，因為這些棧是預先配置而且自動部署。

在應用程式層，應用伺服器的多租戶需要更改應用程式代碼，因為多個客戶會共用相同的應用伺服器。 無論使用者是運行一項事務還是同時運行一千項事務，回應時間都會受到影響，因為其他的客戶不僅是在同一個伺服器硬體上運行，而且在相同的邏輯系統記憶體中運行。 根據應用程式的不同，可能會有額外的安全需求。

事務

多租戶基礎架構和應用程式需要用事務來驗證每個客戶提交的請求。 此過程有助於驗證和授權使用者可以訪問的事務資源類型。

從應用程式層提取認證和授權服務有助於提高多租戶事務的可伸縮性、可維護性和重用性。 大多數添加到基礎架構的應用程式服務都需要授權，而專門用於授權的獨立子網、雲或應用伺服器集群可以滿足可伸縮性、可維護性和重用性需求。 授權服務也是一樣，因為可以在雲中或子網中根據事務增長來重用和調整此架構。

資料庫

作為很多應用程式的核心部件，資料庫對於多租戶的可伸縮性是至關重要的。 由於可伸縮性資料庫需要對基礎架構和應用程式層進一步規劃，因此您需要瞭解應用程式的需求，以及可伸縮資料庫基礎架構的最佳實踐。 如果基礎架構對每個客戶帳戶都有一個單獨的資料庫，那麼實現可伸縮性就會很簡單，因為已經存在針對單個資料庫的容錯移轉的最佳實踐。 還要考慮成本，因為大多數商用資料庫在每次增加客戶帳戶時都要進行授權，所以成本會呈指數級增長。

如果多租戶架構是應用程式層實現，那麼您必須足夠瞭解應用程式，然後才能進行資料庫規劃。 應用於多租戶架構的資料庫模式可能會有不同，因此必須進行相應的規劃。 在單個許可上節約成本和調整大小的一個常見應用設計方法是將客戶帳戶放入表名稱中，例如，customer123_payment，其中的customer123是使用者帳戶的唯一識別碼。 在為每個客戶添加資料庫實例時，或者在每個表中創建一個資料列以驗證客戶是否訪問合適的資料時，這種設計會大大增加表的數量。

構建多租戶服務

構建多租戶服務的要求包括：

定義基於RESTfu或WSDL的服務。

定義回應時間和性能目標。

確定可伸縮性和高可用性需求。

定義每個事務需要的服務。

根據事務客戶確定服務的負載量。

為服務創建部署和網路拓撲。

為實現配置和安裝而創建部署自動化腳本。

為實現開發而創建Unified Modeling Language (UML)序列圖。

(責任編輯：呂光)