中國式SaaS技術(shù)架構(gòu)

阿朱說 2017-03-02 12:14:40

老外是多租戶SaaS技術(shù)架構(gòu),也就是說,一套分布式應用代碼、一套分布式數(shù)據(jù)庫存儲,在應用架構(gòu)層面做的強大,滿足各個租戶的自定義和系統(tǒng)集成。

SaaS

中國呢,過去的3年已經(jīng)證明面向中小企業(yè)、創(chuàng)業(yè)企業(yè)基本是不靠譜,所以從去年下半年,大家都紛紛殺入中大型企業(yè)、大型企業(yè)。這些中國企業(yè),要么要求在他們的私有云中部署,要么要求在公有云為他們開辟一個專區(qū)專門獨立部署,而且都要求和他們現(xiàn)有的內(nèi)部ERP軟件統(tǒng)一用戶賬號登錄、應用邏輯打通、數(shù)據(jù)打通。

這就是中國的現(xiàn)實,那如何滿足中國的這種需求呢?于是,這就出現(xiàn)了中國式SaaS技術(shù)架構(gòu)。

一、客戶端UI

不同的崗位工作環(huán)境有不同適用的應用技術(shù):

1、對于一線現(xiàn)場(如生產(chǎn)制造、倉儲物流配送),一般采取掃碼POS或微信小程序,掃碼后簡單操作幾下就把業(yè)務關(guān)鍵點記錄了下來。

2、對于一線零售店面收銀,現(xiàn)在大多數(shù)白牌平板App

3、對于來回跑中間分銷、渠道、采購、督導的外勤,基本是手機App來處理業(yè)務

4、對于坐在后端的運營人員、人事法務財務,基本用的就是臺式電腦Web應用來處理業(yè)務

二、后端業(yè)務邏輯層

因為客戶端是不同崗位、不同素質(zhì)能力水平、不同業(yè)務重心、不同工作環(huán)境,所以功能不一樣、用戶體驗不一樣,所以后端的服務層業(yè)務邏輯也都不一樣。

這層因為涉及到客戶端接入,所以需要API網(wǎng)關(guān)中間件,因為比較輕(因為還有一層公共業(yè)務邏輯處理層),所以采取微服務中間件(如SpringCloud),這些不同的微服務都打包在一個個的Docker中,為了快速彈性啟動擴容。前面有API網(wǎng)關(guān)中間件可以做分流限流、路由導流,這樣后面微服務容器怎么擴容,對前端都透明。

但是總有一些業(yè)務邏輯是這四種端應用都要處理的,所以還得分出一層叫做公共業(yè)務邏輯處理層。這些公共業(yè)務邏輯處理層按功能職責也分成一個個的服務,放在Docker容器中,受Swarm或Kubernetes集群管理。

三、分布式技術(shù)中間件層

API網(wǎng)關(guān)中間件就屬于這一層,只不過客戶端來的請求都首先經(jīng)過它再路由到業(yè)務邏輯微服務。

另外一個重要的分布式技術(shù)中間件是數(shù)據(jù)傳輸。可以采取Kafka分布式消息隊列來做數(shù)據(jù)管道。

我們也可以使用ZooKeeper分布式中間件進行各種后端處理服務的配置以及執(zhí)行調(diào)度。

這些分布式中間件也都部署在Docker Swarm集群管理下,用API形式供上下層調(diào)用。 

四、數(shù)據(jù)存儲層

有些數(shù)據(jù)需要放在內(nèi)存里為了快速查詢,所以我們需要用到分布式Redis集群。

有些數(shù)據(jù)需要持久性放在關(guān)系型數(shù)據(jù)里,我們可以用MySQL關(guān)系數(shù)據(jù)庫。為了分布式存儲,我們可以在MySQL之前再放一個MyCAT分庫分表分布式中間件。為了讀寫分離提高性能,我們可以在MyCAT之前再放一層MySQLProxy,用于主備讀寫分離。

有些數(shù)據(jù)是文件形式,如圖片、音頻視頻,我們可以用分布式文件系統(tǒng)和對象存儲系統(tǒng)來存放。我們還可以使用CDN技術(shù)來做這些靜態(tài)文件的分發(fā)加速。

有些數(shù)據(jù)是特殊的數(shù)據(jù)結(jié)構(gòu),如時間序列數(shù)據(jù)(IM消息一般是這樣特點)、如圖數(shù)據(jù)(社交網(wǎng)絡一般是這樣特點)、如大文本數(shù)據(jù)(點評評論一般是這樣特點),為了加快這些特殊結(jié)構(gòu)的數(shù)據(jù)存取,我們可以用時序數(shù)據(jù)庫、圖數(shù)據(jù)庫、文檔數(shù)據(jù)庫等等。

這些數(shù)據(jù)庫引擎可以為了加快性能,部署在物理服務器上。而這些數(shù)據(jù)庫引擎存取的數(shù)據(jù),可以放在塊存儲云硬盤卷上。

五、主數(shù)據(jù)模塊

這是個模塊,會用到后端業(yè)務邏輯層、分布式中間件層、數(shù)據(jù)存儲層的各項技術(shù)。

這個模塊主要有兩大功能:

1、用戶登錄驗證。在API網(wǎng)關(guān)這樣的純技術(shù)中間件基礎(chǔ)上,我們還需要研發(fā)一個用戶登錄網(wǎng)關(guān),用于辨別不同的企業(yè)用戶登錄進來,進行身份認證、路由指定。這個用戶登錄網(wǎng)關(guān)需要和API網(wǎng)關(guān)進行配合使用。因為登錄是每個用戶訪問的第一步,這塊最容易會成為性能瓶頸,所以要盡量做到高性能編碼、分布式擴容/分流負載均衡。

2、主數(shù)據(jù)管理。主數(shù)據(jù)管理有以下主要動作:主數(shù)據(jù)同步復制、主數(shù)據(jù)分發(fā)、主數(shù)據(jù)更新(有先后順序有存取鎖問題)。所以主數(shù)據(jù)需要獨立出來,供各個系統(tǒng)使用。為了防止主數(shù)據(jù)存取成為瓶頸,數(shù)據(jù)庫這塊也需要注意主備讀寫分離、分庫分表、可方便分布式部署。當然也需要有后臺圖形化的主數(shù)據(jù)管理系統(tǒng)來做人工的干預維護。

六、大數(shù)據(jù)倉庫

剛才以上咱們講的都是業(yè)務邏輯處理需要的技術(shù)以及架構(gòu)堆砌模式,對于報表統(tǒng)計、歷史查詢、綜合查詢、商業(yè)指標對比分析,咱們必須把這些工作放到大數(shù)據(jù)套件中來處理,和真正快速業(yè)務處理的系統(tǒng)分開。

不僅僅是要計算資源分開,還要存儲資源也分開。因為對于大數(shù)據(jù),存儲容量要大(但不一定存儲訪問性能要高),內(nèi)存要大(要進行大量數(shù)據(jù)取出進行計算),CPU性能要高(要密集計算)。所以對于統(tǒng)計、查詢、分析這些功能,服務器云主機和云存儲都要和應用業(yè)務處理分離。

分離后,就需要從應用業(yè)務處理系統(tǒng)中抽取數(shù)據(jù)。

所以,對于數(shù)據(jù)抽取層:我們有一系列的ETL工具,還有數(shù)據(jù)爬蟲引擎用于爬內(nèi)外靜態(tài)數(shù)據(jù),還有用Flume、Logstash、Splunk收集IT資源日志和應用系統(tǒng)運行日志。

抽取來的數(shù)據(jù)可以放在大數(shù)據(jù)倉庫中,我們可以采用Hadoop HDFS、Hbase、Hive等等開源中間件。

要計算處理時,我們可以在YARN或MapRedurce計算調(diào)度框架下使用Spark、Storm來進行內(nèi)存計算和流式計算。

處理后的數(shù)據(jù),我們可以用presto查詢,我們也可以用ElasticSearch來搜索。

最后,我們使用一些可視化工具把結(jié)果用圖表形式輸出出去。

七、最后總結(jié)

按照這樣的技術(shù)架構(gòu)搭建好后,每一個客戶要在公有云上專屬獨立部署,那么給它用DevOps工具新啟幾個服務層Docker,如果公共業(yè)務邏輯模式也要變化,那就新啟幾個公共業(yè)務邏輯Docker。畢竟我們有分布式用戶登錄驗證網(wǎng)關(guān)和API網(wǎng)關(guān),所以不管是公有云專屬部署還是私有云部署,都沒問題。

對于主數(shù)據(jù)管理模塊,因為也有UI層、邏輯層、數(shù)據(jù)層,所以主數(shù)據(jù)這些各層的代碼和數(shù)據(jù)和中間件,可以打包成一個部署單元,用一套專門的DevOps工具及腳本進行自動化部署、配置變更、升級。

對于數(shù)據(jù)層,我們有KV分布式數(shù)據(jù)庫、分布式關(guān)系數(shù)據(jù)庫、主備讀寫分離中間件、分庫分表中間件、CDN分發(fā)、時序數(shù)據(jù)庫/文檔數(shù)據(jù)庫/圖數(shù)據(jù)庫、我們確實需要在API網(wǎng)關(guān)路由層面用DevOps工具及腳本、集中配置中間件Puppet來做到自動化部署擴展、配置變更、升級。這樣不同的企業(yè)指向了不同的分布式數(shù)據(jù)庫引擎地址和分布式數(shù)據(jù)庫存儲卷。這樣就方便了既能做公有云專屬部署又能做私有云部署。

但要記住,這樣的架構(gòu)比較適合中國式SaaS。對于國外老美的SaaS,人家一開始目標就是要滿足大中小不同規(guī)??蛻?,要滿足全世界企業(yè),所以如果做成中國式SaaS技術(shù)架構(gòu),那以后會越來越麻煩。所以老外人家的技術(shù)架構(gòu)是一開始很難設(shè)計與搭建,一開始的維護也很麻煩(需要編寫很復雜的自動化運維工具與腳本),但隨著規(guī)模越來越大(比如幾十萬甚至幾百萬家企業(yè)),那老美的SaaS技術(shù)架構(gòu)就顯示出復雜性優(yōu)勢了。

不同發(fā)展階段,使用不同的實現(xiàn)技術(shù)架構(gòu)。你也不用夢想著用一套架構(gòu)逐步演化和層層搭建,就能逐步從滿足中小企業(yè)擴展到滿足跨國企業(yè)。當然作為一個特定的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)。


長按二維碼關(guān)注我們