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