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