關於SaaS和Serverless，相信關注我的很多讀者都已經不陌生，所以這篇不會聊它們的技術細節，而將重點放在SaaS軟體架構中引入Serverless之後，能給我們的SaaS軟體帶來多大的收益。
在開始下面的內容之前，不妨先給自己半分鐘時間，思考下：你認為Serverless的引入，對你現有的SaaS軟體架構帶來多大的提升？
先說一個大部分人都可以想到的：從Serverless簡化運維的角度去思考，站在軟體平臺的運維方，能夠降低運維複雜度。這個收益顯而易見，我開始也只想到了這一點，直到這幾天看了AWS re:Invent中幾個關於SaaS架構與Serverless的演講，才有了一些更高維度的思考。
下面我們就來一起看看在SaaS遇到Serverless，可以迸出怎麼樣的火花。
背景
SaaS軟體和Serverless服務，在國內的發展，一直有種難兄難弟的感覺。雖然做的事情不一樣，但它們當前的使用者現狀和困境非常相似。
現狀：相似的使用者群體
目前國內做SaaS的已經非常多了，我自己即是SaaS軟體的使用者，也是SaaS軟體的開發者，日常也訂閱了一些好用的SaaS（比如：線上作圖工具ProcessOn、線上表單金資料等）。大部分SaaS軟體都是以實現低門檻的通用功能為主，擁有高複雜度功能支援的非常少見。因為這一功能特性的制約，它們的主要客戶目前以小客戶為主，集中在初創團隊、小公司、甚至個人。
Serverless在國內的現狀也很相似，之前因為為某廠的Serverless服務做推廣，目前比較容易被接受的還都是初創團隊和小公司。因為Serverless簡化運維這個直接收益的認識上，比較容易被大家理解、認可並接受（包括我自己）。所以針對運維能力薄弱的團隊或企業，會是一個比較好的突破口，自然而然的，使用者群體也落到了缺少技術能力或人力成本匱乏的小團隊上。
困境：相似的焦慮
由於SaaS和Serverless有著類似的使用者群體，所以他們的焦慮也非常相似。這一使用者群體的特點就是目前廠商焦慮的核心：付費能力不高，續費意願一般。現階段解決這一焦慮的主要手段就是不斷的營銷作增長，所以我們總會看到很多拉新活動或續費優惠活動。但營銷活動做的再多，也無法改變這一焦慮存在的本質，尤其是在出現更多同類產品的競爭對手之後，這樣的壓力會越來越明顯。
所以，為求突破，大家都開始把眼光放到大客戶這塊藍海上，中大型企業對於軟體與基礎設施的消費能力強和續費可能也要遠遠高於初創團隊和小企業，如果能有幾個大客戶常駐平臺，那麼對於SaaS和Serverless服務商的長期發展都是非常有益的。目標很美好，但是要支援大客戶的入駐並不是一件容易的事，所以也就有了一直被熱議的一個問題：大客戶的這塊蛋糕，到底要不要去吃？又該怎麼吃？
困難的本質
SaaS的難
SaaS軟體為什麼推向大企業的時候會很難？這裡面有很多原因，對於SaaS軟體的開發商來說，大客戶的需求更復雜，實現起來比較困難，成本會急劇升高，架構複雜度也會面臨巨大的挑戰。同時，大客戶對於業務執行到SaaS平臺，還有一個最大的擔憂，就是SaaS的不穩定性。
如果你是SaaS平臺的重度使用者，一定碰到過這些問題：其他租戶的故障影響到了你的功能、平臺版本的升級直接把你的服務整掛了。為什麼會產生這樣的問題呢？其實本質還是當前國內SaaS軟體的目標和架構設計原因，由於初期目標就是服務小客戶，為了節省成本，利用好規模效應，獲得更高的利潤，大量的功能支援都在共享資源池中，所有租戶的使用都有可能會造成互相的影響。而該問題的本質其實就是租戶的隔離級別不滿足大客戶的要求，所以如果要拓寬這類客戶，就必須從架構上提升租戶隔離的級別。
Serverless的難
Serverless在推向大客戶的時候，與SaaS軟體面對的困難並不一樣。由於Serverless直接提升的是運維效率，而大企業往往已經有成熟的運維體系和團隊支撐，引入Serverless是否真的可以帶來提升，這其實並不好說，因為從更全面的實施角度去考慮，其中還包含大量諸如培訓等容易被忽略的成本和風險。如果基於現有成熟體系去替換一般來說是比較難推動的。這就像已經有完善成熟的信用體系之下，移動支付很難流行起來，是一個道理。所以，Serverless要被大客戶接受，需要找到一個更痛的切入點去打動客戶。
SaaS + Serverless的新思路
在聊了SaaS和Serverless各自的現狀和麵向大客戶應用的難點之後，回頭看SaaS和Serverless的結合，會擦出怎麼樣的火花呢？
首先來看看在SaaS中引入Serverless，除了基本平臺運維的效率提升之外，我們試著把注意力轉移到大客戶的租戶隔離上來。是不是有點感覺了？
在沒有Serverless的支援之前，我們要如何為客戶提供更高階別的隔離？是不是需要我們去編寫很多指令碼去完成各種資源的建立、應用的部署、資料的初始化等等操作？而且這樣的操作複雜度與系統依賴其他資源的複雜度成正比，那麼對於一個租戶的獨有資源管理（資源建立、彈性伸縮、以及不續費之後的銷燬）存在著很大的挑戰。
但如果我們使用Serverless來完成租戶需要的資源隔離，運維層面就可以帶來很大的改善，整體運維複雜度也不會提升太多。在這樣的思路之下，我們還可以做更靈活的多層租戶服務，以滿足各種不同級別使用者的要求，比如：對普通租戶採用共享資源提供服務，白銀租戶採用部分共享資源 + 部分Serverless的獨立資源提供服務，黃金租戶採用完全Serverless部署的獨立資源服務等。
下圖就是採用了Serverless來部署不同級別租戶的架構圖，其中Tenant 1和Tenant 2通過獨立的Serverless部署，擁有更好的隔離型，這類租戶往往是更高階別的付費使用者。而一些基礎付費使用者則還是通過池化資源對外提供服務。
由於Serverless擁有彈性伸縮特性，這使得所有資源的開銷變得更加經濟。如下圖，當我們使用Serverless來構建SaaS服務的時候，整體的資源消耗可以隨著租戶的使用情況呈現一個最佳狀態。
對於SaaS軟體供應商來說，通過Serverless來構建SaaS服務不僅可以在多租戶隔離上的要求上做的更好，在資源成本控制上也會更為出色。另外一方面，從Serverless供應商而言，走進大客戶的難點，或許可以通過為SaaS軟體提供多租戶解決方案，從而找到一條更容易的快速通道。原本SaaS和Serverless面向大客戶都存在一定的難度，而這樣的結合，是不是有種難兄難弟雙雙把大客戶帶回家的感覺？
如何通過Serverless構建SaaS軟體
既然通過Serverless來構建SaaS軟體這麼爽，那麼我們又該如何做呢？這次大會的主題演講中也給出了幾個非常具有指導意義的參考解決方案。其中《深入探尋無伺服器SaaS參考解決方案的內部原理》主題中有一個使用Amazon Lamdba來構建的例子，下面給拆解一下大家最關心的租戶建立與隔離資源的建立流程是怎麼樣的。
先來看看這個參考解決方案的架構圖：
圖中Control Plane是整個SaaS系統的控制中間，這裡負責管理租戶、租戶下的使用者以及各個租戶的資源配置等。Application Plane部分則是具體執行SaaS業務的核心叢集，在Application Services部分，可以看到有兩個微服務叢集，這裡就體現了隔離的思想，你可以把其中一個作為普通租戶的資源池，而其他的可作為高階租戶的獨立資源池。
既然我們要實現租戶的資源隔離，這一整套隔離資源是如何一步步建立出來的呢？
上圖展示了一個新租戶註冊的時候，在Control Plane中完成的一系列細節操作：
- 租戶配置（確定是pool使用者還是silo使用者）
- 根據租戶型別，建立不同的使用者管理服務，並建立租戶管理員使用者
- 構建租戶管理服務，儲存該租戶的配置
- 如果是silo使用者，則為該租戶構建獨有的服務資源（下圖展示了這一步的具體流程）
不同租戶的服務版本和構建部署是如何對映的呢？下面這張圖就很清晰了，左側的表格記錄了租戶ID、程式碼版本、所屬stackName（不知道怎麼翻譯，其實就是不同的資源池）。
所以，通過這樣來實現，對於一些高階租戶來說，除了資源的隔離之外，軟體版本的隔離也是可以做到的。這樣也消除了，大平臺版本的升級（可能租戶自己並不想升級）影響到某個租戶的情況。
整個租戶建立與隔離資源建立的大概步驟講完了，該演講中還有一些租戶管理、使用者管理、許可權管理、API Gateway上的授權管理等細節這裡就不細節說了，有興趣的小夥伴可以自行觀看這個專題演講：深入探尋無伺服器SaaS參考解決方案的內部原理 進一步瞭解，裡面還有一些簡單程式碼供參考。除此之外，對於正在研究SaaS解決方案的同學，還有一個 多租戶EKS SaaS解決方案 的演講也非常值得一看。
當然了，AWS re:Invent的內容不僅限於SaaS和Serverless，還有很多關於DevOps、GraphQL等精彩的前沿內容。有興趣的小夥伴，可以點選這裡直達內容首頁。
歡迎關注我的公眾號：程式猿DD，分享外面看不到的乾貨與思考！