一、什么是Saas？

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

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

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

• 缺點(diǎn)

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

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

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

2.1 定制化開(kāi)發(fā)

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

2.2 可配置化

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

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

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

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

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

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

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

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

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

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

• 缺點(diǎn)：

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

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

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

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

• 缺點(diǎn)：

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

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

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

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

• 缺點(diǎn)：

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

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

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

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

• 缺點(diǎn)：

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

3.5 通用saas邏輯圖

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

四、技術(shù)選型

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

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

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

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

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

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

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

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

• 4.1.3讀寫分離

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

• 4.1.4 分庫(kù)分表中間件

??目前對(duì)于分庫(kù)分表中間件，開(kāi)源組件越來(lái)越多，常用的分庫(kù)分表中間件具體如下：

• 簡(jiǎn)單易用的組件：

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

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

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

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

  • 分布式：Dubbo（阿里）、OSP（唯品會(huì)）、Motan（微博）、Tars（騰訊），spring cloud
  • cache: redis\mc
  • 定時(shí)任務(wù)統(tǒng)計(jì)：elastic-job\XXL-JOB\SATURN(唯品會(huì)),具體介紹：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三個(gè)開(kāi)源軟件的組合。在實(shí)時(shí)數(shù)據(jù)檢索和分析場(chǎng)合，三者通常是配合共用，而且又都先后歸于 Elastic.co 公司名下，故有此簡(jiǎn)稱，參考文檔如下：
    官網(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发展史常用架构的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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