摘要：我們的產(chǎn)品覆蓋了和，目前項目全都架在的云引擎之上。我們的方案是把業(yè)務代碼從中抽出來了，做成了移動端，這樣業(yè)務能在和中共用，移動端是基于的云引擎環(huán)境下開發(fā)的。在這個過程中，云引擎和都發(fā)揮了重要作用。

【玩轉 LeanCloud 】活動開發(fā)經(jīng)驗分享：

作者：黃濤

大家好，我是 htoooth，在一家電商公司做 Node.js 開發(fā)，愛折騰，喜歡追新語言，像 golang、elixir、clojure、人工智能和 python 都在我的關注之列。我有一個創(chuàng)業(yè)項目叫視網(wǎng)么，是個做 AR 的互動營銷平臺，客戶使用我們的產(chǎn)品可以很方便地將 AR 技術集成到自己的業(yè)務中去。我們的產(chǎn)品覆蓋了 iOS、Android 和 Web，目前項目全都架在 LeanCloud 的云引擎之上。

邂逅 LeanCloud 是在 2014 年。那時我們幾個創(chuàng)始人正打算啟動項目，但缺后端人員，恰好我從博客中了解到了 AVOSCloud（后改名為 LeanCloud），了解下來感覺靠譜，就把它定為候選方案。當時像這樣的 BaaS 平臺還是挺多的，我們跟另外幾家對比后發(fā)現(xiàn) LeanCloud 無論是功能、文檔，還是 demo 都比較滿足我們的需求，于是就決定選它。四年來我們開發(fā)了不少項目，雖然也經(jīng)歷過 LeanCloud 服務不穩(wěn)定的問題，但綜合評價下來，LeanCloud 還是比其他平臺更勝一籌，所以也一直沒換。最近一年來，我們的產(chǎn)品也有了客戶，對后臺業(yè)務要求系統(tǒng)穩(wěn)定和技術支持，于是我們在 2016 年下半年購買了 LeanCloud 付費版。順便提下，我覺得 AVOSCloud 改名為 LeanCloud 很贊，更符合他們的產(chǎn)品定位。

由于項目需要，我們幾乎把 LeanCloud 各種功能和服務都用了個遍，比如云引擎、云函數(shù)、云緩存、云存儲、實時通信、統(tǒng)計分析、REST API、JavaScript / iOS / Android SDK 等等。每次他們推出新功能我們都會關注一下，說不定什么時候就能派上用場。下面我來聊聊具體的使用情況吧。

項目啟動時我們沒有后端開發(fā)人員，整個團隊只有三個全職外加三個實習生，開發(fā)能力有限， 只能照顧到 Android 平臺。項目的方向是具備 LBS 地理定位功能的社交軟件，正好 LeanCloud 對聊天和地理定位支持得非常好；而且它還支持第三方登錄、密碼和短信多種登錄方式，這讓我們開發(fā)帳戶系統(tǒng)方便了好多，我們能省出更多時間專注在業(yè)務本身的邏輯和代碼上，然后數(shù)據(jù)都往云端一存，在沒寫任何后端代碼的情況下就把產(chǎn)品功能給完成了，當時覺得開發(fā)真是太方便了有沒有~。

Android 平臺搞定后，我們又來做 iOS 平臺，于是就遇到了如下問題：

因為所有的業(yè)務都在 Android 中，iOS 必須要再寫一遍業(yè)務代碼;

新功能新需求來了之后，要分別在 Android 和 iOS 上實現(xiàn)；

關鍵是業(yè)務出現(xiàn)了 bug，客戶端上不好修改。

我們的方案是把業(yè)務代碼從 Android 中抽出來了，做成了移動端 API，這樣業(yè)務能在 Android 和 iOS 中共用，移動端 API 是基于 LeanCloud 的云引擎 Node.js 環(huán)境下開發(fā)的。除此以外，我們的后臺管理系統(tǒng)使用了 Angular.js + LeanCloud JavaScript SDK，這樣也實現(xiàn)了對業(yè)務級的代碼復用。在這個過程中，云引擎和 Node.js 都發(fā)揮了重要作用。

又過了一段時間，我們對產(chǎn)品和業(yè)務做了調整：

我們的產(chǎn)品線增加了 sdk，需要嵌入到客戶的應用中，接口與我們自己的 app 保持獨立，并且有自己的用戶系統(tǒng)；

app 集成自己的 SDK，用戶系統(tǒng)使用獨立的用戶系統(tǒng)，跟 sdk 的用戶系統(tǒng)不一樣；

官網(wǎng) web 從原來的純靜態(tài)頁面變成了動態(tài)網(wǎng)頁，新增了多個欄目和博客，需要從數(shù)據(jù)庫中讀數(shù)據(jù)；

后臺管理系統(tǒng) cms 變?yōu)?Vue.js + LeanCloud JavaScript SDK 的 SPA 應用，新增了素材管理等多個功能。

可以看出我們對 sdk、app、cms 和 web 的業(yè)務需求都不一樣，對資源的需求也不一樣，于是我們需要再一次調整我們的項目架構——我們不再將每個應用看作是一個獨立的整體，而是當成一個計算單元和一個存儲單元的組合，這種分割意味著我們既可以多帶帶使用計算單元，也可以多帶帶使用存儲單元，或者兩者都使用，設計架構也就變得更加靈活了，這樣做的好處是我們可以按項目劃分出哪些需要計算，哪些需要存儲，哪些二者都需要，資源分配比較明確，壞處是應用的數(shù)量增加了。

下圖是我們調整后的功能架構：

我們整個的應用體系使用了 4 個 LeanCloud 應用，如上圖所示，cell1、cell2、cell3 和 cell4。它們各有各的功能側重點：

cell1，是我們整個應用的核心， 上面部暑了cms、cms API、mobile API，它的計算和存儲都至關重要；

cell2，給 app 用的，只儲存用戶信息。app 端集成了 LeanCloud SDK，只用了登錄、注冊和第三方登錄的功能，同時 app 端還需要調用 SDK API；

cell3，web 服務器，數(shù)據(jù)源來自 cell1。因為還要做 SEO 需求，所以沒有用 SPA 應用，而是類似的前后端分離，cell1 提供數(shù)據(jù)接口，cell3 進行模板渲染；

cell4，用來做靜態(tài)資源服務器，存儲 css、js、圖片或較大的視頻文件；

cell3 和 cell4 給官網(wǎng)使用。

由于 cell1 承載功能較多，上面的數(shù)據(jù)也至關重要，所以我們買了收費版本來保證穩(wěn)定性。cell2、cell3、cell4 均對穩(wěn)定性沒有要求，而且請求量也不是很大，所以還用的是開發(fā)版。我們的開發(fā)、測試和灰度環(huán)境也都是按照業(yè)務的重要性來做出選擇的。這樣算來，我們通過 8 個 LeanCloud 應用的配合與協(xié)作來支撐我們項目的全部架構，而且我們沒有做任何負載平衡的工作，全部都依靠 LeanCloud。

我們未來的計劃是等使用量上來之后，會把 mobile API、cms API、cms 都分出去成為一個多帶帶的應用，再做一個 ApiGateway 進行接口的管理工作，也就是未來可能我們的應用數(shù)量會超過 10 個。這么多應用，如果用傳統(tǒng)方式來管理至少要三四個人，而用 LeanCloud 我們實際上只用一個兼職人員就能處理，真要感謝 LeanCloud 的幫助。

1.SDK 增加更多語種，如 golang；
2.開放如請求、CPU 等數(shù)據(jù)監(jiān)控接口的；
3.開放如新建應用、加入應用等運維接口；
4.增加應用集群組網(wǎng)的能力，如多個應用變成一個集群；
5.開放更底層的功能，如網(wǎng)絡四層 TCP/IP 功能；
6.支持機器學習和人功智能，如 tensorflow、gpu；
7.提供更加高效的開發(fā)環(huán)境，如 IDE 的集成插件、命令行等；
8.提供更好的打包開發(fā)部署環(huán)境，如 oschina 的 gitee、LeanCloud、七牛9.整合一體化方案（這樣一來會方便好多）。

LeanCloud 在基礎平臺和基礎應用上的功能點太多了，用一篇文章可說不完，總之對于一個創(chuàng)業(yè)團隊來說，LeanCloud 為低成本開發(fā)提供了許多有利條件，我覺得對得起「lean」這個稱號，最后祝愿 LeanCloud 發(fā)展得越來越好！