轉-中國式SaaS技術架構

架構層面作的強大，知足各個租戶的自定義和系統集成。

　　中國呢，過去的3年已經證實面向中小企業、創業企業基本是不靠譜，因此從去年下半年，你們都紛紛殺入中大型企業、大型企業。這些中國企業，要麼要求在他們的私有云中部署，要麼要求在公有云爲他們開闢一個專區專門獨立部署，並且都要求和他們現有的內部ERP軟件統一用戶帳號登陸、應用邏輯打通、數據打通。

　　這就是中國的現實，那如何知足中國的這種需求呢？因而，這就出現了中國式SaaS技術架構。

　　1、客戶端UI

　　不一樣的崗位工做環境有不一樣適用的應用技術：

　　一、對於一線現場（如生產製造、倉儲物流配送），通常採起掃碼POS或微信小程序，掃碼後簡單操做幾下就把業務關鍵點記錄了下來。

　　二、對於一線零售店面收銀，如今大多數白牌平板App

　　三、對於來回跑中間分銷、渠道、採購、督導的外勤，基本是手機App來處理業務

　　四、對於坐在後端的運營人員、人事法務財務，基本用的就是臺式電腦Web應用來處理業務

　　2、後端業務邏輯層

　　由於客戶端是不一樣崗位、不一樣素質能力水平、不一樣業務重心、不一樣工做環境，因此功能不同、用戶體驗不同，因此後端的服務層業務邏輯也都不同。

　　這層由於涉及到客戶端接入，因此須要API網關中間件，由於比較輕（由於還有一層公共業務邏輯處理層），因此採起微服務中間件（如SpringCloud），這些不一樣的微服務都打包在一個個的Docker中，爲了快速彈性啓動擴容。前面有API網關中間件能夠作分流限流、路由導流，這樣後面微服務容器怎麼擴容，對前端都透明。

　　可是總有一些業務邏輯是這四種端應用都要處理的，因此還得分出一層叫作公共業務邏輯處理層。這些公共業務邏輯處理層按功能職責也分紅一個個的服務，放在Docker容器中，受Swarm或Kubernetes集羣管理。

　　3、分佈式技術中間件層

　　API網關中間件就屬於這一層，只不過客戶端來的請求都首先通過它再路由到業務邏輯微服務。

　　另一個重要的分佈式技術中間件是數據傳輸。能夠採起Kafka分佈式消息隊列來作數據管道。

　　咱們也可使用ZooKeeper分佈式中間件進行各類後端處理服務的配置以及執行調度。

　　這些分佈式中間件也都部署在Docker Swarm集羣管理下，用API形式供上下層調用。

　　4、數據存儲層

　　有些數據須要放在內存裏爲了快速查詢，因此咱們須要用到分佈式Redis集羣。

　　有些數據須要持久性放在關係型數據裏，咱們能夠用MySQL關係數據庫。爲了分佈式存儲，咱們能夠在MySQL以前再放一個MyCAT分庫分表分佈式中間件。爲了讀寫分離提升性能，咱們能夠在MyCAT以前再放一層MySQLProxy，用於主備讀寫分離。

　　有些數據是文件形式，如圖片、音頻視頻，咱們能夠用分佈式文件系統和對象存儲系統來存放。咱們還可使用CDN技術來作這些靜態文件的分發加速。

　　有些數據是特殊的數據結構，如時間序列數據（IM消息通常是這樣特色）、如圖數據（社交網絡通常是這樣特色）、如大文本數據（點評評論通常是這樣特色），爲了加快這些特殊結構的數據存取，咱們能夠用時序數據庫、圖數據庫、文檔數據庫等等。

　　這些數據庫引擎能夠爲了加快性能，部署在物理服務器上。而這些數據庫引擎存取的數據，能夠放在塊存儲雲硬盤捲上。

　　5、主數據模塊

　　這是個模塊，會用到後端業務邏輯層、分佈式中間件層、數據存儲層的各項技術。

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

　　一、用戶登陸驗證。在API網關這樣的純技術中間件基礎上，咱們還須要研發一個用戶登陸網關，用於辨別不一樣的企業用戶登陸進來，進行身份認證、路由指定。這個用戶登陸網關須要和API網關進行配合使用。由於登陸是每一個用戶訪問的第一步，這塊最容易會成爲性能瓶頸，因此要儘可能作到高性能編碼、分佈式擴容/分流負載均衡。

　　二、主數據管理。主數據管理有如下主要動做：主數據同步複製、主數據分發、主數據更新（有前後順序有存取鎖問題）。因此主數據須要獨立出來，供各個系統使用。爲了防止主數據存取成爲瓶頸，數據庫這塊也須要注意主備讀寫分離、分庫分表、可方便分佈式部署。固然也須要有後臺圖形化的主數據管理系統來作人工的干預維護。

　　6、大數據倉庫

　　剛纔以上我們講的都是業務邏輯處理須要的技術以及架構堆砌模式，對於報表統計、歷史查詢、綜合查詢、商業指標對比分析，我們必須把這些工做放到大數據套件中來處理，和真正快速業務處理的系統分開。

　　不只僅是要計算資源分開，還要存儲資源也分開。由於對於大數據，存儲容量要大（但不必定存儲訪問性能要高），內存要大（要進行大量數據取出進行計算），CPU性能要高（要密集計算）。因此對於統計、查詢、分析這些功能，服務器雲主機和雲存儲都要和應用業務處理分離。

　　分離後，就須要從應用業務處理系統中抽取數據。

　　因此，對於數據抽取層：咱們有一系列的ETL工具，還有數據爬蟲引擎用於爬內外靜態數據，還有用Flume、Logstash、Splunk收集IT資源日誌和應用系統運行日誌。

　　抽取來的數據能夠放在大數據倉庫中，咱們能夠採用Hadoop HDFS、Hbase、Hive等等開源中間件。

　　要計算處理時，咱們能夠在YARN或MapRedurce計算調度框架下使用Spark、Storm來進行內存計算和流式計算。

　　處理後的數據，咱們能夠用presto查詢，咱們也能夠用ElasticSearch來搜索。

　　最後，咱們使用一些可視化工具把結果用圖表形式輸出出去。

　　7、最後總結

　　按照這樣的技術架構搭建好後，每個客戶要在公有云上專屬獨立部署，那麼給它用DevOps工具新啓幾個服務層Docker，若是公共業務邏輯模式也要變化，那就新啓幾個公共業務邏輯Docker。畢竟咱們有分佈式用戶登陸驗證網關和API網關，因此不論是公有云專屬部署仍是私有云部署，都沒問題。

　　對於主數據管理模塊，由於也有UI層、邏輯層、數據層，因此主數據這些各層的代碼和數據和中間件，能夠打包成一個部署單元，用一套專門的DevOps工具及腳本進行自動化部署、配置變動、升級。

　　對於數據層，咱們有KV分佈式數據庫、分佈式關係數據庫、主備讀寫分離中間件、分庫分表中間件、CDN分發、時序數據庫/文檔數據庫/圖數據庫、咱們確實須要在API網關路由層面用DevOps工具及腳本、集中配置中間件Puppet來作到自動化部署擴展、配置變動、升級。這樣不一樣的企業指向了不一樣的分佈式數據庫引擎地址和分佈式數據庫存儲卷。這樣就方便了既能作公有云專屬部署又能作私有云部署。

　　但要記住，這樣的架構比較適合中國式SaaS。對於國外老美的SaaS，人家一開始目標就是要知足大中小不一樣規模客戶，要知足全世界企業，因此若是作成中國式SaaS技術架構，那之後會愈來愈麻煩。因此老外人家的技術架構是一開始很難設計與搭建，一開始的維護也很麻煩（須要編寫很複雜的自動化運維工具與腳本），但隨着規模愈來愈大（好比幾十萬甚至幾百萬家企業），那老美的SaaS技術架構就顯示出複雜性優點了。

　　不一樣發展階段，使用不一樣的實現技術架構。你也不用夢想着用一套架構逐步演化和層層搭建，就能逐步從知足中小企業擴展到知足跨國企業。固然做爲一個特定的SaaS企業，誰也不能既能知足了創業企業的需求，又能知足跨國公司的需求。因此想一想國內如用友這樣，既有暢捷通產品與架構、又有U8產品與架構，又有NC產品與架構，分而治之就好。連SAP，也還能有SAP ERP套件和Businees One中小企業兩套不一樣產品線不一樣技術架構。