關于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，分享外面看不到的干貨與思考！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/379048.html
標籤：Java