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