多租戶技術的跨部門和虛擬團隊的解決方案

時間 2019-11-12

標籤租戶技術跨部門虛擬團隊解決方案简体版

原文原文鏈接

1 前言

通過多年的企業信息化建設，Office系統逐步造成有9營業場所的分部門、9專業應用子系統、20獨立的信息模塊、330一種方法。這些系統或模塊內置於Microsoft IIS、Apache Tomcat、Weblogic、Cordys BOP上，相互彼此獨立、互不影響。web

在不考慮反覆投資、資源共享、便於運維的狀況下，仍存在一些長期很是難解決的問題：數據庫

（1）、各個系統的組織、帳號不統一。維護困難。
（2）、在一些系統或模塊中。對於人員跨部門的狀況。仍以兩個及以上帳號的方式處理，不只業務不直觀。而且操做性比較差。
（3）、虛擬團隊支持都是經過開發編碼處理。實施週期較長，缺少靈活性。編程

由於雲計算議題的發燒，在IaaS虛擬化資源池和共用的數據中心內，怎樣以單一系統架構與服務提供多數client一樣甚至可定製化的服務，並且仍然可以保障客戶的數據隔離。讓多租戶技術成爲上述需求提供一套解決方式。後端

2 多租戶技術概述

2.1 多租戶技術概述

參考百度百科的定義，多租戶技術（英語：multi-tenancy technology）或稱多重租賃技術，是一種軟件架構技術。它是在探討與實現怎樣於多用戶的環境下共用一樣的系統或程序組件，並且仍可確保各用戶間數據的隔離性。數據結構

多租戶技術源於1960年代。不少公司爲了要使用不少其它的運算資源，向持有大型主機（Mainframe）的供應商租用一部份的運算資源，而這些用戶經常會用到一樣的應用程序，當時會以用戶在登陸系統時輸入的數據來決定用戶的賬戶ID。基於這個ID，Mainframe的供應商就能夠利用此ID來計算運算的資源使用量，包括CPU。存儲器與軟盤或磁帶等，這個做法也被SAP公司用在其R/1到R/3的產品線。架構

到了1990年代。應用程序服務提供者服務（application service provider）模式出現，它的做法與運做模式與租用大型主機時一樣，只是租用的資源是在軟件上。除了操做系統之外也包括了其上的應用程序，好比ERP系統或是CRM等應用，系統可能會執行在數臺不一樣的機器上。或是在一樣的主機但共享不一樣的數據庫，以區分並計算客戶的資源使用量，藉以做爲計費的標準，而此技術也有效的縮減供應商的實體機器成本（因爲可以在一臺電腦上同一時候執行多個用戶所租用的應用程序進程)。到了現代，受歡迎的消費者導向Web應用程序（如Hotmail或Gmail等）也是以單一應用程序平臺來支持所有的用戶，這已是多租戶技術的天然演化的結果，多租戶技術也可以讓客戶中的一部份用戶得以進一步定製化他們的應用程序。app

在虛擬化（virtualization）技術的成熟與應用性的擴張之下，多租戶技術可以駕馭虛擬化的平臺。更強化在用戶應用程序與數據之間的隔離，讓多租戶技術能更加發揮它的特點。運維

在功能上，SaaS應用需要完畢應用需求中的功能要求。這與傳統應用之間是沒有不論什麼分別的。除此以外，SaaS應用最重要的一個特性就是支持多租戶。ide

這一點尤爲對面向企業的SaaS應用來講是必須的。模塊化

2.2 Gartner提出的7種多租戶模型

如下，咱們就來看看在SaaS應用搭建過程當中。可以採用什麼樣的多租戶模型。

從而能較爲清晰地瞭解將來使用PaaS平臺開發的SaaS。可以爲用戶提供哪些多租戶的服務。
  Gartner提出了7種多租戶的部署和實現方式模型。該模型可以做爲不論什麼多租戶環境的參考模型。在詳細的實施中以及大型企業中。可以依據自身的需要來決定採用Gartner提出的何種多租戶模型，或者幾種多租戶模型可以並存在一個雲環境中。
  咱們首先來看一下Gartner提出的這7種模型。而後再依據本次項目的實際狀況。提出使用工做流引擎產品搭建何種多租戶模型設計。
  首先。Gartner依照4個層次對多租戶模型進行劃分，即基礎設施層（主要是指各類server）、數據層（即數據庫層）、應用平臺層（即應用執行的容器，一般也稱爲應用server）、以及應用邏輯層（即應用功能）。

例如如下圖所看到的：

第一種模型稱爲「Shared Nothing」，即不共享不論什麼資源。在這樣的模型中。從最底層的基礎設施層。一直到最上端的應用邏輯層，每個租戶均獨享。這樣的模式也是傳統的IT開發和部署模式。

另一種模型稱爲「Shared Hardware」，即共享硬件資源，所有硬件server會造成一個硬件資源池，所有租戶依據需要來共享這些資源。這樣的模式就是現在比較常見的IaaS模式。

第三種模型稱爲「Shared OS」，即共享操做系統。

在這樣的模型中，所有硬件資源均安裝有一樣的操做系統。經過在租戶間切分和分配操做系統的進程來實現對計算資源的共享。與另一種模型同樣，這樣的模型也主要集中在對底層計算資源的共享和分配上，而更高層次的內容均是各個租戶獨享的資源。需要單獨購買和部署。

第四種模型稱爲「Shared Database」。即共享數據庫。

在這樣的模型下，所有租戶會共享一個數據庫，各個租戶本身的應用server以及執行於當中的應用會使用共享數據庫中爲該租戶劃分的數據資源。

第五種模型稱爲「Shared Container」，即共享容器。注意，在這樣的模型下。各個租戶僅僅是共享應用的執行容器，而應用相應的數據庫都是各個租戶獨享的，這一點與第六種模型是根本性的差異。

在這樣的模型中。要求應用執行的容器是支持多租戶訪問的，即容器自己可以智能化的區分來自各個租戶的請求。

第六種模型稱爲「Shared Everything」，即全共享。在這樣的模型中，所有租戶自頂向下共享所有資源。對於提供服務的一方來說，可以最大限度的利用各類資源，並且依託支持多租戶的應用容器，也可以僅僅開發一套程序。部署一次。即可知足所有租戶對公共應用的需要。

第七種模型稱爲「Custom Multitenancy」，即定製化的多租戶。在這樣的模型中，實現多租戶的方法是在應用邏輯中改造已有的API，添加租戶的維度。但是這樣的模式不過對某一個應用起做用，由於沒有使用支持多租戶的應用server。但是又想讓各個租戶共享應用容器，因此不得不在應用邏輯中作文章。

在信息平臺建設中，應當依據詳細客戶的需要，來構建恰當的多租戶模型，爲其提供所需的不一樣服務級別的SaaS應用服務。對於需要更爲經濟型SaaS應用的客戶羣。可以提供第六種多租戶模型的應用，而對於需要更高數據隔離和計算資源需要的客戶羣。則可以提供第五種多租戶模型的應用。

2.3 多租戶應用特色

（1）用戶定製
用戶可依據本身的需要自行定製應用程序；
應贊成多個版本號同一時候執行。

  （2）共享實例
  方便部署與管理；
  易擴展；
  爲數據集成提供便利。

（3）應用隔離、數據隔離

2.4 多租戶使用場景

下圖爲多租戶使用目標場景，應用及其部署隔離、數據庫隔離並採用不一樣的數據庫。

好比，市場經營部門，租用業務流程和專業應用兩個業務應用。

那麼。市場經營人員登陸系統後。就可以見到業務流程和專業應用兩個應用菜單。有對應權限進行業務操做，業務權限由業務應用管理員進行配置。

3 使用多租戶技術實現人員跨部門及虛擬團隊功能

3.1 引言

在信息系統設計中。系統人員存在跨部門狀況，也屬於常見的現象，一般經過組織管理、角色管理來解決，而當系統逐漸龐大起來後。這樣的解決方式將更趨於複雜，靈活性減小的狀況。

如本文開始所描寫敘述的多個獨立系統，也是Gartner第一種模型所稱爲「Shared Nothing」的狀況，這是逐個解決的。

而如今信息化普及狀況下，信息系統愈來愈龐大、複雜，早期的內容需要整合到統一平臺上，採用「發燒級的」雲技術架構，這時，人員跨部門、虛擬團隊的解決方式就比較突出了，怎樣解決更合理呢？

3.2 使用多租戶技術的解決方式

使用多租戶技術的解決方式，嚴格的來講。不不過技術方案。而且還包含管理方案。

這樣。先從技術方案提及。

（1）在目標業務運營平臺上。應存在統一用戶帳戶服務、統一待辦任務服務、租戶服務。

統一用戶帳戶服務。是業務運營平臺上所有應用的僅僅有一套用戶帳號和標準組織機構。

統一待辦服務。是針對流程應用的，所有流程應用的待辦。都由統一待辦服務提供。

租戶服務，是需要平臺提供的租戶租賃開通管理。

（2）例如如下圖所看到的，在租戶內容部署應用，假設某個租戶有個性化需求。則在原應用版本號上個性化新版本號，在新的租戶上使用。

按此原理，業務應用一般包括一個基礎版本號，其它的爲拓展個性化和版本號，而不是一個大而全的版本號。這樣，相關的人員跨部門、虛擬組織的功能，作爲服務，在應用內解決。

假設，從管理方案上說。

（1）跨部門、虛擬組織。每每是暫時性的，或者有期限的，這樣，從管理角度。新建租戶，爲暫時組織提供相關服務；

（2）對於特殊的多重身份、職能的結構和我的，則創建專用租戶，用於解決跨部門、虛擬組織的需求。

3.3 多租戶使用舉例

（1）用戶使用應用的過程

例如如下圖所看到的。用戶經過統一組織文件夾登陸系統，獲取用戶基本信息和權限（應用菜單入口）。經過菜單進入開通的應用，這時，可以獲取此應用下的角色權限（用於處理虛擬組織），按虛擬組織角色起草公文。

（2）用戶處理待辦任務的過程

例如如下圖所看到的，用戶經過統一組織文件夾登陸系統，獲取用戶基本信息和權限（應用菜單入口）。經過統一待辦讀取待辦任務。在待辦任務中包括租用應用信息。由此直接定位到詳細應用功能點，進入開通的應用時，可以獲取此應用下的角色權限（用於處理虛擬組織），按虛擬組織角色審批公文。

綜合上述使用過程分析。虛擬組織、人員跨部門，可以進行統一管理。統一管理的概念僅限技術層面，便於在統一業務運營平臺上應用。

在業務應用是爲虛擬團隊服務的視角下。應該爲虛擬團隊開通租戶，爲虛擬團隊部署相關業務應用。在虛擬團隊可以使用某應用的視角下，在應用裏創建虛擬團隊的角色組。

當中，虛擬團隊的角色組（權限羣集），應進行統一管理，分配給對應的應用裏。

4 關於使用SaaS模式開發的思考

4.1 關於SaaS模式

按百度百科的定義：SaaS是Software-as-a-service（軟件即服務）。SaaS在業內的叫法是軟件運營，或稱軟營。

是一種基於互聯網提供軟件服務的應用模式。

一種隨着互聯網技術的發展和應用軟件的成熟，在21世紀開始興起的全然創新的軟件應用模式。是軟件科技發展的最新趨勢。

SaaS不是雲計算，雲計算也不等於SaaS。SaaS是雲計算上的應用表現。雲計算是SaaS的後端基礎服務保障。

雲計算將弱化SaaS門檻。促進SaaS發展。雲計算應用直接剝離出去，將平臺留下，作平臺的始終作平臺，作雲計算資源的人專心作好資深的調度和服務。

SaaS服務商僅僅需要關注本身的軟件功能表現，無需投入大量資金到後端基礎系統建設。

依據SaaS應用是否具備可配置性，高性能，可伸縮性的特性。SaaS成熟度模型被分紅四級。

每一級都比前一級添加三中特性中的一種。

	可配置	高性能	可伸縮
Level1	N	N	N
Level2	Y	N	N
Level3	Y	Y	N
Level4	Y	Y	Y

（1）定製開發—Level1
這樣的模型下。軟件服務提供商爲每個客戶定製一套軟件。併爲其部署。

每個客戶使用一個獨立的數據庫實例和應用server實例。

數據庫中的數據結構和應用的代碼可能都依據客戶需求作過定製化改動。

（屢次開發）

（2）可配置—Level2
經過不一樣的配置知足不一樣客戶的需求，而不需要爲每個客戶進行特定定製。以減小定製開發的成本。
但是。軟件的部署架構沒有太大的變化。依舊爲每個客戶獨立部署一個執行實例。

僅僅是每個執行實例執行的是同一份代碼，經過配置的不一樣來知足不一樣客戶的個性化需求。
可配置性的比較通用的實現方式。就是經過MetaData（元數據）來實現。（一次開發屢次部署）

（3）多租架構—Level3
多租戶單實例（Multi-Tenant）的應用架構纔是一般真正意義上的SaaS應用架構，它可以有效減小SaaS應用的硬件及執行維護成本。最大化地發揮SaaS應用的規模效應。（一次開發一次部署）

（4）可伸縮架構—Level4
將第三級的Multi-Tenant SingleInstance系統擴展爲Multi-Tenant MultiInstance。終於用戶首先經過接入Tenant Load Balance層，再被分配到不一樣的Instance上。經過多個Instance來分擔大量用戶的訪問，咱們可以讓應用實現近似無限的水平擴展

SaaS2.0模式要求服務運營商能夠提供具有靈活定製、即時部署、高速集成的SaaS應用平臺，能夠提供基於web的應用定製、開發、部署工具，能夠實現無編程的SaaS應用、穩定、部署實現能力。