SaaS 是什么

定義

相信大家都對云服務中的? IaaS、PaaS、SaaS 早就有所耳聞，現在更是衍生出了 aPaaS、iPaaS、DaaS 等等的類似概念。對于 SaaS 也有各種各樣的定義，本文給出的定義是：

SaaS 是一種基于互聯網提供服務和軟件的交付模式，所有網絡基礎設施及軟件、硬件運作平臺的所有前期實施、后期維護都由 SaaS 平臺完成，用戶只需要租賃軟件服務并通過互聯網接入使用。SaaS 模型依賴敏捷性和運營效率，作為推動增長、覆蓋和創新的業務戰略的支柱。業內大家通常會以 Salesforce 作為 SaaS 的標桿。

價值

目前市場上越來越多的企業和組織采用 SaaS 服務來替代原來傳統的軟件采購部署方式，其原因可以主要總結為以下幾個方面。

?

另外，相比于傳統軟件，SaaS 的盈利模式也決定了客戶的成功對于 SaaS 廠商來說極其重要，只有客戶成功了，才會有續費， SaaS 項目才有辦法繼續下去。當然 SaaS 系統相比傳統軟件也會有一些缺點，如獨立性、可控性、個性化等。

基礎架構

SaaS 系統通常是一個普通的分布式系統，因此它一定具有分布式系統的所有組成要素，如服務發現、負載均衡、序列化協議、傳輸協議、授權認證、網絡安全等等。

入口

客戶最直接接觸的通常是 SaaS 系統的客戶端，客戶端的形式可以根據業務的需求決定，常見的有瀏覽器網頁、移動端 APP、小程序、智能設備等。

客戶端到服務器的入口通常是一個通用域名或者是每個租戶的獨立子域名。如互客的入口是 huke.163.com，網易七魚的入口是 xxx.qiyukf.com。域名的背后就一定需要 DNS 的存在，需要配置出合理的 DNS 解析，通常傳統的基于 UDP 的 DNS 服務容易受到中間人攻擊，存在被劫持的風險，另外也存在被運營商封禁等情況，因此 SaaS 系統通常通過搭建自己的 HTTPDNS 來規避風險。

有了域名作為入口之后，下一步就是客戶端和服務器之間的通信協議，對于少數簡單的 SaaS 系統來說只要通過域名和 HTTP 協議就可以完成所有服務，但大部分 SaaS 系統都會存在雙向通信的需求，因此還需要維護長連接通道，常用的如原生 TCP 協議，或 Websocket 協議。另外如果業務中有媒體流傳輸的需求，還會用到 UDP、RTP 協議等。當然，目前市場上對于各種場景和需求都有對應的成熟解決方案，因此 SaaS 系統通常不會去從 0 開始解決所有問題，如長鏈接和媒體流我們可以集成網易云信的服務來解決。

接入層

接入層通常是各種路由協議以及多層代理組成，如運營商和 AS 之間通常用 BGP 協議或者三線，機房內部通常會有接入的三層交換機，四層代理等等。網易七魚目前的接入方案如下圖所示，而對于規模較小的業務，為了靈活性和性價比，通常會在交換機和 Nginx 之間加入四層代理 nlb。這一層基本都是由集團的 SA 同學負責搭建和運維。

?

業務層

這里我們不去討論業務上的各種設計模式和分層，因此把接入層之后、數據層之前的所有服務和設施統稱為業務層。通常業務層是一個 SaaS 系統研發中投入資源最大的，線上問題如性能瓶頸、穩定性、安全漏洞等大部分都來自于業務層，因此該層也是開發和線上運維的重點。

在業務層目前 SaaS 系統最常用的還是微服務的架構，不同于 IaaS 或 PaaS，SaaS 業務的一個重要特征是其業務復雜度很高、業務鏈路很長，而微服務的架構剛好可以很好地應對這種情況。當然在業務剛開始的時候，我們可以用簡單的單體應用來快速實現原型驗證，等業務發展起來后再開始逐步微服務拆分。

流量通過接入層后，一般為了系統的靈活性，會通過 Nginx 的 upstream 來轉發請求到網關，由網關統一分發到對應的業務服務，而業務服務又可以拆分為許多獨立的微服務相互調用。這也就帶來了 SaaS 系統中的大部分常見問題，如：

• 誰可以使用什么服務？（租戶管理）

• 服務在哪里？（服務發現）

• 請求應該由哪個服務節點處理？（負載均衡）

• 信息怎么傳輸？（傳輸協議）

• 如何避免一個租戶影響另一個租戶？（資源隔離）

• 輸入和輸出如何表示？（序列化協議）

• 網絡出現分區、超時或者服務出錯了怎么辦？（熔斷、降級、服務治理）

• 服務權限如何管理？（認證授權）

• 如何保證通信安全？（網絡安全）

• 重要程度和依賴關系怎么樣？（服務分級）

• 如何保證不同機器的服務狀態一致？（分布式數據一致性）

等等...這些全都需要研發人員投入大量的精力，每個點展開細說都是一個很大的話題。基于業務和技術的考慮，通常還需要引入消息隊列、緩存、配置中心、定時任務等組件。

數據層

所有業務邏輯，最后一定都會在數據存儲上得到體現。在一個 SaaS 系統中，最常用的存儲依然是關系型數據庫，如我們的 DDB、另外常用 HBase、TiDB 等作為冷數據存儲，ES、MongoDB 等作為對應功能的數據存儲。因此 SaaS 系統中多個數據存儲之間的一致性是一個需要重視的地方。

對象存儲方面，我們集團內有 Nos，市面上的云廠商也都有相應的服務，不需要自己構建。不論客戶存儲的對象還是系統中的某些資源，為了提高客戶的訪問速度，我們都需要有 CDN 的存在。

SaaS 業務中還有一個常見的需求就是 BI，這要求系統具有數據分析能力，OLAP 數據庫也是必不可少的，網易云商采用的是 ClickHouse。

在某些特定的業務場景，也許還需要用到 TSDB，錄入智能設備的傳感器讀數，用戶的活動軌跡，系統的狀態變化等。

數據層還有一個非常重要，但經常被忽視的話題就是數據合規。特別是對于 SaaS 業務，因為面向的客戶都是企業和組織，因此數據的安全合規是非常重要的。例如網易云商有專門的中間件用于數據庫的敏感數據加密。

?

運維能力

到目前為止，一個 SaaS 系統基本已經搭建成型可以提供服務了。但是我們對系統的狀態還一無所知，因此還要構建足夠強大的運維能力。其中包括了可觀測性、計量計費、快速恢復、故障演練、系統治理各個方面。以可觀測性為例，我們需要采集系統中的各種數據并通過大量技術手段來觀測系統的狀態，如系統資源、業務指標、健康狀態、鏈路追蹤、業務埋點、報警管理、錯誤統計、流量水位、趨勢分析、變更管理等。針對 SaaS 業務的特點，還需要特別對系統進行租戶維度的監控和管理。

?

部署模式

SaaS 系統根據隔離程度的不一樣可以分為三種部署模式，每種部署模式都會涉及到架構的調整適配，都有各自的優缺點。

共享模式

指 SaaS 系統中的所有資源，如業務服務、數據存儲等全部是共享的，這要是絕大分部 SaaS 系統一開始采用的模式，這種模式系統的優勢是靈活性高，資源利用率高，采用集中化管理，開發運維更簡單。缺點是租戶間容易相互影響，合規性也容易被一些特定行業客戶挑戰，還有很難為不同租戶提供差異化服務。

專屬模式

指 SaaS 系統中幾乎所有資源都是租戶獨占的，這種部署模式的優勢是每個租戶有完全隔離的環境，租戶之間不會有影響，可以針對不同租戶提供個性化的服務。但是缺點也很明顯，這種部署模式的資源利用率低、成本高、運維難度高、管理復雜。通常會被用于一些特定行業或者特殊需求的客戶場景。

?

混合模式

指 SaaS 系統中有部分資源是所有租戶共享的，還有部分資源是租戶獨占的，這種模式是現在大型 SaaS 系統常見的部署模式，可以兼顧上面種模式的優缺點，針對不同的客戶提供不同的解決方案。

?

未來發展

上面簡要介紹了搭建一個 SaaS 系統的主要過程，盡管 SaaS 的設計初衷是快速為特定業務場景提供垂直解決方案，但企業對跨業務跨部門的需求也越來越強烈，例如營銷服務一體化、私域運營等場景。因此，業界無論在業務還是技術方面都還在不斷地探索之中，例如對于 SaaS 的成本控制，合規性，可擴展性，針對不同租戶的差異化服務等等，都是 SaaS 廠商經常面臨的難題。有人在探索部署方式的優化，有人在探索產品的設計方案，有人在探索低代碼的模式，還有人在探索生態合作的方案。無論如何，大家的的努力都是在為了客戶的成功，回到我們的起點，只有客戶成功了，SaaS 才有存在下去的價值。

?