3 年，从工程师到创始人

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

爱意满满的作品展示区。

这是一个创建于 2580 天前的主题，其中的信息可能已经有所发展或是发生改变。

[玩转 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 平台，于是就遇到了如下问题：

因为所有的业务都在 Android 中，iOS 必须要再写一遍业务代码;
新功能新需求来了之后，要分别在 Android 和 iOS 上实现；
关键是业务出现了 bug，客户端上不好修改。

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

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

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

我们的产品线增加了 sdk，需要嵌入到客户的应用中，接口与我们自己的 app 保持独立，并且有自己的用户系统； app 集成自己的 SDK，用户系统使用独立的用户系统，跟 sdk 的用户系统不一样；官网 web 从原来的纯静态页面变成了动态网页，新增了多个栏目和博客，需要从数据库中读数据；后台管理系统 cms 变为 Vue.js + LeanCloud JavaScript SDK 的 SPA 应用，新增了素材管理等多个功能。

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

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

架构图

我们整个的应用体系使用了 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 我们实际上只用一个兼职人员就能处理。