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 平台,于是就遇到了如下问题:

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

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

clipboard.png

我们整个的应用体系使用了 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、七牛9.整合一体化方案(这样一来会方便好多)。

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

阅读 2.2k

推荐阅读
LeanCloud 官方专栏
用户专栏

LeanCloud(原 AVOS Cloud) 是针对移动应用的一站式云端服务,专注于为应用开发者提供工具和平台。提供...

4997 人关注
95 篇文章
专栏主页