摘要：扯遠了，是統一數據訪問層的實現，主要是針對數據的操作，所以，不僅僅是用在中，在中所有應用中，需要訪問數據庫的都是通過來進行的并且提供了異步和同步兩種接口主要實現了兩種模式的數據訪問，和。

任何一個App都需要一個Server，我們認為，移動開發者（或組織）不應該把精力放在這些事情上面：

搭建后端Server服務。

編寫后端Server代碼。

設計Server底層數據存儲架構。

關注Server的高可用、可擴展、負載均衡、高性能等諸多繁瑣問題。

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

我們還認為，你應該把更多的精力聚焦在業務和App開發上面，這樣不僅節約了時間和金錢，更重要的是你能把所有精力都放在業務本身上面，讓你的應用在競爭中脫穎而出，領先競爭對手。

簡單來講就是針對App開發者提供的統一的后端對象數據存儲服務，讓用戶不再關心Server端數據存儲的問題，CloudData具有關系型、半結構化、json格式及單個對象具有事務性等特點，采用MongoDB 3作為存儲系統，至于CloudData更多細節請參考MaxLeap CloudData相關文檔。

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

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

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服務的時候，不能寫同步處理邏輯，否則會阻塞主線程，導致其他請求不能得到響應；另外，有異步編程經驗的同學一定感受到這樣的痛苦：callback方法泛濫成災，大量的flatMap方法調用導致也導致代碼的可讀性差，除此之外，我們實在是找不到vert.x web框架的任何缺點。當然，這些缺點也并不是不可以避免，基于此，我們對vert.x web，稍稍加了一點東西，改變了一些實現策略：我們在邏輯處理階段將異步變成同步，在框架后面，我們在變成異步，并且增加了對JAX-RS 部分規范支持，如果之前你覺得，基于vert.x web寫rest接口還有一點點的學習成本，但現在基于我們改變之后的vert.x web寫rest接口，你會發現跟以前并沒有兩樣：

@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相關細節請參考Maxleap的開源BaaS系統實現 https://github.com/MaxLeap/MyBaaS

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

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

扯遠了，Pandora是Maxleap統一數據訪問層的實現，主要是針對mongo數據的操作，所以，不僅僅是用在CloudData中，在Maxleap中所有應用中，需要訪問mongo數據庫的都是通過Pandora來進行的,并且提供了異步和同步兩種接口

Pandora主要實現了兩種模式的數據訪問，CloudData和NativeData。

Clouddata是Maxleap App數據的訪問，凡是訪問應用的數據，都是通過這個模塊，CloudData數據的訪問稍顯復雜一些，包含Pointer、Relation等自定義數據結構的實現；數據ACL的實現；自定義操作指令如$relationTo等

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

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

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

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

先看一下業界某BaaS服務的Clouddata的設計：

（圖片來自網絡）

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

1、數據在一個龐大的集群中，出現問題的概率也會大很多，比如有10000個應用，那么出現問題的概率也會大10000倍，1個應用出現一次問題，那么整個服務都會因為某一個應用出現問題而受到影響。

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

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

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

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

好了，是時候看看我們的CloudData的設計了，當然，也是極其的簡單，遵循3個原則：

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

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

3、分而治之

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

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

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

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

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

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

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

這里，我們重點介紹mongo的集群架構設計方案

集群特點：

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

原文作者來自 MaxLeap 團隊 基礎服務及架構組成員：趙靜  
關于MaxLeap
MaxLeap移動云服務平臺為企業提供一站式的移動研發和運營云服務，幫助企業快速研發和上線移動應用，平臺提供數據云存儲，云引擎，支付管理，IM，數據分析和營銷自動化等服務。
MaxLeap官網鏈接： https://maxleap.cn

如果您正在學習移動研發和云服務等方面的訊息，不妨關注我們的微信服務號MaxLeapSvc，我們將不定期推送相關干貨。敬請期待！