一、什么是Saas？

??從字面中理解SaaS的全稱是Software as a service, 即軟件即服務，即由傳統(tǒng)的開發(fā)賣軟件升級到開發(fā)軟件賣服務。百度百科對SAAS的定義是：SAAS平臺是運營saas軟件的平臺,SaaS提供商為企業(yè)搭建信息化所需要的所有網(wǎng)絡基礎設施及軟件、硬件運作平臺，并負責所有前期的實施、后期的維護等一系列服務，企業(yè)無需購買軟硬件、建設機房等，租戶開箱即用。SaaS 是一種軟件布局模型，其應用專為交付而設計，便于用戶通過互聯(lián)網(wǎng)托管、部署及接入。
??ToB Saas系統(tǒng)最近幾年都很火,很多創(chuàng)業(yè)公司都在嘗試創(chuàng)建企業(yè)級別的應用 CRM, HR,銷售, 很多Saas創(chuàng)業(yè)公司也拿了大額風投，也有不少上市公司，比如有贊、微盟等。那么SAAS軟件的優(yōu)缺點如下:

• 優(yōu)點

1、用戶角度：開箱即用 、無需維護、按需使用、隨處可用、使用成本降低；
2、ASP提供商：節(jié)省銷售成本、節(jié)省軟件維護成本；

• 缺點

1、高度依賴網(wǎng)絡、數(shù)據(jù)安全性和保密性要求高；
2、定制化服務開發(fā)部署周期長；

二、saas演進過程

??SaaS成熟度模型根據(jù)是否具有可配置性、高性能、可伸縮可將SaaS成熟度分為四級，每一級都比前一級增加三種特性中的一種，分別是定制開發(fā)、可配置(代替定制) 、高性能的多租戶架構(gòu)以及可伸縮性多租戶架構(gòu)。

2.1 定制化開發(fā)

??為用戶提供專用的數(shù)據(jù)庫實例及應用服務器實例，依據(jù)用戶實際需求進行定制化開發(fā)，其實最初的SaaS應用成熟度模型，在技術(shù)架構(gòu)上和傳統(tǒng)項目型軟件開發(fā)或軟件外包沒什么區(qū)別。有一個客戶項目，就按照客戶的需求來定制一個版本，每個客戶都有一份獨立的代碼，各版本間可通用的只有少量可重用軟件，庫及開發(fā)人員經(jīng)驗。雖然最初級的SaaS模型，在應用架構(gòu)上和傳統(tǒng)軟件模式并沒有什么區(qū)別，但在商業(yè)模式上，最初級的SaaS模型和傳統(tǒng)軟件模式，還是存在本質(zhì)上的區(qū)別——即軟硬件及相應的維護職責都由SaaS服務商提供，用戶按需繳納費用即可使用。

2.2 可配置化

??為用戶部署單獨的運行實例，但有效的減低了第二次開發(fā)的成本，通過可配置的形式，滿足用戶的基本需求。
??最初級的成熟度模型，顯然并不是良好的SaaS成熟度模型，每次新增用戶都需要進行定制化的開發(fā)，單獨部署。這種模式勢必會導致隨著客戶數(shù)的增加，需要投入的定制化開發(fā)成本，軟硬件已經(jīng)運營成本，都將隨著客戶的增加而按照比較增加。但這種模式達到一定規(guī)模后，想要進一步擴大規(guī)模，基本上就只能依賴于人肉戰(zhàn)術(shù)了。
??所以，首先需要解決的問題就是降低定制化開發(fā)成本。SaaS第二級依賴的解決方案，就是通過可配置化實現(xiàn)有效降低開發(fā)，進而達到縮減成本的目的。希望通過可配置化來滿足不同客戶的需求，而不需要為客戶進行特定的開發(fā)。但是，其實通過描述可發(fā)現(xiàn)，在第二級模型中，軟件的部署架構(gòu)并沒有發(fā)生多大的變化，依舊是為每個客戶部署一個運行實例，只是每個運行實例都是運行著同一份代碼，通過配置的不同來滿足不同客戶的需求。

2.3 高性能的多租戶架構(gòu)

??從應用架構(gòu)的角度而言，第一級和第二級成熟度模型和傳統(tǒng)軟件并沒有太大的區(qū)別，只是在商業(yè)模式上比較符合SaaS的定義。由于其應用架構(gòu)的設計是為每一個新的租戶都單獨部署一份軟件實例，在一對一的架構(gòu)，勢必會導致需要維護軟硬件成本，隨著新租戶的增加而直線上升，無法有效的發(fā)揮SaaS模式的規(guī)模效應。所以，多租戶單實例的SaaS架構(gòu)才是通常上真正意義的SaaS模式，多個租戶對應一個軟件實例可有效的降低軟硬件成本，充分發(fā)揮SaaS模式的規(guī)模效應。
??實現(xiàn)多租戶模型的關(guān)鍵是通一定的策略來確保用戶數(shù)據(jù)的獨立性，用戶共享統(tǒng)一的應用實例，勢必會對數(shù)據(jù)獨立性提出一定的要求，在用戶需求差別不大，客戶數(shù)量不多時，講一個第一級/第二級成熟度模型改造成多租戶并不會太復雜，通常可以通過獨立數(shù)據(jù)庫，共享數(shù)據(jù)庫獨立數(shù)據(jù)結(jié)構(gòu)，共享數(shù)據(jù)結(jié)果實現(xiàn)。

2.4 可伸縮性多租戶架構(gòu)

??該級別的初始目的為了實現(xiàn)在用戶數(shù)大量增加的情況下，無須更改應用架構(gòu)，只需要簡答的增加硬件部署的數(shù)量，就可支撐應用規(guī)模的增長。在架構(gòu)設計中的Tenant Load Balaner層將會保存用戶，租戶與對應軟件實例的映射，用戶登錄后，即刻映射到對應的軟件實例。

三、SAAS架構(gòu)常用方案

??SaaS成熟度模型分級不同，系統(tǒng)架構(gòu)設計也不盡相同，下面簡單說一下系統(tǒng)架構(gòu)在不同分級模型下設計：

3.1 獨立服務和數(shù)據(jù)庫

• 優(yōu)點：

為不同的租戶提供獨立的應用實例和數(shù)據(jù)庫，有助于簡化數(shù)據(jù)模型和業(yè)務模型的擴展設計，滿足不同租戶的獨特需求；如果出現(xiàn)故障，恢復系統(tǒng)或數(shù)據(jù)均比較簡單，系統(tǒng)間也不會相互影響。

• 缺點：

1、數(shù)據(jù)庫層面：每個租戶數(shù)據(jù)庫都作為獨立數(shù)據(jù)庫進行部署，該模型提供了最大的數(shù)據(jù)庫隔離。但隔離需要為每個數(shù)據(jù)庫分配足夠的資源來處理其高峰負載。這里重要的是， 彈性池不能用于部署在不同資源組或不同訂閱中的數(shù)據(jù)庫。這種限制使得這種獨立的單租戶應用程序模型成為從整體數(shù)據(jù)庫成本角度來看最昂貴的解決方案；
2、應用層面：每個租戶若存在個性化定制，則需要對項目進行橫向擴展，擴展時務必需要保證與主干版本的兼容性問題。
3、運維層面：應用和數(shù)據(jù)庫的安裝數(shù)量會隨租戶的數(shù)量線性遞增，隨之帶來維護成本和購置成本的增加。

3.2 共享服務獨立數(shù)據(jù)庫

• 優(yōu)點：

為不同的租戶提供獨立數(shù)據(jù)庫，有助于簡化數(shù)據(jù)模型擴展設計，滿足不同租戶的獨特需求；如果出現(xiàn)故障，數(shù)據(jù)恢復均比較簡單，也可以自動將單個租戶恢復到較早的時間點。因為恢復只需要恢復存儲租戶的一個單租戶數(shù)據(jù)庫。這種恢復對其他租戶沒有影響，這證實了管理運營處于每個租戶的細粒度級別。應用層面的維護成本和購置成本有所減少。

• 缺點：

1、數(shù)據(jù)庫層面，數(shù)據(jù)模型統(tǒng)一
2、應用層面，每個租戶若存在個性化定制，則需要對項目進行橫向擴展，擴展時務必需要保證與主干版本的兼容性問題
3、運維層面，數(shù)據(jù)庫的運維問題同模式一，應用層面的運維在版本控制的問題上難度有所增加

3.3 共享應用及數(shù)據(jù)庫

• 優(yōu)點：

為安全性要求較高的租戶提供了一定程度的邏輯數(shù)據(jù)隔離，并不是完全隔離；每個數(shù)據(jù)庫可支持更多的租戶數(shù)量。

• 缺點：

1、數(shù)據(jù)庫層面，如果出現(xiàn)故障，數(shù)據(jù)恢復比較困難，因為恢復數(shù)據(jù)庫將牽涉到其他租戶的數(shù)據(jù)；
2、應用層面，配置中心需要對租戶信息進行完整且合理的分配和維護。

3.4 網(wǎng)關(guān)+前臺+中臺模式

• 優(yōu)點：

  • 有利于定制不同租戶的個性化需求。例如：交互界面不同、工作流不同等等。
  • 服務只需要根據(jù)用戶需求在前臺做相應的橫向擴展即可；
  • 不同租戶間服務相互獨立，互不影響。

• 缺點：

  • 模塊劃分需要做好劃分，重點注重業(yè)務之間的低耦合；
  • 調(diào)用鏈路變長，需要做一定的優(yōu)化處理；
  • 模塊縱向拆分后，后期研發(fā)和運維難度均會有所增加；
    原文鏈接：https://blog.csdn.net/haponchang/article/details/104246317

3.5 通用saas邏輯圖

• 優(yōu)點：
  • 服務只需要根據(jù)用戶需求在前臺做相應的橫向擴展即可；
  • 不同租戶間共享服務。
• 缺點：
  • 模塊劃分需要做好劃分，重點注重業(yè)務之間的低耦合；
  • 調(diào)用鏈路變長，需要做一定的優(yōu)化處理；
  • 模塊縱向拆分后，后期研發(fā)和運維難度均會有所增加；

四、技術(shù)選型

??多租戶模式下，軟件的架構(gòu)需要考慮可擴展性（Scalability）、數(shù)據(jù)隔離、性能、數(shù)據(jù)庫成本、性能監(jiān)控等多指標。

• 4.1 數(shù)據(jù)庫層：

• 4.1.1 數(shù)據(jù)庫的垂直切

1）. 縱向分庫就是根據(jù)業(yè)務耦合性，將關(guān)聯(lián)度低的不同表存儲在不同的數(shù)據(jù)庫，做法與大系統(tǒng)拆分為多個小系統(tǒng)類似，按業(yè)務分類進行獨立劃分。與“微服務治理”的做法相似，每個微服務使用單獨的一個數(shù)據(jù)庫。
2）. 垂直分表是基于數(shù)據(jù)庫中的列進行，某個表字段較多，可以新建一張擴展表，將不經(jīng)常用或者字段長度較大的字段拆出到擴展表中。在字段很多的情況下，通過大表拆小表，更便于開發(fā)與維護，也能避免跨頁問題，MYSQL底層是通過數(shù)據(jù)頁存儲的，一條記錄占用空間過大會導致跨頁，造成額外的開銷。另外，數(shù)據(jù)庫以行為單位將數(shù)據(jù)加載到內(nèi)存中，這樣表中字段長度越短且訪問頻次較高，內(nèi)存能加載更多的數(shù)據(jù)，命中率更高，減少磁盤IO，從而提升數(shù)據(jù)庫的性能。

• 垂直切分的優(yōu)點：
  • 解決業(yè)務系統(tǒng)層面的耦合，業(yè)務清晰
  • 與微服務的治理類似，也能對不同業(yè)務的數(shù)據(jù)進行分級管理，維護，監(jiān)控，擴展等。
  • 高并發(fā)場景下，垂直切分一定程度的提升IO，數(shù)據(jù)庫連接數(shù)，單機硬件資源的瓶頸。
• 垂直切分的缺點
  • 部分表無法join，只能通過接口聚合方式解決，提升了開發(fā)的復雜度。
  • 分布式事處理復雜
  • 依然存在單表數(shù)據(jù)量過大的問題。

• 4.1.2 數(shù)據(jù)庫水平切分

??當一個應用難以再細粒度的垂直切分或切分后數(shù)據(jù)量行數(shù)依然巨大，存在單庫讀寫，存儲性能瓶頸，這時候需要進行水平切分。
??水平切分為庫內(nèi)分表和分庫分表，是根據(jù)表內(nèi)數(shù)據(jù)內(nèi)在的邏輯關(guān)系，將同一個表按不同的條件分散到多個數(shù)據(jù)庫或多表中，每個表中只包含一部分數(shù)據(jù)，從而使得單個表的數(shù)據(jù)量變小，達到分布式的效果。
??庫內(nèi)分表只解決單一表數(shù)據(jù)量過大的問題，但沒有將表分布到不同機器的庫上，因些對于減輕mysql的壓力來說幫助不是很大，大家還是競爭同一個物理機的CPU、內(nèi)存、網(wǎng)絡IO，最好通過分庫分表來解決。

• 水平切分優(yōu)點
  • 不存在單庫數(shù)據(jù)量過大、高并發(fā)的性能瓶頸，提升系統(tǒng)穩(wěn)定性和負載能力。
  • 應用端改造較小，不需要拆分業(yè)務模塊。
• 水平切分缺點
  • 跨分片的事務一致性難以保證
  • 跨庫的join關(guān)聯(lián)查詢性能較差
  • 數(shù)據(jù)多次擴展維度和維護量極大。

• 4.1.3讀寫分離

??為了確保數(shù)據(jù)庫產(chǎn)品的穩(wěn)定性，很多數(shù)據(jù)庫擁有雙機熱備功能，也就是主從，主服務主要負責寫，從服務器提供讀功能，在查詢壓力較大的情況，讀寫分離是較好的方案。

• 4.1.4 分庫分表中間件

??目前對于分庫分表中間件，開源組件越來越多，常用的分庫分表中間件具體如下：

• 簡單易用的組件：

  • Asgard（唯品會）
  • DAYU （唯品會）
  • ShardSphere(當當)
  • TSharding（蘑菇街）

• 強悍重量級的中間件：

  • sharding
  • TDDL Smart Client的方式（淘寶）
  • Atlas(Qihoo 360)
  • alibaba.cobar(是阿里巴巴（B2B）部門開發(fā))
  • MyCAT（基于阿里開源的Cobar產(chǎn)品而研發(fā)）
  • Oceanus(58同城數(shù)據(jù)庫中間件)

• 4.2 應用層優(yōu)化：

  • 分布式：Dubbo（阿里）、OSP（唯品會）、Motan（微博）、Tars（騰訊），spring cloud
  • cache: redis\mc
  • 定時任務統(tǒng)計：elastic-job\XXL-JOB\SATURN(唯品會),具體介紹：https://www.jianshu.com/p/ab438d944669
  • 搜索引擎:技術(shù)組件ES
  • 異步化：ROCKET、KAFKA、RabbitMQ、plusar

• 4.3 運維與監(jiān)控

  • 日志分析系統(tǒng)：elk
    ELK Stack 是Elasticsearch、Logstash、Kiban三個開源軟件的組合。在實時數(shù)據(jù)檢索和分析場合，三者通常是配合共用，而且又都先后歸于 Elastic.co 公司名下，故有此簡稱，參考文檔如下：
    官網(wǎng)地址:https://www.elastic.co/cn/
    官網(wǎng)權(quán)威指南:
    https://www.elastic.co/guide/cn/elasticsearch/guide/current/index.html
    安裝指南：
    https://www.elastic.co/guide/en/elasticsearch/reference/6.x/rpm.html

總結(jié)

以上是生活随笔為你收集整理的Saas发展史常用架构的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。