瘋狂使用 leancloud

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

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

項目背景

介紹自己

我是 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 越來越好。

瘋狂使用 leancloud （投稿文章）