編輯導語：云時代 SaaS 產品創業有著大學問，想要學會就更是不容易，這篇文章是O2O 生鮮 SaaS 創業記中的系統篇，從系統這個層面進行講解，一起看看吧。

一、系列簡介

這是一部云時代 SaaS 產品創業記，講述一位技術創業者如何從零開始系統完整建設滿足行業客戶產品，從戰略到戰術，從產品到技術到組織，從定位到定價到盈利，從云到中臺到 SaaS，共計八個篇章內容涵蓋行業/客戶/友商、市場/增長、產品/中臺、云服務/微服務/系統、組織/協同，力求全面清晰講透云時代下 SaaS 產品建設。

二、系統篇序

系統架構從來都是頂層設計，自上而下進行分而治之，本質是領域邏輯和業務邏輯的分類。云時代架構關注復用和彈性，簡單說是中臺和 SaaS 化。

三、云系統架構

在云時代中如何設計和落地符合時代和行業需要的系統架構，如何匹配業務模式更好的支撐業務發展和響應市場變化以及指導組織架構，是業務系統架構師首要思考的問題。

這里業務系統是指支撐業務運營并賺錢或省錢的系統，可以是我們講的外賣平臺管理系統，也可以是滴滴出行那樣打車服務系統，這些都是業務系統，應用云計算特性，做到復用和彈性則是業務系統首要考慮事情。

高性能/高可用/可擴展架構是面向具體系統穩定性的解決方案，是解決大流量、高并發、穩定性問題，采取策略是讀寫分離、分庫分表、高性能緩存、服務集群等。我們需要先架構業務系統，再針對具體業務流量進行高性能/高可用/可擴展架構。

業務系統架構最直接產出是中臺和 SaaS 化系統，中臺解決業務運營能力復用，大致分為技術中臺、業務中臺、數據中臺，SaaS 化系統解決客戶分層和彈性服務。

云時代架構首先要理解什么是云計算，根據 NIST（美國國家標準與技術研究院）以及微軟、IBM、阿里云等對云計算定義為三種服務模式，LaaS（Infrastructure as a Service 基礎設施即服務）、PaaS（Platform as a Service 平臺即服務）、SaaS（Software as a Service 軟件即服務）。

LaaS 是云計算基礎服務層，基礎服務包括云主機、虛擬機、黑金物理計等，主要提供 CPU/內存等計算資源，國內供應商阿里云/華為云/騰訊云，是所有云計算基礎能力，業務架構中了解基礎知識即可無需特別深入。

PaaS 是云計算平臺組建服務層（可以理解為技術中臺），以 docker、kubernets 為代表容器化技術提供容器集群計算，用于建設技術中臺，通過容器編排服務，可以快速建立滿足高性能、高可用、可擴展的數據庫、緩存、mq、logs、網關等，需要重點關注和理解。

SaaS 是云計算業務服務層（可以理解為具體實現業務邏輯層，包含業務中臺/數據中臺），以建設業務中臺、數據中臺等業務系統為核心，包括第三方供應商系統和后臺系統。同樣是由 docker、kubernets 容器技術提供應用運行環境，做到服務隔離和服務彈性。

所有的業務系統都是部署在服務器上，需要 CPU 和內存運行業務應用，需要接入互聯網對外服務，需要 VPN 虛擬內網隔離服務，需要保存數據/圖片/視頻等資源，LaaS 提供的計算、網絡、存儲資源滿足這些需求。

為保存具體的業務數據需要數據庫，為應對大流量需要緩存和負載均衡，為應對高并發需要 mq 和容錯等，為快速發布版本需要 devops，為排查 bug 需要 logs，為保證應用正常運行需要監控，PaaS 提供通用的技術平臺組建，不論是什么業務都會用到這些組件做到復用平臺組建，通過容器化技術可以快速建立滿足高性能、高可用、可擴展的數據庫、緩存、logs、網關等等。

用微服務框架實現的業務邏輯，具體有用戶管理、商品管理、訂單管理、財務管理、售后管理等。有客戶端代碼、有 API 接口代碼、有宏流程模型代碼。SaaS 就是具體實現業務邏輯地方。

四、業務中臺架構

我們在 SaaS 層實現具體業務邏輯，有客戶端、API、前臺業務、中臺 API、第三方供應商、后臺系統（財務審核、OA 審批、客戶管理）等。

客戶端是 vue、react 為主 pc/h5 頁面和小程序客戶端、安卓、ios 客戶端，以及開放給第三方 open API SDK。

網關是所有服務的統一和唯一 API 請求入口，擁有負載均衡、驗證權限、分流請求、熔斷請求、監控請求、公共服務統一邏輯處理等，網關組件往往會搭配 oauth2 作為登錄授權驗證，用戶權限驗證，搭配 erueka 作為 API 接口服務注冊和發現，搭配 apollo 作為配置中心?？梢园l現下圖中藍色部分都是 PaaS 層定義平臺組件部分，這些組件承擔系統中公用和部分非業務邏輯事情。

中臺 API 可以理解為宏流程模型具體實現代碼，關注的整個宏流程模型的具體實現，例如中臺 API 中有一個【外賣平臺商品管理 API】接口，這個 API 做了外賣平臺接口封裝，調用這個接口就可以完成三個平臺的商品管理。因為這個接口實現宏流程模型，除了基本的商品管理新增、修改、刪除外不包含其他的業務邏輯。

這個時候有一個需求需要在客戶添加商品成功后推薦類似商品給客戶繼續添加，這個具體的業務邏輯應該寫在【前臺業務】中，而不是中臺 API 中。因為這個業務邏輯不是宏流程模型中的邏輯，不符合通用業務標準，同時也無法直接復用，因為推薦選項可能是商品類目推薦、也可能是商品名稱相似推薦。

如果這個推薦業務上線后受到客戶歡迎，是可以考慮納入中臺 API 中的。但是不應該修改宏流程模型，因為推薦不屬于外賣平臺管理的行業標準，準確來說這個屬于數據中臺的推薦能力，應該納入數據中臺中實現推薦 API。如果沒有建設數據中臺，那可以考慮新增一個中臺推薦 API 模塊，再修改【前臺業務】把原有邏輯改為調用中臺推薦 API 邏輯即可完成，這樣中臺推薦 API 成為可復用的能力。

通過前臺業務和中臺 API，即業務和領域模型邏輯分離，做到中臺 API 的穩定性、復用性大大提高，前臺業務具備快速響應市場變化和低成本試錯能力。

五、微服務技術棧

技術棧沒有最好只有最適合，根據技術團隊對技術棧了解程度選擇市面上成熟可靠有大廠在生產環境中使用過最好，中小企業微服務選型上以阿里、Google 成熟組建為主，我們以 Java 為例。

dubbo 是阿里開源微服務框架，提供一攬子微服務組件，包括 nacos、dubbo admin、dubbo rpc 等。

spring cloud 是 spring 家族中微服務框架，spring boot 算是 Java 開發應用標準框架，國內應用廣泛。

kubernetes 是 Google 開源容器集群管理服務，具備服務發現、API 網關、配置中心組件功能，可以替代微服務框架來使用，云架構中 PaaS 和 SaaS 都可以用容器構建應用服務，做到服務彈性和隔離，降低業務運營成本，是當前市場上容器技術應用標準框架。

技術棧選擇應該根據團隊能力和人力資源成本考慮，優先選擇技術上成熟穩定和資料豐富的，這樣基本上不會遇到技術上難題，選擇團隊成員都能上手的，否則培訓成本太高容易踩執行不規范的明坑，最后選擇市場面廣的好招聘人員。

六、SaaS 化的彈性服務

市場變化會直接影響系統的穩定性/可用性，首先是流量變化，當某一模塊面對高漲流量時通過容器技術很容易建立多節點應對，例如美團外賣訂單量這天指數級增加帶來超出現有訂單系統能承受最大峰值，我們可以通過 kubernets kubectl 快速新增一個訂單中臺模塊 pod 節點，通過網關動態調整應對峰值流量，當流量下降后我們可以刪除掉新增這個 pod 節點，做到需要時實例化，不需要就刪除，不會浪費資源和成本。

其次是創新業務低成本試錯，很多時候我們會嘗試進入其他行業或熱門市場中，需要產品研發團隊能快速響應需求開發和上線，項目需要控制整個投入成本，例如是對業務基礎上進行微創新，只需要多啟動一個 pod 節點做前臺業務實現，剩下復用中臺接口 API。如果是全新項目沒有可復用的，我們同樣是啟動 pod 節點，部署需要的平臺組件和前臺業務實現，成為一個獨立的系統環境，后期就算失敗也可以快速注銷掉，不會影響其他系統。

七、產品研發成本

產品研發團隊一直是企業成本中心，如何有效提高效率和降低成本，是所有互聯網企業一直追求的命題，最直觀的要求就是投入少、產出多、質量高，特別是創業公司在資源有限情況下，市場雄心很大，需求特別多，投入產品研發資源非常少，這種情況下也很難招聘符合要求和滿意人才去實現業務中臺、技術中臺、數據中臺，更別說云系統架構做到整個系統的復用和彈性。

在資源有限情況下更應該保證每個決策和動作都是有效的，每一個動作都應該計算單項成本，計算階段性總成本，區分哪些動作是有效動作能帶來收益，那些不是應該剔除。

云計算三種模式帶來產品研發成本降低，LaaS 為我們帶來一個月五百元的四核云主機，早期項目流量不多情況下， 可以暫時放棄用作高性能/高可用雙節點和雙備份，等流量上來需要穩定性時，通過 PaaS 可以幾分鐘內搭建起多節點和主從備份等，通過宏流程模型可以獲得穩定業務中臺 API，當需要快速響應需求和試錯時候，可以實例化模型，生產具體前臺業務邏輯滿足市場需求。

八、系統篇總結

充分應用云計算特性發揮三種模式架構特點，構建復用能力的中臺服務和彈性的 SaaS 化服務是云時代產品優勢也是市場競爭利器。

九、組織篇預告

康為定律告訴我們組織架構會影響系統架構和業務架構，如何在云時代進行逆康威定律，做到業務架構指導系統架構進而指導組織架構。

本文由 @徐小威 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Pexels，基于CC0協議