老外是多租戶SaaS技術架構，也就是說，一套分布式應用代碼、一套分布式數據庫存儲，在應用架構層面做的強大，滿足各個租戶的自定義和系統集成。
中國呢，過去的3年已經證明面向中小企業、創業企業基本是不靠譜，所以從去年下半年，大家都紛紛殺入中大型企業、大型企業。這些中國企業，要么要求在他們的私有云中部署，要么要求在公有云為他們開辟一個專區專門獨立部署，而且都要求和他們現有的內部ERP軟件統一用戶賬號登錄、應用邏輯打通、數據打通。
這就是中國的現實，那如何滿足中國的這種需求呢？于是，這就出現了中國式SaaS技術架構。
不同的崗位工作環境有不同適用的應用技術：
1、對于一線現場（如生產制造、倉儲物流配送），一般采取掃碼POS或微信小程序，掃碼后簡單操作幾下就把業務關鍵點記錄了下來。
2、對于一線零售店面收銀，現在大多數白牌平板App
3、對于來回跑中間分銷、渠道、采購、督導的外勤，基本是手機App來處理業務
4、對于坐在后端的運營人員、人事法務財務，基本用的就是臺式電腦Web應用來處理業務
因為客戶端是不同崗位、不同素質能力水平、不同業務重心、不同工作環境，所以功能不一樣、用戶體驗不一樣，所以后端的服務層業務邏輯也都不一樣。
這層因為涉及到客戶端接入，所以需要API網關中間件，因為比較輕（因為還有一層公共業務邏輯處理層），所以采取微服務中間件（如SpringCloud），這些不同的微服務都打包在一個個的Docker中，為了快速彈性啟動擴容。前面有API網關中間件可以做分流限流、路由導流，這樣后面微服務容器怎么擴容，對前端都透明。
但是總有一些業務邏輯是這四種端應用都要處理的，所以還得分出一層叫做公共業務邏輯處理層。這些公共業務邏輯處理層按功能職責也分成一個個的服務，放在Docker容器中，受Swarm或Kubernetes集群管理。
API網關中間件就屬于這一層，只不過客戶端來的請求都首先經過它再路由到業務邏輯微服務。
另外一個重要的分布式技術中間件是數據傳輸。可以采取Kafka分布式消息隊列來做數據管道。
我們也可以使用ZooKeeper分布式中間件進行各種后端處理服務的配置以及執行調度。
這些分布式中間件也都部署在Docker Swarm集群管理下，用API形式供上下層調用。
有些數據需要放在內存里為了快速查詢，所以我們需要用到分布式Redis集群。
有些數據需要持久性放在關系型數據里，我們可以用MySQL關系數據庫。為了分布式存儲，我們可以在MySQL之前再放一個MyCAT分庫分表分布式中間件。為了讀寫分離提高性能，我們可以在MyCAT之前再放一層MySQLProxy，用于主備讀寫分離。
有些數據是文件形式，如圖片、音頻視頻，我們可以用分布式文件系統和對象存儲系統來存放。我們還可以使用CDN技術來做這些靜態文件的分發加速。
有些數據是特殊的數據結構，如時間序列數據（IM消息一般是這樣特點）、如圖數據（社交網絡一般是這樣特點）、如大文本數據（點評評論一般是這樣特點），為了加快這些特殊結構的數據存取，我們可以用時序數據庫、圖數據庫、文檔數據庫等等。
這些數據庫引擎可以為了加快性能，部署在物理服務器上。而這些數據庫引擎存取的數據，可以放在塊存儲云硬盤卷上。
這是個模塊，會用到后端業務邏輯層、分布式中間件層、數據存儲層的各項技術。
這個模塊主要有兩大功能：
1、用戶登錄驗證。在API網關這樣的純技術中間件基礎上，我們還需要研發一個用戶登錄網關，用于辨別不同的企業用戶登錄進來，進行身份認證、路由指定。這個用戶登錄網關需要和API網關進行配合使用。因為登錄是每個用戶訪問的第一步，這塊最容易會成為性能瓶頸，所以要盡量做到高性能編碼、分布式擴容/分流負載均衡。
2、主數據管理。主數據管理有以下主要動作：主數據同步復制、主數據分發、主數據更新（有先后順序有存取鎖問題）。所以主數據需要獨立出來，供各個系統使用。為了防止主數據存取成為瓶頸，數據庫這塊也需要注意主備讀寫分離、分庫分表、可方便分布式部署。當然也需要有后臺圖形化的主數據管理系統來做人工的干預維護。
剛才以上咱們講的都是業務邏輯處理需要的技術以及架構堆砌模式，對于報表統計、歷史查詢、綜合查詢、商業指標對比分析，咱們必須把這些工作放到大數據套件中來處理，和真正快速業務處理的系統分開。
不僅僅是要計算資源分開，還要存儲資源也分開。因為對于大數據，存儲容量要大（但不一定存儲訪問性能要高），內存要大（要進行大量數據取出進行計算），CPU性能要高（要密集計算）。所以對于統計、查詢、分析這些功能，服務器云主機和云存儲都要和應用業務處理分離。
分離后，就需要從應用業務處理系統中抽取數據。
所以，對于數據抽取層：我們有一系列的ETL工具，還有數據爬蟲引擎用于爬內外靜態數據，還有用Flume、Logstash、Splunk收集IT資源日志和應用系統運行日志。
抽取來的數據可以放在大數據倉庫中，我們可以采用Hadoop HDFS、Hbase、Hive等等開源中間件。
要計算處理時，我們可以在YARN或MapRedurce計算調度框架下使用Spark、Storm來進行內存計算和流式計算。
處理后的數據，我們可以用presto查詢，我們也可以用ElasticSearch來搜索。
最后，我們使用一些可視化工具把結果用圖表形式輸出出去。
按照這樣的技術架構搭建好后，每一個客戶要在公有云上專屬獨立部署，那么給它用DevOps工具新啟幾個服務層Docker，如果公共業務邏輯模式也要變化，那就新啟幾個公共業務邏輯Docker。畢竟我們有分布式用戶登錄驗證網關和API網關，所以不管是公有云專屬部署還是私有云部署，都沒問題。
對于主數據管理模塊，因為也有UI層、邏輯層、數據層，所以主數據這些各層的代碼和數據和中間件，可以打包成一個部署單元，用一套專門的DevOps工具及腳本進行自動化部署、配置變更、升級。
對于數據層，我們有KV分布式數據庫、分布式關系數據庫、主備讀寫分離中間件、分庫分表中間件、CDN分發、時序數據庫/文檔數據庫/圖數據庫、我們確實需要在API網關路由層面用DevOps工具及腳本、集中配置中間件Puppet來做到自動化部署擴展、配置變更、升級。這樣不同的企業指向了不同的分布式數據庫引擎地址和分布式數據庫存儲卷。這樣就方便了既能做公有云專屬部署又能做私有云部署。
但要記住，這樣的架構比較適合中國式SaaS。對于國外老美的SaaS，人家一開始目標就是要滿足大中小不同規模客戶，要滿足全世界企業，所以如果做成中國式SaaS技術架構，那以后會越來越麻煩。所以老外人家的技術架構是一開始很難設計與搭建，一開始的維護也很麻煩（需要編寫很復雜的自動化運維工具與腳本），但隨著規模越來越大（比如幾十萬甚至幾百萬家企業），那老美的SaaS技術架構就顯示出復雜性優勢了。
不同發展階段，使用不同的實現技術架構。你也不用夢想著用一套架構逐步演化和層層搭建，就能逐步從滿足中小企業擴展到滿足跨國企業。當然作為一個特定的SaaS企業，誰也不能既能滿足了創業企業的需求，又能滿足跨國公司的需求。所以想想國內如用友這樣，既有暢捷通產品與架構、又有U8產品與架構，又有NC產品與架構，分而治之就好。連SAP，也還能有SAP ERP套件和Businees One中小企業兩套不同產品線不同技術架構。
