3年，从工程师到创始人

【 玩转 LeanCloud 】开发者经验分享：

大家好，我是 htoooth，在一家电商公司做 Node.js 开发，爱折腾，喜欢追新语言，像 golang、elixir、clojure、人工智能和 python 都在我的关注之列。我有一个创业项目叫视网么，是个做 AR 的互动营销平台，客户使用我们的产品可以很方便地将 AR 技术集成到自己的业务中去。我们的产品覆盖了 iOS、Android 和 Web，目前项目全都架在 LeanCloud 的云引擎之上。

LeanCloud 更胜一筹

邂逅 LeanCloud 是在 2014 年。那时我们几个创始人正打算启动项目，但缺后端人员，恰好我从博客中了解到了 AVOSCloud（ 后改名为 LeanCloud ），了解下来感觉靠谱，就把它定为候选方案。当时像这样的 BaaS 平台还是挺多的，我们跟另外几家对比后发现 LeanCloud 无论是功能、文档，还是 demo 都比较满足我们的需求，于是就决定选它。四年来我们开发了不少项目，虽然也经历过 LeanCloud 服务不稳定的问题，但综合评价下来，LeanCloud 还是比其他平台更胜一筹，所以也一直没换。最近一年来，我们的产品也有了客户，对后台业务要求系统稳定和技术支持，于是我们在 2016 年下半年购买了 LeanCloud 付费版。顺便提下，我觉得 AVOSCloud 改名为 LeanCloud 很赞，更符合他们的产品定位。

由于项目需要，我们几乎把 LeanCloud 各种功能和服务都用了个遍，比如云引擎、云函数、云缓存、云存储、实时通信、统计分析、REST API、JavaScript / iOS / Android SDK 等等。每次他们推出新功能我们都会关注一下，说不定什么时候就能派上用场。下面我来聊聊具体的使用情况吧。

填补后端人员空缺，开发超省力

项目启动时我们没有后端开发人员，整个团队只有三个全职外加三个实习生，开发能力有限， 只能照顾到 Android 平台。项目的方向是具备 LBS 地理定位功能的社交软件，正好 LeanCloud 对聊天和地理定位支持得非常好；而且它还支持第三方登录、密码和短信多种登录方式，这让我们开发帐户系统方便了好多，我们能省出更多时间专注在业务本身的逻辑和代码上，然后数据都往云端一存，在没写任何后端代码的情况下就把产品功能给完成了，当时觉得开发真是太方便了有没有~。

云引擎实现多端共用一套代码

Android 平台搞定后，我们又来做 iOS 平台，于是就遇到了如下问题：

1. 因为所有的业务都在 Android 中，iOS 必须要再写一遍业务代码;

2. 新功能新需求来了之后，要分别在 Android 和 iOS 上实现；

3. 关键是业务出现了 bug，客户端上不好修改。

我们的方案是把业务代码从 Android 中抽出来了，做成了移动端 API，这样业务能在 Android 和 iOS 中共用，移动端 API 是基于 LeanCloud 的云引擎 Node.js 环境下开发的。除此以外，我们的后台管理系统使用了 Angular.js + LeanCloud JavaScript SDK，这样也实现了对业务级的代码复用。在这个过程中，云引擎和 Node.js 都发挥了重要作用。

应用资源按需调配，搭建微服务架构

又过了一段时间，我们对产品和业务做了调整：

1. 我们的产品线增加了 sdk，需要嵌入到客户的应用中，接口与我们自己的 app 保持独立，并且有自己的用户系统；

2. app 集成自己的 sdk，用户系统使用独立的用户系统，跟 sdk 的用户系统不一样；

3. 官网 web 从原来的纯静态页面变成了动态网页，新增了多个栏目和博客，需要从数据库中读数据；

4. 后台管理系统 cms 变为 Vue.js + LeanCloud JavaScript SDK 的 SPA 应用，新增了素材管理等多个功能。

可以看出我们对 sdk、app、cms 和 web 的业务需求都不一样，对资源的需求也不一样，于是我们需要再一次调整我们的项目架构——我们不再将每个应用看作是一个独立的整体，而是当成一个计算单元和一个存储单元的组合，这种分割意味着我们既可以单独使用计算单元，也可以单独使用存储单元，或者两者都使用，设计架构也就变得更加灵活了，这样做的好处是我们可以按项目划分出哪些需要计算，哪些需要存储，哪些二者都需要，资源分配比较明确，坏处是应用的数量增加了。

下图是我们调整后的功能架构：

LeanCloud 更胜一筹

我们整个的应用体系使用了 4 个 LeanCloud 应用，如上图所示，cell1、cell2、cell3 和 cell4。它们各有各的功能侧重点：

• cell1，是我们整个应用的核心， 上面部暑了cms、cms API、mobile API，它的计算和存储都至关重要；

  
  

• cell2，给 app 用的，只储存用户信息。app 端集成了 LeanCloud SDK，只用了登录、注册和第三方登录的功能，同时 app 端还需要调用 SDK API；

  
  

• cell3，web 服务器，数据源来自 cell1。因为还要做 SEO 需求，所以没有用 SPA 应用，而是类似的前后端分离，cell1 提供数据接口，cell3 进行模板渲染；

  
  

• cell4，用来做静态资源服务器，存储 css、js、图片或较大的视频文件；

  
  

• cell3 和 cell4 给官网使用。

由于 cell1 承载功能较多，上面的数据也至关重要，所以我们买了收费版本来保证稳定性。cell2、cell3、cell4 均对稳定性没有要求，而且请求量也不是很大，所以还用的是开发版。我们的开发、测试和灰度环境也都是按照业务的重要性来做出选择的。这样算来，我们通过 8 个 LeanCloud 应用的配合与协作来支撑我们项目的全部架构，而且我们没有做任何负载平衡的工作，全部都依靠 LeanCloud。

我们未来的计划是等使用量上来之后，会把 mobile API、cms API、cms 都分出去成为一个单独的应用，再做一个 ApiGateway 进行接口的管理工作，也就是未来可能我们的应用数量会超过 10 个。这么多应用，如果用传统方式来管理至少要三四个人，而用 LeanCloud 我们实际上只用一个兼职人员就能处理，真要感谢 LeanCloud 的帮助。

期待的新功能

1. SDK 增加更多语种，如 golang；

2. 开放如请求、CPU 等数据监控接口的；

3. 开放如新建应用、加入应用等运维接口；

4. 增加应用集群组网的能力，如多个应用变成一个集群；

5. 开放更底层的功能，如网络四层 TCP/IP 功能；

6. 支持机器学习和人功智能，如 tensorflow、gpu；

7. 提供更加高效的开发环境，如 IDE 的集成插件、命令行等；

8. 提供更好的打包开发部署环境，如 oschina 的 gitee、LeanCloud、七牛整合一体化方案（这样一来会方便好多）。

   
   

LeanCloud 在基础平台和基础应用上的功能点太多了，用一篇文章可说不完，总之对于一个创业团队来说，LeanCloud 为低成本开发提供了许多有利条件，我觉得对得起「lean」这个称号，最后祝愿 LeanCloud 发展得越来越好！

end

LeanCloud，领先的 BaaS 提供商，为移动开发提供强有力的后端支持。更多内容请关注「LeanCloud通讯」