中國(guó)式SaaS技術(shù)架構(gòu)
來源：原創(chuàng) 時(shí)間：2017-05-17 瀏覽：0 次老外是多租戶SaaS技能架構(gòu)，也即是說，一套分布式運(yùn)用代碼、一套分布式數(shù)據(jù)庫(kù)存儲(chǔ)，在運(yùn)用架構(gòu)層面做的強(qiáng)壯，滿意各個(gè)租戶的自定義和體系集成。
我國(guó)呢，曩昔的3年現(xiàn)已證實(shí)面向中小公司、創(chuàng)業(yè)公司根本是不靠譜，所以從上一年下半年，咱們都紛繁殺入中大型公司、大型公司。這些我國(guó)公司，要么懇求在他們的私有云中布置，要么懇求在公有云為他們拓荒一個(gè)專區(qū)專門獨(dú)立布置，并且都懇求和他們現(xiàn)有的內(nèi)部ERP軟件一致用戶賬號(hào)登錄、運(yùn)用邏輯打通、數(shù)據(jù)打通。
這即是我國(guó)的現(xiàn)實(shí)，那怎么滿意我國(guó)的這種需要呢？所以，這就呈現(xiàn)了我國(guó)式SaaS技能架構(gòu)。
一、客戶端UI
不相同的崗位工作環(huán)境有不相同適用的運(yùn)用技能：
1、關(guān)于一線現(xiàn)場(chǎng)（如生產(chǎn)制作、倉(cāng)儲(chǔ)物流配送），通常采納掃碼POS或微信小程序，掃碼后簡(jiǎn)略操作幾下就把事務(wù)要害點(diǎn)記錄了下來。
2、關(guān)于一線零售店面收銀，現(xiàn)在大多數(shù)白牌平板App
3、關(guān)于來回跑中間分銷、渠道、收購(gòu)、督導(dǎo)的外勤，根本是手機(jī)App來處理事務(wù)
4、關(guān)于坐在后端的運(yùn)營(yíng)人員、人事法務(wù)財(cái)政，根本用的即是臺(tái)式電腦Web運(yùn)用來處理事務(wù)
二、后端事務(wù)邏輯層
由于客戶端是不相同崗位、不相同本質(zhì)能力水平、不相同事務(wù)重心、不相同工作環(huán)境，所以功用不相同、用戶體會(huì)不相同，所以后端的效勞層事務(wù)邏輯也都不相同。
這層由于涉及到客戶端接入，所以需要API網(wǎng)關(guān)中間件，由于對(duì)比輕（由于還有一層公共事務(wù)邏輯處理層），所以采納微效勞中間件（如SpringCloud），這些不相同的微效勞都打包在一個(gè)個(gè)的Docker中，為了迅速?gòu)椥园l(fā)動(dòng)擴(kuò)容。前面有API網(wǎng)關(guān)中間件能夠做分流限流、路由導(dǎo)流，這么后邊微效勞容器怎么擴(kuò)容，對(duì)前端都通明。
可是總有一些事務(wù)邏輯是這四種端運(yùn)用都要處理的，所以還得分出一層叫做公共事務(wù)邏輯處理層。這些公共事務(wù)邏輯處理層按功用責(zé)任也分紅一個(gè)個(gè)的效勞，放在Docker容器中，受Swarm或Kubernetes集群辦理。
三、分布式技能中間件層
API網(wǎng)關(guān)中間件就歸于這一層，只不過客戶端來的懇求都首要通過它再路由到事務(wù)邏輯微效勞。
別的一個(gè)主要的分布式技能中間件是數(shù)據(jù)傳輸。能夠采納Kafka分布式音訊隊(duì)列來做數(shù)據(jù)管道。
咱們也能夠運(yùn)用ZooKeeper分布式中間件進(jìn)行各種后端處理效勞的裝備以及履行調(diào)度。
這些分布式中間件也都布置在Docker Swarm集群辦理下，用API方式供上下層調(diào)用。
四、數(shù)據(jù)存儲(chǔ)層
有些數(shù)據(jù)需要放在內(nèi)存里為了迅速查詢，所以咱們需要用到分布式Redis集群。
有些數(shù)據(jù)需要持久性放在聯(lián)系型數(shù)據(jù)里，咱們能夠用MySQL聯(lián)系數(shù)據(jù)庫(kù)。為了分布式存儲(chǔ)，咱們能夠在MySQL之前再放一個(gè)MyCAT分庫(kù)分表分布式中間件。為了讀寫別離進(jìn)步功用，咱們能夠在MyCAT之前再放一層MySQLProxy，用于主備讀寫別離。
有些數(shù)據(jù)是文件方式，如圖像、音頻視頻，咱們能夠用分布式文件體系和方針存儲(chǔ)體系來存放。咱們還能夠運(yùn)用CDN技能來做這些靜態(tài)文件的分發(fā)加速。
有些數(shù)據(jù)是特別的數(shù)據(jù)構(gòu)造，如時(shí)刻序列數(shù)據(jù)（IM音訊通常是這么特色）、如圖數(shù)據(jù)（交際網(wǎng)絡(luò)通常是這么特色）、如大文本數(shù)據(jù)（點(diǎn)評(píng)評(píng)論通常是這么特色），為了加速這些特別構(gòu)造的數(shù)據(jù)存取，咱們能夠用時(shí)序數(shù)據(jù)庫(kù)、圖數(shù)據(jù)庫(kù)、文檔數(shù)據(jù)庫(kù)等等。
這些數(shù)據(jù)庫(kù)引擎能夠?yàn)榱思铀俟τ?，布置在物理效勞器上。而這些數(shù)據(jù)庫(kù)引擎存取的數(shù)據(jù)，能夠放在塊存儲(chǔ)云硬盤卷上。
五、主數(shù)據(jù)模塊
這是個(gè)模塊，會(huì)用到后端事務(wù)邏輯層、分布式中間件層、數(shù)據(jù)存儲(chǔ)層的各項(xiàng)技能。
這個(gè)模塊主要有兩大功用：
1、用戶登錄驗(yàn)證。在API網(wǎng)關(guān)這么的純技能中間件基礎(chǔ)上，咱們還需要研制一個(gè)用戶登錄網(wǎng)關(guān)，用于區(qū)分不相同的公司用戶登錄進(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ù)同步仿制、主數(shù)據(jù)分發(fā)、主數(shù)據(jù)更新（有先后順序有存取鎖疑問）。所以主數(shù)據(jù)需要獨(dú)立出來，供各個(gè)體系運(yùn)用。為了防止主數(shù)據(jù)存取變成瓶頸，數(shù)據(jù)庫(kù)這塊也需要留意主備讀寫別離、分庫(kù)分表、可便利分布式布置。當(dāng)然也需要有后臺(tái)圖形化的主數(shù)據(jù)辦理體系來做人工的干涉保護(hù)。
六、大數(shù)據(jù)倉(cāng)庫(kù)
方才以上咱們講的都是事務(wù)邏輯處理需要的技能以及架構(gòu)堆砌方式，關(guān)于報(bào)表核算、前史查詢、歸納查詢、商業(yè)方針對(duì)比剖析，咱們有必要把這些工作放到大數(shù)據(jù)套件中來處理，和真實(shí)迅速事務(wù)處理的體系分開。
不僅僅是要核算資本分開，還要存儲(chǔ)資本也分開。由于關(guān)于大數(shù)據(jù)，存儲(chǔ)容量要大（但不一定存儲(chǔ)拜訪功用要高），內(nèi)存要大（要進(jìn)行很多數(shù)據(jù)取出進(jìn)行核算），CPU功用要高（要密布核算）。所以關(guān)于核算、查詢、剖析這些功用，效勞器云主機(jī)和云存儲(chǔ)都要和運(yùn)用事務(wù)處理別離。
別離后，就需要從運(yùn)用事務(wù)處理體系中抽取數(shù)據(jù)。
所以，關(guān)于數(shù)據(jù)抽取層：咱們有一系列的ETL東西，還有數(shù)據(jù)爬蟲引擎用于爬表里靜態(tài)數(shù)據(jù)，還有用Flume、Logstash、Splunk搜集IT資本日志和運(yùn)用體系運(yùn)行日志。
抽取來的數(shù)據(jù)能夠放在大數(shù)據(jù)倉(cāng)庫(kù)中，咱們能夠采用Hadoop HDFS、Hbase、Hive等等開源中間件。
要核算處理時(shí)，咱們能夠在YARN或MapRedurce核算調(diào)度框架下運(yùn)用Spark、Storm來進(jìn)行內(nèi)存核算和流式核算。
處理后的數(shù)據(jù)，咱們能夠用presto查詢，咱們也能夠用ElasticSearch來查找。
最終，咱們運(yùn)用一些可視化東西把成果用圖表方式輸出出去。
七、最終總結(jié)
按照這么的技能架構(gòu)建立好后，每一個(gè)客戶要在公有云上專屬獨(dú)立布置，那么給它用DevOps東西新啟幾個(gè)效勞層Docker，假如公共事務(wù)邏輯方式也要改變，那就新啟幾個(gè)公共事務(wù)邏輯Docker。究竟咱們有分布式用戶登錄驗(yàn)證網(wǎng)關(guān)和API網(wǎng)關(guān)，所以不管是公有云專屬布置仍是私有云布置，都沒疑問。
關(guān)于主數(shù)據(jù)辦理模塊，由于也有UI層、邏輯層、數(shù)據(jù)層，所以主數(shù)據(jù)這些各層的代碼和數(shù)據(jù)和中間件，能夠打包成一個(gè)布置單元，用一套專門的DevOps東西及腳本進(jìn)行自動(dòng)化布置、裝備改變、晉級(jí)。
關(guān)于數(shù)據(jù)層，咱們有KV分布式數(shù)據(jù)庫(kù)、分布式聯(lián)系數(shù)據(jù)庫(kù)、主備讀寫別離中間件、分庫(kù)分表中間件、CDN分發(fā)、時(shí)序數(shù)據(jù)庫(kù)/文檔數(shù)據(jù)庫(kù)/圖數(shù)據(jù)庫(kù)、咱們確實(shí)需要在API網(wǎng)關(guān)路由層面用DevOps東西及腳本、集中裝備中間件Puppet來做到自動(dòng)化布置拓展、裝備改變、晉級(jí)。這么不相同的公司指向了不相同的分布式數(shù)據(jù)庫(kù)引擎地址和分布式數(shù)據(jù)庫(kù)存儲(chǔ)卷。這么就便利了既能做公有云專屬布置又能做私有云布置。
但要記住，這么的架構(gòu)對(duì)比合適我國(guó)式SaaS。關(guān)于國(guó)外老美的SaaS，人家一開始方針即是要滿意大中小不相同規(guī)劃客戶，要滿意全世界公司，所以假如做成我國(guó)式SaaS技能架構(gòu)，那以后會(huì)越來越費(fèi)事。所以老外人家的技能架構(gòu)是一開始很難設(shè)計(jì)與建立，一開始的保護(hù)也很費(fèi)事（需要編寫很復(fù)雜的自動(dòng)化運(yùn)維東西與腳本），但隨著規(guī)劃越來越大（比方幾十萬甚至幾百萬家公司），那老美的SaaS技能架構(gòu)就顯示出復(fù)雜性優(yōu)勢(shì)了。
不相同發(fā)展階段，運(yùn)用不相同的完成技能架構(gòu)。你也不必夢(mèng)想著用一套架構(gòu)逐漸演化和層層建立，就能逐漸從滿意中小公司拓展到滿意跨國(guó)公司。當(dāng)然作為一個(gè)特定的SaaS公司，誰也不能既能滿意了創(chuàng)業(yè)公司的需要，又能滿意跨國(guó)公司的需要。所以想想國(guó)內(nèi)如用友這么，既有暢捷通商品與架構(gòu)、又有U8商品與架構(gòu)，又有NC商品與架構(gòu)，分而治之就好。連SAP，也還能有SAP ERP套件和Businees One中小公司兩套不相同商品線不相同技能架構(gòu)。
