瘋狂使用 leancloud （投稿文章）

瘋狂使用 leancloud

本文章是投稿文章，已在 leancloud 微信公衆號發表。

這裏是原文，內容有調整。
3年，從工程師到創始人

以爲不錯能夠點這裏進行 leancloud 註冊

項目背景

介紹本身

我是 htoooth，一名愛折騰的工程師，目前在一家電商公司從事 nodejs 的開發工做。本身在技術方面喜歡追新語言，除了主力開發語言 javascript 外，還喜歡 golang，elixir，clojure。最近關注人工智能和 python。個人 blog 是 http://www.cnblogs.com/htoooth/，github 地址：https://github.com/htoooth，但願你們多多 star。

項目狀況

本身雖然平時也在工做，剩下的時間都作本身的創業項目——視網麼(最新網站正在建設中)。這個項目主要是作 AR 的互動營銷平臺，主力產品包括 AppSDK， App，CMS。AppSDK 是嵌入到客戶的 App 中使用的。App主要是給沒有 App 的客戶使用。 CMS 是生產和組織 AR 內容的一個工具，只有 Web 版。AppSDK 和 App 包括 Android 和 iOS。經過咱們的產品能夠很方便地將 AR 技術集成到客戶的業務中去。

我在本身的項目中，固然是主力工程師，主要負責 Android 的 AppSDK、Android 的 App 、移動端 API、CMS（先後端） 和 Website（先後端）。如今咱們的項目後端全都架在 leancloud 雲引擎之上，能夠說 leancloud 支撐了咱們的整個項目。

選擇 leancloud 的過程

咱們項目用 leancloud 能夠說比較早了。記得當時 leancloud 應該叫作 avoscloud。那時 2014 年，咱們幾個創始人要啓動項目，沒有沒有後端人員。剛好我經過這我的的博客(技術很牛逼)中瞭解到 avoscloud，他說到到 avoscloud 去發展了。我很好奇地去 avoscloud 看了看，發現 avoscloud 是美味書籤中國的一幫人作的，又看了一下 avoscloud 這個產品是咱們須要，便做爲候選方案。

記得那段時間，這類 baas 平臺還挺多的，咱們另外找了幾個平臺，和 avoscloud 對比了一下，發現 avoscloud 不管是從功能，文檔和 demo 都能知足咱們的需求，因而技術選型上就定下了，使用 avoscloud。在以後，avoscloud 發生了挺多的變化，包括更名成爲如今的 leancloud，收費計劃的改變等，還有服務不穩定的問題咱們也都經歷過。期間也看過其餘的平臺，綜合評價下來，仍是 leancloud 更勝一籌，並無改變咱們的技術選型。

從 2014 年到 2017 年，四年間開發了很多項目，都一直沒有換，能夠說咱們是 leancloud 的老用戶了。順便說下，更名這件事，我以爲不錯，更符合產品的定位。最近一年來，咱們本身的產品業務也有了客戶，對後臺業務要求系統穩定和技術支持，因而咱們在2016年的下半年，購買了 leancloud 付費版。

咱們如何使用 leancloud

咱們頂目在這四年中一直在 leancloud 上進行開發。項目開發平臺包括 Android，iOS 和 Web。使用 leancloud 的產品包括 AppSDK(Android，iOS)，JsSDK，雲函數，雲引擎，leancache, restApi，實時通訊，統計分析，雲存儲等。 並且每次 leacloud 出來的新功能，咱們也都會看看文檔瞭解一下，說不定何時就能夠用上。能夠說對 leancloud 服務咱們仍是瞭解一部分的。下面我將咱們使用 leancloud 服務開發項目的過程分爲三個階段來說述一下：

第一階段：業務都在 App

當時項目啓動時，因爲咱們沒有後端開發人員，整個團隊就只有三個全職外加三個實習生，開發能力有限， 就只開發 Android 的 App。 項目的方向是LBS的社交軟件，正好 leancloud 對聊天和 LBS 支持的很是好。App 就基於 leancloud 的 AppSDK 進行開發。當時就以爲基於 leancloud，咱們開發賬戶系統很是方便，leancloud 支持第三方，密碼和短信多種登陸方式，讓咱們能更加的關注於業務自己。咱們把全部的業務功能都寫在 App 裏面，至關於把 leancloud 做爲咱們的數據庫存儲。在後端沒有寫任何代碼，就把功能給完成了，當時以爲開發很方便。

第二階段：業務都在 leanengine

隨着第一階段的完後，咱們要進行 iOS 的版本的開發。這時就出現了問題：

1. 由於全部的業務都在 Android 中，iOS 必需要再寫一遍業務代碼;
2. 新功能新需求來了以後，要同時在 Android 和 iOS 進行實現；
3. 關鍵是業務出現了 bug，客戶端很差修改；

那時咱們就把業務代碼從 Android 中抽出來了，作成了移動端 API，這樣業務能在 Android 和 iOS 中共用。移動端API是在 leancloud 上基於 leanengine 開發。當時在 leancloud 上也只有 nodejs 的 sdk 比較成熟，咱們就選擇了 nodejs 作爲咱們的後端環境。除了移動端 API，咱們的 App 後臺也進行了開發工做，技術選型是 angularjs 和 leancloud 的 jsSDK 。 這樣一能夠對業務級的代碼複用。在這個過程當中，leanengine 和 nodejs 發揮了重要做用。

第三階段：抽象成計算單元，作成微服務的形式處理

又過了一段時間，咱們對產品和業務作了調整。新增幾個項目：

1. 咱們的產品線多出 AppSDK，要求須要嵌入到別人的 App 中，接口與咱們 App 獨立，有本身的用戶系統；
2. App 集成 本身的 SDK，用戶系統使用獨立的用戶系統，跟 AppSDK 的用戶系統不同；
3. 官網從原來的純靜態頁面變成了動態網頁，新增了多個欄目和博客，須要從數據庫中讀數據;
4. CMS 從 angular+jsSDK 變成了 vue+後端 api 的 SPA 應用，新增了素材管理等多個功能;

能夠看出咱們的　Web，SDK, App, SPA 的要求不同，對資源的需求也不同。因而咱們須要再一次調整咱們的項目架構。

在此次調整中，咱們改變了對 leancloud 的思惟方式，再也不認爲他是一個一個應用，而是把 leancloud 的一個應用拆開，把當作了一個計算單元和一個存儲單元的組合。這樣的分開意味着，咱們能夠單獨使用計算單元，也能夠單獨使用存儲單元，也能夠二者都使用，這樣在設架構時更靈活。咱們在規劃架構時，會對項目進行劃分，看看哪些是須要計算，哪些是須要存儲的，哪些是都須要的，這樣的好處是，更清晰了。壞處是，多使用了不少應用。

如今咱們的整個功能架構就變成了這樣：

首先，咱們整個應用體系如今使用四個 leancloud 應用，每一個應用承載的應用不同，對它的核心核心需求是不同的。爲了方便與手機app區分，咱們把 leancloud 應用叫作 cell。 當前的架構沒有作任何負載平衡的工做，所有都依靠 leancloud。

• cell1，作爲咱們整個應用的核心， 在上面部暑了cms ，cms api，mobile api，它的計算和存儲都相當重要，因此咱們買了收費版本；
• cell2，這個咱們是給 app 用的，他只有儲存用戶信息的功能，app 端還集成了 leancloud AppSDK，只用了登陸、註冊和第三方登陸的功能。同時 app 端還須要調用 sdk api；
• cell3，把作爲一個web服務器，數據從數據仍是從 cell1 中來，由於仍是要作 SEO 需求，因此沒有用 SPA 應用，而是相似的先後端分離，cell1 提供數據接口， cell3 進行模板渲染；
• cell4，把他當成了一個靜態資源服務器使用，用來存儲 css，js，圖片和視頻較大的文件；
• cell3，cell4 是官網使用的；

整個架構來看，cell1 是功能較多的點，數據也是相當重要的點，因此咱們須要保證穩定。cell2, cell3, cell4 均對穩定性沒有要求，並且請求量也不是很大，因此咱們仍是用的開發版。

這樣咱們就把咱們的應用分紅了重要和不重要的，重要的要重視，不重要的就簡單點。還有對應咱們的開發，測試和灰度環境，都是相同的設計思路。這樣算算，咱們平時用了8個 leancloud 應用。

將來的發展

咱們將來的計劃是使用量上來以後，會把 mobile api, cms api, cms 都分出去作一個單獨的應用，再作一個 ApiGateway 進行接口的管理工做，也就是將來可能咱們的應用會超過 10 個應用。這麼多應用的管理，若是用普通的方式進行管理，至少要三四我的，而如今咱們使用了 leancloud，只有用了一個兼職人員就能處理，感謝 leancloud 的幫助。

總結

leancloud 在基礎平臺和基礎應用上的功能點不是一篇文章就能說的完的，我只說了咱們使用部分。並且如今階段，咱們仍是一個創業團隊，不斷地試錯是咱們的本能，leancloud 爲咱們低成本的試錯提供了很好的支撐，我以爲對得起 「lean」 這個稱號。

期待的新功能

作爲工程師我期待 leancloud 能支持更多的功能：

1. 更多的語言開發，如 golang；
2. 監控接口的開放，如請求，cpu 等數據；
3. 運維接口的開放，如新建應用，加入應用等；
4. 應用集羣組網的能力，如多個應用變成一個集羣；
5. 開放更底層的功能，如網絡4層(tcp)功能；
6. 更加的智能，如人功智能(tensorflow, gpu)；
7. 更加方便的開發環境：IDE 的集成插件，命令行等
8. 更好的打包開發部署環境：如 oschina 的 gitee，leancloud, 七牛整合一體化方案，若是這樣會方便更多；

最後，但願 leancloud 愈來愈好。