疯狂使用 leancloud

本文章是投稿文章，已在 leancloud 微信公众号发表。

这里是原文，内容有调整。

觉得不错可以

项目背景

介绍自己

我是 htoooth，一名爱折腾的工程师，目前在一家电商公司从事 nodejs 的开发工作。自己在技术方面喜欢追新语言，除了主力开发语言 javascript 外，还喜欢 golang，elixir，clojure。最近关注人工智能和 python。我的 blog 是，github 地址：，希望大家多多 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 的版本的开发。这时就出现了问题：

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

新功能新需求来了之后，要同时在 Android 和 iOS 进行实现；

关键是业务出现了 bug，客户端不好修改；

那时我们就把业务代码从 Android 中抽出来了，做成了移动端 API，这样业务能在 Android 和 iOS 中共用。移动端API是在 leancloud 上基于 leanengine 开发。当时在 leancloud 上也只有 nodejs 的 sdk 比较成熟，我们就选择了 nodejs 做为我们的后端环境。除了移动端 API，我们的 App 后台也进行了开发工作，技术选型是 angularjs 和 leancloud 的 jsSDK 。这样一可以对业务级的代码复用。在这个过程中，leanengine 和 nodejs 发挥了重要作用。

第三阶段：抽象成计算单元，做成微服务的形式处理

又过了一段时间，我们对产品和业务做了调整。新增几个项目：

我们的产品线多出 AppSDK，要求需要嵌入到别人的 App 中，接口与我们 App 独立，有自己的用户系统；

App 集成自己的 SDK，用户系统使用独立的用户系统，跟 AppSDK 的用户系统不一样；

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

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 的帮助。