一、什么是Saas？

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

• 優(yōu)點(diǎn)

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

• 缺點(diǎn)

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

二、saas演進(jìn)過程

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

2.1 定制化開發(fā)

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

2.2 可配置化

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

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

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

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

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

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

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

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

• 優(yōu)點(diǎn)：

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

• 缺點(diǎn)：

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

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

• 優(yōu)點(diǎn)：

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

• 缺點(diǎn)：

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

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

• 優(yōu)點(diǎn)：

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

• 缺點(diǎn)：

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

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

• 優(yōu)點(diǎn)：

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

• 缺點(diǎn)：

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

3.5 通用saas邏輯圖

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

四、技術(shù)選型

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

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

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

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

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

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

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

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

• 4.1.3讀寫分離

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

• 4.1.4 分庫分表中間件

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

• 簡單易用的組件：

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

• 強(qiáng)悍重量級的中間件：

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

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

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

• 4.3 運(yùn)維與監(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)容還不錯，歡迎將生活随笔推薦給好友。