資訊專欄INFORMATION COLUMN
摘要：背景當(dāng)下后都能在手機(jī)鍵盤上敲字如飛，后的都可以坦然的搖微信，移動互聯(lián)網(wǎng)可謂炙手可熱。傳統(tǒng)移動開發(fā)技術(shù)方案難題終端移動平臺太多微信而且不同平臺還有版本差異，對于開發(fā)調(diào)試簡直是一場噩夢，要想實(shí)現(xiàn)統(tǒng)一覆蓋沒有雄厚的資本支持是非常困難的。
背景
當(dāng)下10后都能在手機(jī)鍵盤上敲字如飛，60后的都可以坦然的搖微信，移動互聯(lián)網(wǎng)可謂炙手可熱。隨著智能手機(jī)的快速發(fā)展，移動APP作為登入移動互聯(lián)網(wǎng)最便捷的方式，扼守著移動互聯(lián)網(wǎng)的入口?，F(xiàn)在這類軟件被越來越多的人所青睞，在沒有大量資金的情況下，手機(jī)APP是中小企業(yè)發(fā)展方向的一個很好選擇。對于個人和企業(yè)移動APP 已經(jīng)是創(chuàng)業(yè)和發(fā)展的必備工具。移動互聯(lián)網(wǎng)APP開發(fā)，對于企業(yè)來說面臨著項(xiàng)目周期，資源投入，推廣等諸多問題，而對于個人更是望而卻步。
傳統(tǒng)移動開發(fā)技術(shù)方案：
終端移動平臺太多：Android,IOS,Windows Phone,微信 …. 而且不同平臺還有版本差異，對于開發(fā)調(diào)試簡直是一場噩夢，要想實(shí)現(xiàn)統(tǒng)一覆蓋沒有雄厚的資本支持是非常困難的。
開發(fā)成本：招人難，找到合適的更難，成本高，移動開發(fā)門檻障礙
撿了芝麻丟了西瓜：企業(yè)把精力投入到自己不擅長的領(lǐng)域大多時候并不是一件好事情，對于個人來說更是如此。
全站解決方案：一個優(yōu)秀的APP除了核心業(yè)務(wù)同時也需要其他優(yōu)秀的組件，如:推送，用戶行為分析，市場活動，數(shù)據(jù)統(tǒng)計等等。
運(yùn)維困難：要保證APP的穩(wěn)定可靠運(yùn)行，運(yùn)維是必不可少的一部分，這些工作需要專業(yè)的運(yùn)維團(tuán)隊來做。這樣也加重了企業(yè)的負(fù)擔(dān)。
現(xiàn)在是一個屌絲逆襲的時代，為了幫助企業(yè)和個人無門檻擁有屬于自己的APP，MaxWon 應(yīng)運(yùn)而生。
MaxWon 是基于MaxLeap SaaS 云服務(wù)，集成不同行業(yè)模塊，集 APP 生成，運(yùn)營，分析，自動化運(yùn)維與一體的服務(wù)，用戶只需要關(guān)心自己的業(yè)務(wù)，完全擺脫上面的各種難題。
用戶組合自己想要的模塊，點(diǎn)擊生成APP，就可以生成自己想要的不同平臺的APP，包括Android，IOS,微官網(wǎng)，PC官網(wǎng)。
差異化服務(wù)。由于是面向多租戶的服務(wù)，不同的APP產(chǎn)生的流量可能差異很大，系統(tǒng)要能做到服務(wù)隔離和水平擴(kuò)展。
數(shù)據(jù)隔離與擴(kuò)展。為了保證數(shù)據(jù)安全，每一個APP 都會有一個獨(dú)立的DB，數(shù)據(jù)只能被自己的APP訪問，防止數(shù)據(jù)hack，保證數(shù)據(jù)安全。對于大數(shù)據(jù)量的APP，DB 能夠支持無限擴(kuò)展。
快速部署與自動化運(yùn)維。
服務(wù)的監(jiān)控。由于服務(wù)遍布在集群的不同機(jī)器上，需要能夠監(jiān)控所有租戶服務(wù)的健康狀態(tài)，保證服務(wù)的高可用行，并且能夠水平擴(kuò)展。
支持服務(wù)和數(shù)據(jù)的遷移
能獨(dú)立運(yùn)行的1.0由于MaxWon 需要支持不同行業(yè)，業(yè)務(wù)就會比復(fù)雜，比較多。項(xiàng)目業(yè)務(wù)層是按模塊來劃分，通過不同模塊的組合來不同滿足行業(yè)的需求。
第一版架構(gòu)遵循兩個原則:第一， 以業(yè)務(wù)實(shí)現(xiàn)為目標(biāo)，盡快做出產(chǎn)品原型。由于MaxLeap已經(jīng)有很多基礎(chǔ)的中間件可以直接拿來使用，如:推送，F(xiàn)AQ&Issue，支付，IM&社交等。現(xiàn)在只需要把精力放在MaxWon 自己的業(yè)務(wù)中去。第二，快速響應(yīng)產(chǎn)品的需求，產(chǎn)品指導(dǎo)研發(fā)，很多場景、很多的玩法必須幫助產(chǎn)品實(shí)現(xiàn)，而且速度要非?？?，要快速迭代。
| 描述 | 名稱 |
|---|---|
| 平臺 | JDK 1.8 |
| Web框架 | vertx-jersey(異步) |
| ORM | JOOQ |
| RDS | Mysql |
| NoSql | Mongo |
對于大部分人來說 Vert.x可能會有點(diǎn)陌生,它是基于Netty實(shí)現(xiàn)的異步架構(gòu)，和node.js 極其相似。由于之前做MaxLeap服務(wù)，一直在用Vert.x做為基礎(chǔ)架構(gòu)，整個團(tuán)隊對Vert.x 也很熟悉，該踩得坑也都踩過了，通過Verx-Rpc 可以直接訪問的MaxLeap 的微服務(wù)。在使用Vert.x 時最大的感受就是不能寫同步代碼，否則就會阻塞，導(dǎo)致導(dǎo)致服務(wù)不可用，所以我們的服務(wù)全是基于異步的方式來寫的。由于它是一個輕量級高性能JVM應(yīng)用平臺，支持多語言開發(fā)，它的簡單actor-like 機(jī)制能幫助脫離直接基于多線程編程，天生支持分布式，以后對于服務(wù)擴(kuò)展也是水到渠成的事情。
對于ORM 并沒有使用主流的 Hibernate或者IBATIS,而是使用小眾的JOOQ。JOOQ 相對于其他ORM算是很輕量，提供了強(qiáng)大的DSL 來訪問數(shù)據(jù)庫，靈活，上手很容易，代碼非常接近sql。
JOOQ runtime schema mapping 對于多租戶應(yīng)用程序有很好的支持，可以很容易的實(shí)現(xiàn)為每個租戶分配獨(dú)立的DB。
還有一個重要的原因就是 JOOQ 已經(jīng)和Java8 的Stream API 完全融合,cool!!。函數(shù)式編程表達(dá)性強(qiáng)，并且非常通用。它是數(shù)據(jù)及數(shù)據(jù)流處理的核心。Java開發(fā)人員現(xiàn)在也都知道函數(shù)式編程，而且大家又都用過SQL。想象一下，你用SQL來聲明表來源，把數(shù)據(jù)轉(zhuǎn)化成新的元組流，然后要么將它們作為派生表提供給其它更高級的SQL語句來使用，要么將它們交給你的應(yīng)用程序來處理。
下面就是一段典型的Java代碼
DSLContext create = DSL.using(connection, dialect);
create.select(AUTHOR.FIRST_NAME, AUTHOR.LAST_NAME, count())
.from(AUTHOR)
.join(BOOK).on(BOOK.AUTHOR_ID.equal(AUTHOR.ID))
.where(BOOK.LANGUAGE.equal("DE"))
.and(BOOK.PUBLISHED.greaterThan("20017-01-01"))
.limit(2)
.offset(1)
.fetch(record -> transfer(record))
.stream()
.filter(ele -> null != ele)
.collect(Collectors.toList());
有了JOOQ,Java 8以及Streams API,你可以寫出強(qiáng)大的數(shù)據(jù)轉(zhuǎn)化的API，而且簡單易懂。
將架構(gòu)特點(diǎn)劃分為優(yōu)點(diǎn)和缺點(diǎn)進(jìn)行描述。那么優(yōu)點(diǎn)是：
簡單，易于實(shí)現(xiàn)，不需要額外的基礎(chǔ)支撐
利于業(yè)務(wù)的功能快速實(shí)現(xiàn)
服務(wù)都是以Docker Container 啟動，可以實(shí)現(xiàn)快速發(fā)布與部署
?
缺點(diǎn)：
不同租戶的應(yīng)用無法隔離，所有的APP 都使用相同的Container，這樣會帶來APP之間相互影響，導(dǎo)致服務(wù)不穩(wěn)定的風(fēng)險。
缺少服務(wù)健康檢查。
運(yùn)維成本過大。
1.0的架構(gòu)就是一個簡單的Web系統(tǒng)。負(fù)載均衡使用Nignx，并沒有細(xì)化到租戶級別。業(yè)務(wù)系統(tǒng)通過代碼模塊的形式組織各種業(yè)務(wù)就是一個簡單的Web系統(tǒng)，后面直接掛了數(shù)據(jù)庫，比如商品、訂單、會員、客服，等等?？梢钥吹?，我們這個基礎(chǔ)的架構(gòu)，對外就是HTTP。當(dāng)時兩個人的小團(tuán)隊開發(fā)各種業(yè)務(wù)，我們考慮只能用最簡單、最粗暴的方式實(shí)現(xiàn)，能快速地實(shí)現(xiàn)業(yè)務(wù)。當(dāng)時的流量不是第一重要的問題，也不是最主要的矛盾。
對于這個階段，總結(jié)了三點(diǎn)。第一，技術(shù)來源于業(yè)務(wù)同時提升業(yè)務(wù)發(fā)展，業(yè)務(wù)發(fā)展又反過來推動技術(shù)的前進(jìn)，他們是一個相互影響相互促進(jìn)的關(guān)系。和業(yè)務(wù)共同發(fā)展的技術(shù)才是有生命力的。第二，成熟簡單的技術(shù)就是最合適的，這個理念一直貫穿始終。不要把事情復(fù)雜的形態(tài)呈現(xiàn)給大家，腦子要保持簡單，不要想那么復(fù)雜的事兒。第三，要把能遇到的場景盡量到考慮到，以后架構(gòu)升級不至于很被動。大家看到初始的架構(gòu)等于沒有架構(gòu)，但是這種形式在這時是最符合業(yè)務(wù)需求的一個，能快速迭代，能非常方便上線。
面向多租戶的2.0在MaxWon1.0時代的時候，我們的關(guān)注點(diǎn)更偏向業(yè)務(wù)的實(shí)現(xiàn)，隨著用戶增長，性能和穩(wěn)定性問題逐漸浮上水面，作為一個多租戶的應(yīng)用系統(tǒng)，系統(tǒng)不穩(wěn)定，是非常致命的，2.0解決這些問題也迫在眉睫。
首先要解決的就是服務(wù)分離。其中有兩種方案 ：
每一個租戶APP都有屬于自己的 服務(wù) Container，這樣就解決了租戶之間的相互影響。但是 大部分 APP 訪問點(diǎn)可能很小，甚至是僵尸應(yīng)用。雖然Docker 容器使用的資源很小，但是大量的不活躍應(yīng)用還是會浪費(fèi)掉太多的系統(tǒng)資源，資源利用率低。
按租戶的真實(shí)的訪問量劃分為不同的組，普通規(guī)模應(yīng)用或者是僵尸應(yīng)用都公用同一組Container，中等規(guī)模應(yīng)用 某幾個使用一組Container，對于大量數(shù)據(jù)流量的應(yīng)用 獨(dú)占 同一組Container，這樣的話資源利用率就會很高。缺點(diǎn)就是 普通規(guī)模和中等規(guī)模應(yīng)用 服務(wù)之間還是會有影響，由于這兩種規(guī)模的數(shù)據(jù)訪問的會少很多，出現(xiàn)慢查詢而導(dǎo)致拖慢整個系統(tǒng)的可能性會很小。
對比上面的兩個方案優(yōu)缺點(diǎn)，基于現(xiàn)實(shí)的考慮最終選擇了第二種方案。這就需要能夠隨時監(jiān)控APP的數(shù)據(jù)訪問量，當(dāng)某個APP訪問量快速上升時能夠隨時獨(dú)立出服務(wù)來，這樣就可以最大限度的防止租戶之前相互影響而產(chǎn)生的服務(wù)抖動。
對于服務(wù)監(jiān)控，則采用心跳檢測的方式，每個服務(wù)Container對外暴露一組健康檢查的接口，監(jiān)控系統(tǒng)會定時的巡視所有服務(wù)的健康狀態(tài)，如果由于某種原因被Kill掉，則重啟對應(yīng)Container的并產(chǎn)生告警。
對于數(shù)據(jù)存儲分離 也采用了同樣的思路。對于Mongo ,Pandora本身就支持按不同App 數(shù)據(jù)分治。對于Mysql代理則采用 MaxLeap 研發(fā)的 Circe組件，可以實(shí)現(xiàn)不同App數(shù)據(jù)的隔離。使用AWS ELB 解決了Circe的負(fù)載均衡與高可用。
2.0的采用了服務(wù)和數(shù)據(jù)分離的思想，現(xiàn)在回顧也并不復(fù)雜，對于碼農(nóng)來說這種思想已經(jīng)是非常熟悉的了。如果你的產(chǎn)品功能不多，迭代不是很快，可以放慢一下腳步，停下來一段時間來集中一次重構(gòu)。但對于MaxWon來說這一版本的迭代就像是鳥槍換炮，滿足了大部分的應(yīng)用場景。對于業(yè)務(wù)快速迭代，上線時間緊迫的系統(tǒng)來說，這次重構(gòu)也是一個不小的挑戰(zhàn)。
繼承了原有1.0的特點(diǎn)，保留了其優(yōu)勢
解決了數(shù)據(jù)和服務(wù)隔離與擴(kuò)容的問題
實(shí)現(xiàn)不同租戶的差異化服務(wù)
添加了服務(wù)監(jiān)控與檢查
使用docker 構(gòu)建可以完美的解決環(huán)境沖突的問題，也可以方便快速部署和擴(kuò)容。
