概念
SOFTWARE AS A SERVICE
在某些方面，SaaS非常類似於早些年的客戶端軟體模式，其中客戶端（在這種情況下通常是Web瀏覽器）提供對伺服器上執行的軟體的訪問點。SaaS是消費者最熟悉的雲服務形式。SaaS將管理軟體及其部署的任務轉移到第三方服務。最熟悉的業務SaaS應用程式是客戶關係管理應用程式，如Salesforce，像Google Apps這樣的生產力軟體，以及Box和Dropbox等儲存解決方案的軟體。
使用SaaS應用程式往往會降低軟體所有權成本，因為不需要技術人員來管理軟體的安裝，管理和升級，同時這也可以降低軟體許可的成本。SaaS應用程式通常在訂閱模式上被提出來。
PLATFORM AS A SERVICE
PaaS提供比SaaS低一級的功能，通常提供可以開發和部署軟體的平臺。 PaaS提供者抽象處理伺服器的大部分工作，併為客戶提供了作業系統和伺服器軟體以及底層伺服器硬體和網路基礎設施的環境，使使用者可以自由地關注業務端可擴充套件性及其產品或服務的應用開發。
與大多數雲服務一樣，PaaS是建立在虛擬化技術之上的。企業可以根據需要申請資源，隨著需求的增長而不是以冗餘資源投入硬體。
PaaS提供商的例子包括Heroku，Google App Engine和Red Hat的OpenShift。
INFRASTRUCTURE AS A SERVICE
繼續朝服務的下層看，我們就可以看到雲服務的基本構件。 IaaS由高度自動化和可擴充套件的計算資源組成，由雲端儲存和可以自動配置，計量和可用的按需網路功能組成。
IaaS提供商通過儀表板以及API（API可能沒有）提供這些雲伺服器及其相關資源。 IaaS客戶可以直接訪問其伺服器和儲存，就像傳統伺服器一樣，但這樣擁有更高階別的可擴充套件性。 IaaS的使用者可以在雲中外包和構建“虛擬資料中心”，並可以訪問許多與傳統資料中心相同的技術和資源功能，而無需投資於伺服器容量規劃或物理管理維護。
IaaS是最靈活的雲端計算模式，允許自動的伺服器，處理能力，儲存和網路的自動部署。 IaaS客戶對基礎設施擁有真正的控制，比PaaS或SaaS服務的使用者不知道高到哪裡去了。 IaaS的主要用途包括PaaS，SaaS和網路規模應用程式的實際開發和部署。
有很多提供商提供Iaas，比如Navisite，Exoscale和Softlayer，具有自己獨特的價格方案和服務組合可供選擇。
ComputeNext（作者的網站）為IaaS提供一個經紀服務，以便你可以確保為您的應用需求選擇合適的IaaS提供商。通過使用單一API對20多個雲提供商進行歸一化的訪問，您可以比較提供商的價格和效能，從而找到最佳配置，然後構建和部署，而不會被綁死到一個平臺。
具體例子可以參考：www.zhihu.com/question/21641778/an...
通俗的講pass和saas的區別
paas給你一個完善的開發，測試，上線的環境，應用工程程式碼還是需要你來開發，在開發過程需要的一些服務已經幫你做好，比如：簡訊服務，郵件服務，分散式檔案系統服務，域名備案服務，網路端負載均衡服務，資料庫端負載主從熱備服務，分片服務，vpn服務，https服務，各個線上伺服器的監控統計服務等；saas是應用工程幫你做好，你只需要調整下頁面配置，即可上線運營，有點類似淘寶平臺與淘寶入駐商家之間的關係。
程式設計
分層設計
saas系統分層大概是：
租戶識別>應用層>資料訪問層>快取層>資料庫
資料隔離
saas系統說起來很簡單，任何系統似乎加個tenant_id(租戶id)就變成saas系統了。比如原來的使用者登入是：
select username,password from users where email='abc@qq.com'
改成
select username,password from users where email='abc@qq.com' and tenant_id =1;
對於複雜業務的saas系統，這樣做法非常危險，而且開發效率很低。你想想如果那個程式設計師寫sql時候忘了加 “ and tenant_id =1” . 結果不堪設想。
比較好做法是在資料庫訪問層對租戶鑑別進行封裝，SQL進行改寫。
function getUserInfo($where,tenant_id){
//sql
}
技術實現
關於多租戶的資料隔離方案
獨立資料庫
這是第一種方案，即一個租戶一個資料庫，這種方案的使用者資料隔離級別最高，安全性最好，但成本較高。
優點：
為不同的租戶提供獨立的資料庫，有助於簡化資料模型的擴充套件設計，滿足不同租戶的獨特需求；如果出現故障，恢復資料比較簡單。
缺點：
增多了資料庫的安裝數量，隨之帶來維護成本和購置成本的增加。
這種方案與傳統的一個客戶、一套資料、一套部署類似，差別只在於軟體統一部署在運營商那裡。如果面對的是銀行、醫院等需要非常高資料隔離級別的租戶，可以選擇這種模式，提高租用的定價。如果定價較低，產品走低價路線，這種方案一般對運營商來說是無法承受的。
共享資料庫，隔離資料架構
這是第二種方案，即多個或所有租戶共享Database，但是每個租戶一個Schema（也可叫做一個user）。
優點：
為安全性要求較高的租戶提供了一定程度的邏輯資料隔離，並不是完全隔離；每個資料庫可支援更多的租戶數量。
缺點：
如果出現故障，資料恢復比較困難，因為恢復資料庫將牽涉到其他租戶的資料；
如果需要跨租戶統計資料，存在一定困難。
共享資料庫，共享資料架構
這是第三種方案，即租戶共享同一個Database、同一個Schema，但在表中增加TenantID多租戶的資料欄位。這是共享程度最高、隔離級別最低的模式。
優點：
三種方案比較，第三種方案的維護和購置成本最低，允許每個資料庫支援的租戶數量最多。
缺點：
隔離級別最低，安全性最低，需要在設計開發時加大對安全的開發量；
資料備份和恢復最困難，需要逐表逐條備份和還原。
如果希望以最少的伺服器為最多的租戶提供服務，並且租戶接受犧牲隔離級別換取降低成本，這種方案最適合。
選擇合理的實現模式
衡量三種模式主要考慮的因素是隔離還是共享。
成本角度因素
隔離性越好，設計和實現的難度和成本越高，初始成本越高。共享性越好，同一運營成本下支援的使用者越多，運營成本越低。
安全因素
要考慮業務和客戶的安全方面的要求。安全性要求越高，越要傾向於隔離。
租戶數量因素
系統要支援多少租戶？上百？上千還是上萬？可能的租戶越多，越傾向於共享。
平均每個租戶要儲存資料需要的空間大小。存貯的資料越多，越傾向於隔離。
每個租戶的同時訪問系統的終端使用者數量。需要支援的越多，越傾向於隔離。
是否想針對每一租戶提供附加的服務，例如資料的備份和恢復等。這方面的需求越多， 越傾向於隔離。
資訊監管因素
要考慮政府，機關，企業，公司的安全和資訊監管相關的一些政策和規定。
基於laravel框架開發SaaS系統
利用laravel內建的前置中介軟體對租戶請求域名進行判斷，進而區分租戶。
每個租戶的金鑰來對應請求域名，後端鑑權通過每個租戶不同的金鑰和請求域名來製造簽名，中心API伺服器以此鑑權。實現ACL，防止資料遭竊。
分庫分表，實現資料隔離，可以使分庫作為本公司master資料庫的一個備庫擴充套件庫，從而實現讀寫分離，資料安全，查詢優化等功能。
為saas使用者提供伺服器前端專案，不提供資料連結，伺服器前端專案為可轉發請求的服務治理中介軟體功能的框架（curl，guzzle），租戶可以買賬號直接使用系統，也可以搭在自己伺服器，自行增減配置運維，寫前端程式碼新增個性化的內容比如商標、首頁、詳情頁等等。後端介面維護在本公司的伺服器，如果系統有bug可以隨時處理而不需要去所有租戶的伺服器重新部署，實現平滑升級。
租戶識別方案
比較好做法是通過url識別租戶。系統是給租戶生成一個隨機的三級域名，比如abc.crm.baidu.com. 如果客戶想使用自己的域名，可以在cname到我們生成的三級域名，並在管理系統裡面做繫結。
租戶管理系統（計費，訂購，定製，充值，催繳）
Saas系統是必須考慮計費系統和租戶控制系統。這個系統需要都是獨立設計。比如那個租戶購買了那些模組，一個月多少錢。租戶可以建立最多的使用者數。計費到期郵件提醒等功能。
計費方式一般有兩種，週期性計費，類似月租方案，和使用量計費,用多少付多少。 週期性計費比較簡單。也可以兩者結合起來。
定製化開發
SAAS的優勢在於一套系統多人使用，似乎和定製化開發有衝突。比如A客戶想要A功能，B客戶不想要。但定製化開發是無法避免的，比如CRM系統這樣複雜的系統，不可能一套系統滿足所有公司的要求。定製化開發儘可能分系統，分模組去做。然後通過控制檯中配置不同租戶訂購不同模組，那些模組可以在前端頁面上顯示。不同的子系統需要分開部署。前端可通過nginx根據url分發，比如abc.crm.baidu.com/bi/xxx/xx這個地址，就分發到BI子系統。
還有開發和產品，現有需求一定要分析清楚，不要一上線發現後患無窮。新功能儘量做的獨立可以配置。
灰度升級
SAAS付費企業客戶對系統問題都特別敏感。 為了減少升級可能出現問題的影響範圍，一般都採用灰度升級策略。如果使用了url來區分不同租戶，灰度升級配置就會很方便。可以配置nginx 來根據域名做分發，比如租戶A（aaa.com）到例項1（版本1.0），租戶B(bbb.com)到例項2(版本). 當需要域名配置非常多的時候，nginx配置文件會亂。這塊時候可以考慮使用nignx_lua來寫一些擴充套件模組。
轉自電子書
www.kancloud.cn/martist/be_new_fri...
本作品採用《CC 協議》，轉載必須註明作者和本文連結