## UCToo產品體系架構 [UCToo運營服務器](https://gitee.com/uctoo/uctoo)：主要實現SaaS平臺運營域相關功能，包含多商戶管理、多應用管理、應用實例模板管理、應用實例銷售/分發/部署、渠道管理、微信第三方平臺、API管理等功能，一個UCToo運營服務器的部署實例是一個SaaS平臺，可以作為微信第三方服務商運營平臺。 應用實例模板：應用實例模板是一個可獨立部署給客戶使用的完整應用單元，一般由UCToo APP 客戶端和UCToo APP 服務器端組成。應用實例模板在通過SaaS平臺部署給商戶時，由SaaS平臺初始化各項應用實例模板與客戶相關的配置項。 應用實例模板開發應遵循[www.uctoo.org](https://www.uctoo.org)制定的統一應用實例模板開發規范，以使得無論采用何種技術選型的應用，都可以通過UCToo運營服務器進行應用實例模板管理，并進行應用實例模板的商業化分發和部署。 開發相關文檔請參考 [UCToo開源版開發手冊](http://www.hmoore.net/doc_uctoo/uctoo_dev) 更多關于SaaS產品架構方面的想法，請參考作者公眾號文章[《基于云原生技術構建去中心化SaaS產品》](https://mp.weixin.qq.com/s/FhnJdTofx4btb738UlsF8g) # :-: 基于云原生技術構建去中心化SaaS產品 近兩年隨著C端流量飽和，B端業務成為尋找新增長點的重要領域，而在to B業務中，SaaS產品又是極其重要的一個組成部分。UCT作為一家多年SaaS產品的廠商，在近年基于云原生技術開發的實踐中，看到了一些SaaS產品發展的新契機，在此分享我們的一些最佳實踐。 業內人士都有共識，國內的SaaS產業環境與國外有很大不同，國內SaaS廠商的盈利能力普遍不佳，甚至一些已上市的SaaS廠商都還在連年虧損。究其原因，固然有SaaS產品復雜度高，客戶需求多樣且多變，市場雖在快速增長但總體規模仍然不大等復雜原因，但深層次的根本問題，我認為還是在于技術能力與底層商業邏輯無法滿足市場需求。 ## SaaS成熟度模型 傳統的SaaS成熟度模型分為四級（從0級開始編號）[[1]](#anchor1 "SaaS成熟度模型")： Level 0.定制開發 Level 1.可配置 Level 2.可配置、多租戶 Level 3.可擴展、可配置、多租戶  :-: *圖1.SaaS成熟度模型* 后有專家評論，用不同的詮釋方式，在以上四級后添加了第4級[[2]](#anchor2 "SaaS成熟度模型level4")：， Level 0. (Chaos 混亂的) Level 1. (Managed Chaos 受控的混亂) Level 2. (Multi-Tenant, Highrise 單實例多租戶) Level 3. (Multi-Tenant, Build-Out 可擴展多租戶) Level 4. (Utopia): This is like Level 3, except you've figured out an efficient way to run different versions of the software on different "instances". 譯文：level4（烏托邦）：如同第 3 級，除非你可以找出有效的方式，以在不同的“實例”上運行不同版本的軟件。一句話道出了事情的本質。 隨著近年云原生技術體系的發展和商業化落地，我們初步看到了實現烏托邦級SaaS產品的可行性。UCT于2019年中開始組織開發人員參與小程序云開發的技術培訓和學習，至2020年開始全面采用小程序云開發技術進行項目和產品的開發。通過具體的開發實踐，在此總結level4級SaaS產品的主要特點。 ## 烏托邦級SaaS成熟度特點 1. 去中心化架構。 涉及租戶的具體應用，并沒有任何需要中心化的節點參與其中。云基礎設施提供商通過IaaS/PaaS/SaaS的分層解耦，實現了SaaS層的去中心化。  :-: *圖2.去中心化SaaS產品架構* 2. 運營與應用分離。 SaaS產品的運營域與應用域明顯分離。SaaS廠商的運營支撐系統主要實現業務運營所需的功能，例如，租戶業務受理、應用/服務購買、應用配置/部署、渠道管理等。具體租戶使用的應用實例，可以像單租戶產品一樣開發，無需考慮復雜的數據分隔、負載均衡等，每個租戶部署的實例都是程序和數據完全獨立的實例。 3. 應用模板遵循統一開發規范，可商業化分發和部署，可實現跨服務商間的應用集成。 SaaS生態體系的全景圖大致是這樣。  :-: *圖3.Level 4 SaaS生態體系全景圖* 一個SaaS服務商可以運營多個SaaS平臺。每個租戶可以通過應用實例模板部署具體的應用實例，每個應用實例都是私有化的程序和數據歸屬。生態體系遵循統一的應用實例模板開發規范。應用實例還可以在服務商間進行集成。 4. 靈活的計費模式，可以按需計費。 不僅可以實現傳統的按時長、按功能/模塊、按用戶量等計費模式，還可精細化到按需計費按資源用量計費。 5. 低代碼且高度可配置。 應用實例模板的開發遵循微服務、數據/業務/表現層分離（前后端分離）、高度可配置、面向租戶低代碼等的開發理念。 6. 高安全性、高可用性。 得益于去中心化、運營與應用分離、實例間相互獨立/資源隔離、PaaS/IaaS提供高水平SLA等的保障，顯著提高了每個租戶的安全性和可用性。 7. 適用于所有類型的用戶。 SaaS應用不僅可以滿足預算有限的小微企業，還可以適用于有較多預算的大中型企業，如有必要，可以實現代碼級的定制需求。 8. 技術及廠商中立。 客戶的需求永遠是分散和多元化的，SaaS服務商無法限定客戶必須在哪個生態中開展業務和拓展用戶，因此烏托邦級的SaaS應是技術及廠商中立的，在一個生態中的最佳實踐，可以較快的復制到其他生態中，為客戶提供持續一致的產品和服務體驗。 9. 社會化生產 生產力與生產關系之間的普適規律永遠有效。烏托邦級的SaaS產品應能支持廠商、客戶、開發者的廣泛參與，以與去中心化生態體系相匹配的方式實現社會化的生產和運營。因此開源應是這一級產品的重要特征，但也需有技術和監管保障所有參與方的知識產權、數據所有權以及商業利益受到保護。 在實現烏托邦級后，SaaS 5 級成熟度模型對比[[3]](#anchor3 "SaaS 5 級成熟度模型對比")：  :-: *圖4.Level 4 SaaS成熟度模型對比* ## 微信生態里的工程實踐 回顧微信服務商生態的發展歷程，基本吻合了SaaS成熟度從0到4級的一個升級過程。 UCT成立于2014年，當時微信用戶正在高速增長，微信公眾平臺推出不久，市場上微信營銷、微信自媒體的風潮開始火熱。基于微信公眾平臺（mp.weixin.qq.com）進行H5應用開發的需求高漲，一批微信服務商開始涌現。然而，當年受限于技術發展水平，服務商大部分都是項目定制開發階段，甚至微信官方的文檔和sdk都錯誤不少，因此，也出現了一些第三方的SDK和開發框架，幫助客戶和開發者降低微信應用的開發復雜度提高開發效率。微信生態基本上是一種混亂的野蠻生長，缺少規范和監管的狀態。  :-: *圖5.微信生態缺失的部分* 上圖取自UCT商業計劃的2015年版本，這些年來幾乎沒怎么變過，只在小程序產品出現后修改了幾個字。 2015年，微信推出了微信開放平臺(open.weixin.qq.com)，第三方開發商初步有了較為一致的服務接入能力，第三方開發商的產品也開始初步SaaS化，開始支持多租戶和一定程度的可配置。 發展到2017年，第三方開發商逐漸細分賽道，開始做一些垂直行業解決方案，此時的SaaS產品已經有了比較成型的產品架構和服務體系。SaaS產品基本達到了level2的水平。 這一年微信小程序的發布，為第三方服務商注入了新的動力，基本上從生態級別提供了較為一致的開發規范，真正補足了微信生態體系缺失的部分。各第三方服務商開始支持基于小程序的產品和解決方案。 隨著最近兩年微信小程序云開發的逐漸成熟，及其背后騰訊云CloudBase云原生技術的廣泛采用，為微信生態的服務商實現level4級SaaS產品奠定了基礎。 ## 騰訊云云原生技術體系符合烏托邦級SaaS需求的主要特性 1. 去中心化 微信生態本身就是去中心化的，微信官方形容這是一個繁榮的森林，不會存在參天大樹遮蔽了花花草草的成長，再小的品牌都能在微信生態有成長的空間，如今微信生態依然是經營私域流量的首選陣地。 與此相對應的，采用云開發技術實現的微信小程序，帳號和數據都是歸屬租戶所有的。租戶授權小程序/公眾號到第三方平臺，由第三方平臺代為實現業務，在第三方平臺將小程序模版，云函數、數據庫部署到租戶小程序帳號和小程序云開發環境后，商戶應用與第三方SaaS平臺就可以不存在必然關聯關系了。  :-: *圖6.租戶授權小程序/公眾號至第三方平臺代為實現業務* 2. 運營與應用分離 微信第三方平臺服務商的運營支撐系統，主要面向平臺運營人員以及渠道等運營營銷參與者進行設計和功能開發。例如，實現租戶管理、租戶業務受理、小程序/公眾號的授權管理、應用/服務購買、應用配置/部署、渠道管理等。 SaaS服務商具體提供給租戶使用的應用，簡化成第三方平臺小程序模板的開發。可以是完全采用云原生技術的包含云函數、云數據庫的資源包。也可以是開發商原有已開發的產品進行應用容器化升級后的產品。而且傳統的ISV只需要少量的技術升級和適配即可將已有產品接入成level4級SaaS生態的組成部分，可以最大程度的保護已有開發成果。可以采用云托管將應用實例docker部署給租戶。  :-: *圖7.第三方平臺小程序模板管理* 3. 統一開發規范 微信小程序提供了一套基本一致的開發技術體系，小程序中支持插件機制，同時商戶的帳號開發權限集可以授權給多個第三方服務商，小程序的開發可以實現搭積木的效果。例如，需要開通直播功能、發票功能的小程序，只需要幾行代碼就可以集成微信官方的直播組件或者其他第三方服務商開發的發票插件，客服插件等等。微信官方還組織了第三方平臺服務市場，商戶可以尋找適合自己業務的產品和解決方案。  :-: *圖8.第三方平臺開發權限集* 應用實例還可以在服務商間進行集成，小程序云開發甚至從PaaS層面提供了插件的更新和依賴機制。至于服務商間應用的商業化分發和部署好像還沒有什么實現案例。  :-: *圖9.插件更新* 一個第三方平臺帳號目前可以發布5個第三方平臺，一家SaaS廠商可以按行業或功能集形成行業解決方案。微信開放平臺中，不同第三方平臺的小程序模板是相互隔離的，第三方開發商沒有技術方式獲取到其他第三方平臺小程序的源碼。  :-: *圖10. 一家SaaS廠商發布的第三方平臺* 4. 按需計費 傳統SaaS產品很難實現按需計費。讓本身沒什么預算的小微企業每年支付幾千上萬的SaaS租用費，對他們可能有些壓力，更何況購買的SaaS產品可能根本沒有多少業務量，更沒有帶來預期的價值，可能這也是很多SaaS產品續費率低的原因。包年套餐的付費模式更是將個人用戶擋在了門外。而對于一些自帶流量的大客戶，就算SaaS廠商收取每年幾萬的最高級資費套餐，也難以覆蓋客戶百萬千萬級的用戶對SaaS資源的消耗量。這可能也是很多SaaS廠商GMV的增長并未帶來收入的正比增長，反而帶來巨大的基礎設施投入成本的重要原因。 而采用小程序云開發，就由PaaS基礎設施提供了精確到資源實際消耗量的計費能力。甚至入門的基礎版套餐都是免費的，使得實現每個人的小程序提供了可能。  :-: *圖11.小程序云開發資費套餐* 5. 低代碼/高度可配置 從用戶的視角來說，SaaS租戶多數不具備很高水平的IT技能，這就要求SaaS的應用開發商，應盡可能的實現功能配置和運營的簡化、可視化、移動化。租戶不僅可以實現自助服務，降低運營成本，在租戶自己無法完成必要的操作時，實施人員或者客服也可以快捷的代為完成一些配置。在UCT已實施的SaaS案例中，就有實現了很少的運營人員即可支撐一個垂直行業SaaS平臺運營的案例，極大提高了ROI。 從開發的角度來說，應盡可能的合理拆分應用服務的顆粒度，提高代碼、模塊的復用度。如能總結一類業務和操作的共性，最好可以實現代碼的自動化生成機制，提高開發效率，向實現AI編程、填空式編程的方向發展。在微信第三方小程序模板的開發中，小程序模板定義了小程序的能力集，具體商戶通過各自的個性化配置和模板裝修獲得自定義的ext_json，最終發布成符合自身需求的小程序應用實例。  :-: *圖12.可視化配置的自定義表單和界面裝修* 數據/業務/表現層分離（前后端分離）。如果全部采用小程序云開發的官方技術體系，云函數、云數據庫是與小程序前端耦合在一起的，并不符合此項特性。這可能是對于希望能夠一次開發多云部署，能夠快速將業務拓展到其他生態體系的SaaS廠商來說是個需要注意的問題。 6. 高安全性、高可用性。 得益于去中心化、運營與應用分離、實例間相互獨立/資源隔離，在最極端的情況下，即使第三方平臺的SaaS運營平臺不可用了，也不會影響每個租戶的業務持續性。PaaS/IaaS基礎設施提供商還有很多云安全、備份、彈性計算的基礎設施，可以有效增加租戶的安全性和可用性。 7. 適用于所有類型的用戶。 你問一個每年只有2000元預算的客戶，是否需要源代碼是否需要數據私有，他給你的回復大概率都是，“很好，需要！”。其實，客戶可能永遠都不會去了解源代碼，也不關心具體的技術實現，他們只是希望以后業務拓展后，可以預留升級和定制的能力。采用云原生技術體系進行的SaaS應用交付和部署，恰恰可以滿足這樣的需求。業界也有通識，中小企業的市場是比較難做的，總體規模不大也沒什么利潤。SaaS產品能夠服務腰部和頭部的企業才能打開更大的市場空間。大客戶項目的實施，不可避免就會有很多定制的需求，無論是對接客戶已有的ERP平臺，還是同步客戶在各個電商平臺的數據，基本都得是源碼級別的定制開發。采用云原生技術的SaaS應用交付是符合源碼和私有數據需求的。對于實現在不同的“實例”上運行不同版本的軟件是正確的發展方向。 現在很多SaaS廠商為了實現客戶的定制化需求，做了不少PaaS和開放平臺方面的嘗試，雖然不能說是完全沒用，但總感覺不是終極的解決方案。我們也做過PaaS方向的嘗試，下圖來自UCT商業計劃2017年版本的一頁。總結起來就是坑多效果少，大概不是正確的方向。  :-: *圖13. UCT商業計劃節選* 8. 技術及廠商中立 2015年成立的云原生計算基金會CNCF[[4]](#anchor4 "CNCF云原生計算基金會"),推動了很多云原生技術的發展。廠商中立也是CNCF的一項理念。主流云服務提供商的基礎設施也大多采用CNCF涵蓋的技術體系進行的定制化實現。對于SaaS廠商來說，想要提高開發成果的通用性，最好也參考云原生技術體系中各個項目主線版本的技術實現，盡量減少采用云基礎設施提供商定制部分的技術實現。 9. 社會化生產 生產力決定生產關系。新技術的發展也需要有相匹配的生產方式。UCT從成立之初就確定了開源的理念。我們覺得SaaS廠商開源產品和應用的主線版本，開發者、交付工程師基于合作發展的共同利益，能夠自由的參與和貢獻能力，并獲取收益應該是更先進的生產方式。 當然開源和商業的邊界，開源產品的盈利能力和知識產權保護等方面還有很多需要解決和完善的問題。ICT產業的大部分技術都是建立在開源理念的成果之上，方向應該是沒有錯的。 ## SaaS產品的終極形態 雖然我也不確定SaaS產品的終極形態是怎樣的。但感覺大致的方向應該是SaaS開發商基于云原生的技術體系，遵循一致的開發規范和協議，進行運營平臺和應用實例的產品開發。ISV開發的應用可以在SaaS和PaaS平臺間商業化的分發和部署。CNCF涵蓋的技術體系和W3C關于web applications、widget等規范[[5]](#anchor5 "SaaS level4 參考規范")都是可以參考的一些技術體系。 以上微信生態的具體實踐，相信在阿里、鴻蒙、抖音等生態可能也有對應的解決方案。UCT自成立以來主要在微信生態拓展業務，受限于時間、資源等方面的條件，還未在其他生態進行投入，歡迎其他生態的開發者分享相應生態的最佳實踐。 想法可以在天上飛，但是路還是要腳踏實地的一步一步走。UCT基于新的技術體系正在構建level4級的SaaS產品和生態，我們現已開源了運營域的UCToo運營平臺框架，項目地址 [gitee.com/uctoo/uctoo](https://gitee.com/uctoo/uctoo) ，應用開發服務器、低代碼前端組件等其他相關組成部分正在規劃開源中。 云原生技術對構建先進的SaaS產品具有很大的促進作用，同時業界需要更多最佳實踐指引新技術的商業化和落地，在此本公司提議成立一個通用云技術開源組織（Universal Cloud Technology Open source Organization），為符合level4級的開源項目提供孵化、技術支持和商業化服務。在此捐贈 [www.uctoo.org](https://www.uctoo.org) 域名用于UCTOO的建設。歡迎業界同行共同參與。 ## 參考資料 <span id="anchor1">1. [https://docs.microsoft.com/zh-cn/archive/blogs/gianpaolo/saas-simple-maturity-model](https://docs.microsoft.com/zh-cn/archive/blogs/gianpaolo/saas-simple-maturity-model)</span> <span id="anchor2">2. [https://www.infoq.com/news/2008/02/saas-architecture-maturity-model](https://www.infoq.com/news/2008/02/saas-architecture-maturity-model)</span> <span id="anchor3">3. [https://wenku.baidu.com/view/a65b20bdc850ad02df8041f4.html](https://wenku.baidu.com/view/a65b20bdc850ad02df8041f4.html)</span> <span id="anchor4">4. [https://www.cncf.io](https://www.cncf.io)</span> <span id="anchor5">5. [https://www.w3.org](https://www.w3.org)</span> **后記**：本來想新注冊個域名用于通用云技術開源組織的官網，避免機構名和我們產品名重復，但是竟然發現uctos.com域名上個月被google搶注了，這就有點惱火了。他們不差錢的叫基金會，咱們差錢的那就叫組織了。