摘要：扯遠(yuǎn)了，是統(tǒng)一數(shù)據(jù)訪問層的實現(xiàn)，主要是針對數(shù)據(jù)的操作，所以，不僅僅是用在中，在中所有應(yīng)用中，需要訪問數(shù)據(jù)庫的都是通過來進(jìn)行的并且提供了異步和同步兩種接口主要實現(xiàn)了兩種模式的數(shù)據(jù)訪問，和。

任何一個App都需要一個Server，我們認(rèn)為，移動開發(fā)者（或組織）不應(yīng)該把精力放在這些事情上面：

搭建后端Server服務(wù)。

編寫后端Server代碼。

設(shè)計Server底層數(shù)據(jù)存儲架構(gòu)。

關(guān)注Server的高可用、可擴展、負(fù)載均衡、高性能等諸多繁瑣問題。

這些事情可能會耗掉你80%以上的時間和精力，結(jié)果服務(wù)可用性、穩(wěn)定性、可擴展性等都可能不盡人意。

我們還認(rèn)為，你應(yīng)該把更多的精力聚焦在業(yè)務(wù)和App開發(fā)上面，這樣不僅節(jié)約了時間和金錢，更重要的是你能把所有精力都放在業(yè)務(wù)本身上面，讓你的應(yīng)用在競爭中脫穎而出，領(lǐng)先競爭對手。

簡單來講就是針對App開發(fā)者提供的統(tǒng)一的后端對象數(shù)據(jù)存儲服務(wù)，讓用戶不再關(guān)心Server端數(shù)據(jù)存儲的問題，CloudData具有關(guān)系型、半結(jié)構(gòu)化、json格式及單個對象具有事務(wù)性等特點，采用MongoDB 3作為存儲系統(tǒng)，至于CloudData更多細(xì)節(jié)請參考MaxLeap CloudData相關(guān)文檔。

CloudData架構(gòu)非常的簡單，從上往下看，包括API Server、數(shù)據(jù)訪問邏輯處理層和底層數(shù)據(jù)存儲層，下面，我們分別介紹三個模塊的具體實現(xiàn)原理。

在Api Server層面，我們的語言采用的是java，針對java，當(dāng)前比較流行的方式可能是：選擇一個web 框架，可能是spring mvc，使用java servlet，然后選擇一款 java web 容器，可能是tomcat或者jetty等，但我們并沒有采用這樣方式，因為，在我們看來，這種方式有幾個缺點：架構(gòu)顯得有些笨拙，每次啟動都需要部署到j(luò)ava web 容器中，不夠輕量、同步通信，并發(fā)上不去，性能較低。因此，通過綜合考量，我們選擇了vert.x web框架，vert.x 基于事件驅(qū)動、非阻塞通信機制，這意味著，只需要很少的線程就能應(yīng)付大量的并發(fā)，同時它也更加的輕量，擁有更高的性能，啟動vert.x web服務(wù)只需要幾十毫秒到幾百毫秒之間，使用也是異常的簡單，只要你稍稍懂一點http協(xié)議及網(wǎng)絡(luò)編程幾乎可以說是零學(xué)習(xí)成本：

HttpServer server = vertx.createHttpServer();
Router router = Router.router(vertx);

router.route("/index").handler(routingContext -> {
  HttpServerResponse response = routingContext.response();
  response.putHeader("content-type", "text/plain");
  // Write to the response and end it
  response.end("Hello World Maxleap!");
});

server.requestHandler(router::accept).listen(10086);

需要注意的是，vert.x web基于EventLoop單線程模式，所以，在寫web服務(wù)的時候，不能寫同步處理邏輯，否則會阻塞主線程，導(dǎo)致其他請求不能得到響應(yīng)；另外，有異步編程經(jīng)驗的同學(xué)一定感受到這樣的痛苦：callback方法泛濫成災(zāi)，大量的flatMap方法調(diào)用導(dǎo)致也導(dǎo)致代碼的可讀性差，除此之外，我們實在是找不到vert.x web框架的任何缺點。當(dāng)然，這些缺點也并不是不可以避免，基于此，我們對vert.x web，稍稍加了一點東西，改變了一些實現(xiàn)策略：我們在邏輯處理階段將異步變成同步，在框架后面，我們在變成異步，并且增加了對JAX-RS 部分規(guī)范支持，如果之前你覺得，基于vert.x web寫rest接口還有一點點的學(xué)習(xí)成本，但現(xiàn)在基于我們改變之后的vert.x web寫rest接口，你會發(fā)現(xiàn)跟以前并沒有兩樣：

@GET
@Path(":className/:objectId")
public void get(RoutingContext context) {
  func(context, (ctx, cloudCode, appId, className, principal) -> {
    LASObject doc = lasDataEntityManager.get(appId, className, principal, new ObjectId(context.request().getParam("objectId")));
    if (doc == null) {
      ctx.response().end("{}");
    } else {
      ctx.response().end(MongoJsons.serialize(doc));
    }
  });
}

更多的Api Server相關(guān)細(xì)節(jié)請參考Maxleap的開源BaaS系統(tǒng)實現(xiàn) https://github.com/MaxLeap/MyBaaS

這一層包含了CloudData的核心邏輯實現(xiàn)，相對來講，是CloudData設(shè)計中最復(fù)雜的一層，當(dāng)然，僅僅只是相對，所有的邏輯處理都在這一層，而Pandora是其具體實現(xiàn)，所以，我們重點會講一講Pandora的設(shè)計思路

Pandora是古希臘神話中最美的女人，她充滿誘惑，攜帶危險來到人間，當(dāng)然，在我們看來，危險與誘惑跟美麗的女人無關(guān)，如果說美麗的人會讓你身處危險之中，那就請讓我萬劫不復(fù)吧。

扯遠(yuǎn)了，Pandora是Maxleap統(tǒng)一數(shù)據(jù)訪問層的實現(xiàn)，主要是針對mongo數(shù)據(jù)的操作，所以，不僅僅是用在CloudData中，在Maxleap中所有應(yīng)用中，需要訪問mongo數(shù)據(jù)庫的都是通過Pandora來進(jìn)行的,并且提供了異步和同步兩種接口

Pandora主要實現(xiàn)了兩種模式的數(shù)據(jù)訪問，CloudData和NativeData。

Clouddata是Maxleap App數(shù)據(jù)的訪問，凡是訪問應(yīng)用的數(shù)據(jù)，都是通過這個模塊，CloudData數(shù)據(jù)的訪問稍顯復(fù)雜一些，包含Pointer、Relation等自定義數(shù)據(jù)結(jié)構(gòu)的實現(xiàn)；數(shù)據(jù)ACL的實現(xiàn)；自定義操作指令如$relationTo等

NativeData是對mongo指令友好的封裝，與mongo原生指令并沒有兩樣。

Pandora最為核心的功能是實現(xiàn)了資源限制和數(shù)據(jù)庫訪問的路由策略，這對數(shù)據(jù)庫進(jìn)行平滑的動態(tài)擴展及遷移提供了可能性，當(dāng)然，目前Maxleap也實現(xiàn)了這一點，當(dāng)用戶的應(yīng)用因為數(shù)據(jù)量、訪問量上升需要升級后臺mongo數(shù)據(jù)庫的時候，這一切都是無感知的，不會影響你的線上服務(wù)照常運行，當(dāng)然，某些特殊情況下，可能需要短暫的停頓服務(wù)幾分鐘，并且僅僅是寫停頓，讀不受影響。

在Maxleap項目中，使用Pandora最大的好處是，開發(fā)人員無需關(guān)心后臺mongo的架構(gòu)，數(shù)據(jù)一致性、mongo服務(wù)升級降級等諸多繁瑣問題，當(dāng)然，你甚至連數(shù)據(jù)存儲在那個mongo集群都不要知道，因為，使用Pandora我實在想不到你還需要了解數(shù)據(jù)存儲在哪里的理由。

如果你對Baas有些許，如果你去Maxleap提供的服務(wù)有所了解，我想，你一定會關(guān)心Cloudapp后端數(shù)據(jù)存儲架構(gòu)是怎么設(shè)計的，成千過萬的應(yīng)用數(shù)據(jù)我們是怎么存儲的、你的應(yīng)用可用性問題、服務(wù)是否有足夠的保障，接下來，我們正要介紹這一點。

先看一下業(yè)界某BaaS服務(wù)的Clouddata的設(shè)計：

（圖片來自網(wǎng)絡(luò)）

在我們看來，這是一種糟糕的設(shè)計，如果我們沒有理解錯的話，所有的用戶數(shù)據(jù)都在一個大集群里面，后端是一個大的sharded集群，所有的用戶數(shù)據(jù)的訪問都會經(jīng)由一組mongos路由服務(wù)（毫無疑問，這絕對是一個風(fēng)險，試想，如果mongos出了問題，整改后端數(shù)據(jù)存儲就會down掉），當(dāng)然，這并不是主要問題，主要問題在于：

1、數(shù)據(jù)在一個龐大的集群中，出現(xiàn)問題的概率也會大很多，比如有10000個應(yīng)用，那么出現(xiàn)問題的概率也會大10000倍，1個應(yīng)用出現(xiàn)一次問題，那么整個服務(wù)都會因為某一個應(yīng)用出現(xiàn)問題而受到影響。

2、數(shù)據(jù)規(guī)模大了，運維困難，又如，如果mongo異常down掉，恢復(fù)時間絕對的是一個煎熬的過程，而這個時候，整個服務(wù)都不可用。

3、穩(wěn)定性較差，每一個應(yīng)用都有可能發(fā)送令人惡心的指令，可能會導(dǎo)致資源搶占（比如最常見的情況是沒有索引的查詢，會引起熱數(shù)據(jù)污染，結(jié)果集返回大量數(shù)據(jù)，搶占了網(wǎng)絡(luò)帶寬等），這個時候，整個集群都會受到影響，可能導(dǎo)致整個集群的吞吐量下降，反應(yīng)到應(yīng)用層面，可能就是大量應(yīng)用請求短時間超時，讀寫失敗

這是我們Maxleap其中的一臺產(chǎn)品Mongo Server所表現(xiàn)的性能，當(dāng)然，你可能會驚訝于數(shù)據(jù)在磁盤也能夠擁有4000/s的吞吐量，當(dāng)然，這一切得益于我們使用SSD硬盤所帶來的效果。這張圖也告訴我們，盡可能的小心你的查詢，當(dāng)服務(wù)器趨于吞吐平穩(wěn)的時候，不要造成內(nèi)存數(shù)據(jù)污染，但如果是所有的應(yīng)用在一個大集群，這種情況將不可避免，因為，你永遠(yuǎn)都不會知道用戶會寫怎樣的查詢指令，而一旦有這樣的指令，影響將會擴散到整個大集群其他的應(yīng)用。

4、效率低下，需要更多的硬件成本，比如，當(dāng)你的讀寫壓力變大的時候，你不得不加新的機器去copy集群的全量數(shù)據(jù)，造成磁盤和內(nèi)存的浪費，因為你應(yīng)用的熱數(shù)據(jù)在每一個mongo節(jié)點都有（當(dāng)然，為什么我列在第四點，可能你覺得這并不重要，硬件從來都不是問題，更重要的是，你覺得，公司從來都不缺這點錢）

好了，是時候看看我們的CloudData的設(shè)計了，當(dāng)然，也是極其的簡單，遵循3個原則：

1、用戶資源隔離（毫無疑問，這點是最重要的）

2、動態(tài)可無限擴展（不管你有多少個庫，1萬還是100萬）

3、分而治之

基于以上3點，我們的設(shè)計是為每一個應(yīng)用創(chuàng)建一個獨立mongo集群，是不是太簡單了，有木有，但是，我們認(rèn)為這是最科學(xué)的，將大集群按照應(yīng)用分解成小集群，大問題分解成小問題，以大化小，分而治之，不管在哪里，都是靠譜的，并且還特別有效，最近幾年，火的不要不要的被廣泛傳播的軟件架構(gòu)方式‘微服務(wù)’不也是同樣的道理么？當(dāng)然，你可以說，微服務(wù)更傾向于‘單一職責(zé)’原理，當(dāng)然，只要你高興，隨你怎么想。

也許，你可能會質(zhì)疑這是否會浪費資源，因為，每個人都會有這樣直觀上的錯覺，但是，事實上，不僅沒有浪費資源，還會大大的節(jié)約資源，這一點，在上面已經(jīng)討論到，數(shù)據(jù)在一個大集群中，副本集越多，浪費的內(nèi)存越多，磁盤越多。第二點，起一個mongo集群，并不會浪費多少內(nèi)存。

當(dāng)然更重要的是，我們并不是真正為每一個應(yīng)用創(chuàng)建一個mongo集群，畢竟，這樣做，很多時候并沒有意義，因為，90%的應(yīng)用可能并沒有較高的訪問量，50%的以上的應(yīng)用，可能從來都不會被頻繁訪問。

所以，我們的策略是，當(dāng)用戶第一次注冊Maxleap創(chuàng)建一個應(yīng)用的時候，用戶的數(shù)據(jù)放在一個默認(rèn)的集群中，在Maxleap中，這個集群叫User Default Cluster，當(dāng)你的用戶有一定的訪問量的時候（沒有訪問量也沒有關(guān)系，只要你是我們的付費用戶）我們會把你公司所有的應(yīng)用部署在一個多帶帶的mongo集群中，再往后，你應(yīng)用訪問量繼續(xù)上升，我們就把你的應(yīng)用在多帶帶升級到一個mongo集群，當(dāng)然，這一切的升級過程，都是平滑無縫的進(jìn)行的，沒有人能夠感知的到，包括我們自己。

So,我們Maxleap CloudData是這樣子的：

好了，關(guān)于Pandora及CloudData我們先簡單介紹到這里，更多的細(xì)節(jié)我們到時候會專門擰一個細(xì)節(jié)出來討論。

上面我們早已經(jīng)知道，我們使用的Mongo作為Clouddata作為主要存儲系統(tǒng)，更早之前，在我們mongo還在2.6之前，我們還使用了redis作為熱數(shù)據(jù)緩存，但后來我mongo升級到3.0之后，變?nèi)サ袅藃edis，所以，整個底層數(shù)據(jù)存儲，就只剩下mongo，整個系統(tǒng)設(shè)計又進(jìn)一步變得更加簡單，之所以去掉redis，這不是我們所要討論的重點，我們會在相關(guān)的文章中進(jìn)行詳細(xì)說明。

這里，我們重點介紹mongo的集群架構(gòu)設(shè)計方案

集群特點：

每一個mongo集群都是一個復(fù)制集：1主1從1投票節(jié)點，還有一個備份節(jié)點（Norns-backup是我們自主實現(xiàn)的一個增量實時備份系統(tǒng)）
每一個mongo集群都在一個VPC網(wǎng)絡(luò)里面
每一個mongo集群3個節(jié)點都在不同的可用區(qū)里面（不同的機房，機房是光纖直連，網(wǎng)絡(luò)延遲大概咋500us）
部分mongo集群的數(shù)據(jù)存儲在LVM上面
每一個mongo集群都使用SSD硬盤
每一個mongo集群我們都提供瞬時10倍以上的請求峰值

原文作者來自 MaxLeap 團隊 基礎(chǔ)服務(wù)及架構(gòu)組成員：趙靜  
關(guān)于MaxLeap
MaxLeap移動云服務(wù)平臺為企業(yè)提供一站式的移動研發(fā)和運營云服務(wù)，幫助企業(yè)快速研發(fā)和上線移動應(yīng)用，平臺提供數(shù)據(jù)云存儲，云引擎，支付管理，IM，數(shù)據(jù)分析和營銷自動化等服務(wù)。
MaxLeap官網(wǎng)鏈接： https://maxleap.cn

如果您正在學(xué)習(xí)移動研發(fā)和云服務(wù)等方面的訊息，不妨關(guān)注我們的微信服務(wù)號MaxLeapSvc，我們將不定期推送相關(guān)干貨。敬請期待！