現(xiàn)在是一個(gè)屌絲逆襲的時(shí)代，為了幫助企業(yè)和個(gè)人無(wú)門檻擁有屬于自己的APP，云應(yīng)用平臺(tái)應(yīng)運(yùn)而生。
云應(yīng)用平臺(tái)是基于公司已有的共有云服務(wù)，集成不同行業(yè)模塊，集APP生成，運(yùn)營(yíng)，分析，自動(dòng)化運(yùn)維與一體的服務(wù)，用戶只需要關(guān)心自己的業(yè)務(wù)，完全擺脫上面的各種難題。
圖1 云應(yīng)用平臺(tái)
用戶組合自己想要的模塊，點(diǎn)擊生成APP，就可以生成自己想要的不同平臺(tái)的APP，包括Android，IOS，微官網(wǎng)，PC官網(wǎng)。
需要解決的的問題
差異化服務(wù)。由于是面向多租戶的服務(wù)，不同的APP產(chǎn)生的流量可能差異很大，系統(tǒng)要能做到服務(wù)隔離和水平擴(kuò)展。
數(shù)據(jù)隔離與擴(kuò)展。為了保證數(shù)據(jù)安全，每一個(gè)APP都會(huì)有一個(gè)獨(dú)立的DB，數(shù)據(jù)只能被自己的APP訪問，防止數(shù)據(jù)hack，保證數(shù)據(jù)安全。對(duì)于大數(shù)據(jù)量的APP，DB能夠支持無(wú)限擴(kuò)展。
快速部署與自動(dòng)化運(yùn)維。
服務(wù)的監(jiān)控。由于服務(wù)遍布在集群的不同機(jī)器上，需要能夠監(jiān)控所有租戶服務(wù)的健康狀態(tài)，保證服務(wù)的高可用行，并且能夠水平擴(kuò)展。
支持服務(wù)和數(shù)據(jù)的遷移
能獨(dú)立運(yùn)行的1.0
由于云應(yīng)用平臺(tái)需要支持不同行業(yè)，業(yè)務(wù)就會(huì)比復(fù)雜，比較多。項(xiàng)目業(yè)務(wù)層是按模塊來(lái)劃分，通過不同模塊的組合來(lái)不同滿足行業(yè)的需求。
圖2 云應(yīng)用平臺(tái)項(xiàng)目業(yè)務(wù)層劃分
第一版架構(gòu)遵循兩個(gè)原則：第一，以業(yè)務(wù)實(shí)現(xiàn)為目標(biāo)，盡快做出產(chǎn)品原型。由于公司云平臺(tái)已經(jīng)有很多基礎(chǔ)的中間件可以直接拿來(lái)使用，如:推送，F(xiàn)AQ&Issue，支付，IM&社交等�，F(xiàn)在只需要把精力放在云應(yīng)用自己的業(yè)務(wù)中去。第二，快速響應(yīng)產(chǎn)品的需求，產(chǎn)品指導(dǎo)研發(fā)，很多場(chǎng)景、很多的玩法必須幫助產(chǎn)品實(shí)現(xiàn)，而且速度要非常快，要快速迭代。
主要技術(shù)棧
對(duì)于大部分人來(lái)說Vert.x可能會(huì)有點(diǎn)陌生，它是基于netty實(shí)現(xiàn)的異步架構(gòu)，和node.js極其相似。一直在用Vert.x做為基礎(chǔ)架構(gòu)，整個(gè)團(tuán)隊(duì)對(duì)Vert.x也很熟悉，該踩得坑也都踩過了，通過Verx-Rpc可以直接訪問已有的微服務(wù)。在使用Vert.x時(shí)最大的感受就是不能寫同步代碼，否則就會(huì)阻塞，導(dǎo)致導(dǎo)致服務(wù)不可用，所以我們的服務(wù)全是基于異步的方式來(lái)寫的。由于它是一個(gè)輕量級(jí)高性能JVM應(yīng)用平臺(tái)，支持多語(yǔ)言開發(fā)，它的簡(jiǎn)單actor-like機(jī)制能幫助脫離直接基于多線程編程，天生支持分布式，以后對(duì)于服務(wù)擴(kuò)展也是水到渠成的事情。
對(duì)于ORM并沒有使用主流的Hibernate或者IBATIS，而是使用小眾的JOOQ。JOOQ相對(duì)于其他ORM算是很輕量，提供了強(qiáng)大的DSL來(lái)訪問數(shù)據(jù)庫(kù)，靈活，上手很容易，代碼非常接近sql。
JOOQruntimeschemamapping對(duì)于多租戶應(yīng)用程序有很好的支持，可以很容易的實(shí)現(xiàn)為每個(gè)租戶分配獨(dú)立的DB。
還有一個(gè)重要的原因就是JOOQ已經(jīng)和Java8的StreamAPI完全融合，cool��！。函數(shù)式編程表達(dá)性強(qiáng)，并且非常通用。它是數(shù)據(jù)及數(shù)據(jù)流處理的核心。Java開發(fā)人員現(xiàn)在也都知道函數(shù)式編程，而且大家又都用過SQL。想象一下，你用SQL來(lái)聲明表來(lái)源，把數(shù)據(jù)轉(zhuǎn)化成新的元組流，然后要么將它們作為派生表提供給其它更高級(jí)的SQL語(yǔ)句來(lái)使用，要么將它們交給你的應(yīng)用程序來(lái)處理。
下面就是一段典型的Java代碼
圖3 典型Java代碼
有了JOOQ，Java 8以及Streams API，你可以寫出強(qiáng)大的數(shù)據(jù)轉(zhuǎn)化的API，而且簡(jiǎn)單易懂。
圖4 MaxWon 1.0 Structure
架構(gòu)特點(diǎn)
將架構(gòu)特點(diǎn)劃分為優(yōu)點(diǎn)和缺點(diǎn)進(jìn)行描述。那么優(yōu)點(diǎn)是：
- 簡(jiǎn)單，易于實(shí)現(xiàn)，不需要額外的基礎(chǔ)支撐
- 利于業(yè)務(wù)的功能快速實(shí)現(xiàn)
- 服務(wù)都是以DockerContainer啟動(dòng)，可以實(shí)現(xiàn)快速發(fā)布與部署
缺點(diǎn)：
- 不同租戶的應(yīng)用無(wú)法隔離，所有的APP都使用相同的Container，這樣會(huì)帶來(lái)APP之間相互影響，導(dǎo)致服務(wù)不穩(wěn)定的風(fēng)險(xiǎn)。
- 缺少服務(wù)健康檢查。
- 運(yùn)維成本過大。
1.0的架構(gòu)就是一個(gè)簡(jiǎn)單的Web系統(tǒng)。負(fù)載均衡使用Nignx，并沒有細(xì)化到租戶級(jí)別。業(yè)務(wù)系統(tǒng)通過代碼模塊的形式組織各種業(yè)務(wù)就是一個(gè)簡(jiǎn)單的Web系統(tǒng)，后面直接掛了數(shù)據(jù)庫(kù)，比如商品、訂單、會(huì)員、客服，等等�？梢钥吹剑覀冞@個(gè)基礎(chǔ)的架構(gòu)，對(duì)外就是HTTP。當(dāng)時(shí)兩個(gè)人的小團(tuán)隊(duì)開發(fā)各種業(yè)務(wù)，我們考慮只能用最簡(jiǎn)單、最粗暴的方式實(shí)現(xiàn)，能快速地實(shí)現(xiàn)業(yè)務(wù)。當(dāng)時(shí)的流量不是第一重要的問題，也不是最主要的矛盾。
對(duì)于這個(gè)階段，總結(jié)了三點(diǎn)。第一，技術(shù)來(lái)源于業(yè)務(wù)同時(shí)提升業(yè)務(wù)發(fā)展，業(yè)務(wù)發(fā)展又反過來(lái)推動(dòng)技術(shù)的前進(jìn)，他們是一個(gè)相互影響相互促進(jìn)的關(guān)系。和業(yè)務(wù)共同發(fā)展的技術(shù)才是有生命力的。第二，成熟簡(jiǎn)單的技術(shù)就是最合適的，這個(gè)理念一直貫穿始終。不要把事情復(fù)雜的形態(tài)呈現(xiàn)給大家，腦子要保持簡(jiǎn)單，不要想那么復(fù)雜的事兒。第三，要把能遇到的場(chǎng)景盡量到考慮到，以后架構(gòu)升級(jí)不至于很被動(dòng)。大家看到初始的架構(gòu)等于沒有架構(gòu)，但是這種形式在這時(shí)是最符合業(yè)務(wù)需求的一個(gè)，能快速迭代，能非常方便上線。
面向多租戶的2.0
在MaxWon1.0時(shí)代的時(shí)候，我們的關(guān)注點(diǎn)更偏向業(yè)務(wù)的實(shí)現(xiàn)，隨著用戶增長(zhǎng)，性能和穩(wěn)定性問題逐漸浮上水面，作為一個(gè)多租戶的應(yīng)用系統(tǒng)，系統(tǒng)不穩(wěn)定，是非常致命的，2.0解決這些問題也迫在眉睫。
要解決的問題
首先要解決的就是服務(wù)分離。其中有兩種方案：
1、每一個(gè)租戶APP都有屬于自己的服務(wù)Container，這樣就解決了租戶之間的相互影響。但是大部分APP訪問點(diǎn)可能很小，甚至是僵尸應(yīng)用。雖然Docker容器使用的資源很小，但是大量的不活躍應(yīng)用還是會(huì)浪費(fèi)掉太多的系統(tǒng)資源，資源利用率低。
2、按租戶的真實(shí)的訪問量劃分為不同的組，普通規(guī)模應(yīng)用或者是僵尸應(yīng)用都公用同一組Container，中等規(guī)模應(yīng)用某幾個(gè)使用一組Container，對(duì)于大量數(shù)據(jù)流量的應(yīng)用獨(dú)占同一組Container，這樣的話資源利用率就會(huì)很高。缺點(diǎn)就是普通規(guī)模和中等規(guī)模應(yīng)用服務(wù)之間還是會(huì)有影響，由于這兩種規(guī)模的數(shù)據(jù)訪問的會(huì)少很多，出現(xiàn)慢查詢而導(dǎo)致拖慢整個(gè)系統(tǒng)的可能性會(huì)很小。
對(duì)比上面的兩個(gè)方案優(yōu)缺點(diǎn)，基于現(xiàn)實(shí)的考慮最終選擇了第二種方案。這就需要能夠隨時(shí)監(jiān)控APP的數(shù)據(jù)訪問量，當(dāng)某個(gè)APP訪問量快速上升時(shí)能夠隨時(shí)獨(dú)立出服務(wù)來(lái)，這樣就可以最大限度的防止租戶之前相互影響而產(chǎn)生的服務(wù)抖動(dòng)。
對(duì)于服務(wù)監(jiān)控，則采用心跳檢測(cè)的方式，每個(gè)服務(wù)Container對(duì)外暴露一組健康檢查的接口，監(jiān)控系統(tǒng)會(huì)定時(shí)的巡視所有服務(wù)的健康狀態(tài)，如果由于某種原因被Kill掉，則重啟對(duì)應(yīng)Container的并產(chǎn)生告警。
圖4 MaxWon 2.0 Structure
對(duì)于數(shù)據(jù)存儲(chǔ)分離也采用了同樣的思路。對(duì)于Mongo，Pandora本身就支持按不同App數(shù)據(jù)分治。對(duì)于Mysql代理則采用自研的Circe組件，可以實(shí)現(xiàn)不同App數(shù)據(jù)的隔離。使用AWSELB解決了Circe的負(fù)載均衡與高可用。
2.0的采用了服務(wù)和數(shù)據(jù)分離的思想，現(xiàn)在回顧也并不復(fù)雜，對(duì)于碼農(nóng)來(lái)說這種思想已經(jīng)是非常熟悉的了。如果你的產(chǎn)品功能不多，迭代不是很快，可以放慢一下腳步，停下來(lái)一段時(shí)間來(lái)集中一次重構(gòu)。但對(duì)于MaxWon來(lái)說這一版本的迭代就像是鳥槍換炮，滿足了大部分的應(yīng)用場(chǎng)景。對(duì)于業(yè)務(wù)快速迭代，上線時(shí)間緊迫的系統(tǒng)來(lái)說，這次重構(gòu)也是一個(gè)不小的挑戰(zhàn)。
優(yōu)勢(shì)
- 繼承了原有1.0的特點(diǎn)，保留了其優(yōu)勢(shì)
- 解決了數(shù)據(jù)和服務(wù)隔離與擴(kuò)容的問題
- 實(shí)現(xiàn)不同租戶的差異化服務(wù)
- 添加了服務(wù)監(jiān)控與檢查
- Docker構(gòu)建和發(fā)布
使用docker構(gòu)建可以完美的解決環(huán)境沖突的問題，也可以方便快速部署和擴(kuò)容。
圖5 Docker構(gòu)建
通過spotifydocker-maven-plugin插件，根據(jù)事先定義在項(xiàng)目中的DockerFile可以輕松的把項(xiàng)目打包成可執(zhí)行的dockerImage并push到生產(chǎn)環(huán)境中。
圖6 Docker構(gòu)建
好用的中間件
Hydra：海德拉古希臘神話人物，是一種傳說中有九個(gè)頭的大蛇，為冥王看守門戶。在這里Hydra作為MaxWon的API網(wǎng)關(guān)，管理來(lái)自不同端的請(qǐng)求，根據(jù)請(qǐng)求的來(lái)源轉(zhuǎn)發(fā)到相應(yīng)的服務(wù)容器組中。同時(shí)它也會(huì)管理和監(jiān)控容器狀態(tài)以及對(duì)服務(wù)的動(dòng)態(tài)擴(kuò)容。
圖7 Hydra-MaxWon的API網(wǎng)關(guān)
Circe：希臘神話里一個(gè)能制造幻覺的女巫，這里用來(lái)隱喻能夠制造Mysql服務(wù)的代理的項(xiàng)目.通過它可以實(shí)現(xiàn)不同租戶的數(shù)據(jù)隔離，過濾非法，有毒的sql語(yǔ)句，保證數(shù)據(jù)隱私和安全。
Pandora：訪問MongoDB的基礎(chǔ)組件，提供了同步和異步的兩種接口。Pandora最為核心的功能是實(shí)現(xiàn)了資源限制和數(shù)據(jù)庫(kù)訪問的路由策略，這對(duì)數(shù)據(jù)庫(kù)進(jìn)行平滑的動(dòng)態(tài)擴(kuò)展及遷移提供了可靠的支持。感興趣的可以參考同事寫的MONGO集群設(shè)計(jì)
總結(jié)
脫離業(yè)務(wù)談架構(gòu)都是扯淡，利用技術(shù)手段提升工作效率是好事，別陷進(jìn)去，產(chǎn)品最終拿出來(lái)說話的還是有沒有解決用戶的問題，而不是解決你自己的問題。對(duì)于MaxWon這種快速迭代的系統(tǒng)，系統(tǒng)也會(huì)考慮更多的業(yè)務(wù)場(chǎng)景，體積也越來(lái)越龐大，遇到棘手的問題也會(huì)越來(lái)越多，做好優(yōu)化的準(zhǔn)備。
系統(tǒng)要盡量保持簡(jiǎn)單，技術(shù)架構(gòu)的選型建議是尋找當(dāng)前最短路徑，然后進(jìn)行不斷優(yōu)化迭代，想一口吃個(gè)大胖子不太可能。
代碼不要寫死。
核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文標(biāo)題：移動(dòng)云平臺(tái)的基礎(chǔ)架構(gòu)之旅（一）：云應(yīng)用
本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839719494.html
相關(guān)文章
