标签：javascrip baas 社交软件 建设 sdk 后台 库存 选型 个人
本文章是投稿文章，已在 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 应该叫做 avoscloud。那时 2014 年，我们几个创始人要启动项目，没有没有后端人员。恰好我通过这个人的博客(技术很牛逼)中了解到 avoscloud，他说到到 avoscloud 去发展了。我很好奇地去 avoscloud 看了看，发现 avoscloud 是美味书签中国的一帮人做的，又看了一下 avoscloud 这个产品是我们需要，便作为候选方案。
记得那段时间，这类 baas 平台还挺多的，我们另外找了几个平台，和 avoscloud 对比了一下，发现 avoscloud 无论是从功能，文档和 demo 都能满足我们的需求，于是技术选型上就定下了，使用 avoscloud。在之后，avoscloud 发生了挺多的变化，包括改名成为现在的 leancloud，收费计划的改变等，还有服务不稳定的问题我们也都经历过。期间也看过其他的平台，综合评价下来，还是 leancloud 更胜一筹，并没有改变我们的技术选型。
从 2014 年到 2017 年，四年间开发了不少项目，都一直没有换，可以说我们是 leancloud 的老用户了。顺便说下，改名这件事，我觉得不错，更符合产品的定位。最近一年来，我们自己的产品业务也有了客户，对后台业务要求系统稳定和技术支持，于是我们在2016年的下半年，购买了 leancloud 付费版。
我们顶目在这四年中一直在 leancloud 上进行开发。项目开发平台包括 Android，iOS 和 Web。使用 leancloud 的产品包括 AppSDK(Android，iOS)，JsSDK，云函数，云引擎，leancache, restApi，实时通信，统计分析，云存储等。 而且每次 leacloud 出来的新功能，我们也都会看看文档了解一下，说不定什么时候就可以用上。可以说对 leancloud 服务我们还是了解一部分的。下面我将我们使用 leancloud 服务开发项目的过程分为三个阶段来讲述一下：
当时项目启动时，由于我们没有后端开发人员，整个团队就只有三个全职外加三个实习生，开发能力有限， 就只开发 Android 的 App。 项目的方向是LBS的社交软件，正好 leancloud 对聊天和 LBS 支持的非常好。App 就基于 leancloud 的 AppSDK 进行开发。当时就觉得基于 leancloud，我们开发帐户系统非常方便，leancloud 支持第三方，密码和短信多种登录方式，让我们能更加的关注于业务本身。我们把所有的业务功能都写在 App 里面，相当于把 leancloud 作为我们的数据库存储。在后端没有写任何代码，就把功能给完成了，当时觉得开发很方便。
随着第一阶段的完后，我们要进行 iOS 的版本的开发。这时就出现了问题：
那时我们就把业务代码从 Android 中抽出来了，做成了移动端 API，这样业务能在 Android 和 iOS 中共用。移动端API是在 leancloud 上基于 leanengine 开发。当时在 leancloud 上也只有 nodejs 的 sdk 比较成熟，我们就选择了 nodejs 做为我们的后端环境。除了移动端 API，我们的 App 后台也进行了开发工作，技术选型是 angularjs 和 leancloud 的 jsSDK 。 这样一可以对业务级的代码复用。在这个过程中，leanengine 和 nodejs 发挥了重要作用。
又过了一段时间，我们对产品和业务做了调整。新增几个项目：
可以看出我们的 Web，SDK, App, SPA 的要求不一样，对资源的需求也不一样。于是我们需要再一次调整我们的项目架构。
在这次调整中，我们改变了对 leancloud 的思维方式，不再认为他是一个一个应用，而是把 leancloud 的一个应用拆开，把看成了一个计算单元和一个存储单元的组合。这样的分开意味着，我们可以单独使用计算单元，也可以单独使用存储单元，也可以两者都使用，这样在设架构时更灵活。我们在规划架构时，会对项目进行划分，看看哪些是需要计算，哪些是需要存储的，哪些是都需要的，这样的好处是，更清晰了。坏处是，多使用了很多应用。
现在我们的整个功能架构就变成了这样：
首先，我们整个应用体系现在使用四个 leancloud 应用，每个应用承载的应用不一样，对它的核心核心需求是不一样的。为了方便与手机app区分，我们把 leancloud 应用叫做 cell。 当前的架构没有做任何负载平衡的工作，全部都依靠 leancloud。
整个架构来看，cell1 是功能较多的点，数据也是至关重要的点，所以我们需要保证稳定。cell2, cell3, cell4 均对稳定性没有要求，而且请求量也不是很大，所以我们还是用的开发版。
这样我们就把我们的应用分成了重要和不重要的，重要的要重视，不重要的就简单点。还有对应我们的开发，测试和灰度环境，都是相同的设计思路。这样算算，我们平时用了8个 leancloud 应用。
我们未来的计划是使用量上来之后，会把 mobile api, cms api, cms 都分出去做一个单独的应用，再做一个 ApiGateway 进行接口的管理工作，也就是未来可能我们的应用会超过 10 个应用。这么多应用的管理，如果用普通的方式进行管理，至少要三四个人，而现在我们使用了 leancloud，只有用了一个兼职人员就能处理，感谢 leancloud 的帮助。
leancloud 在基础平台和基础应用上的功能点不是一篇文章就能说的完的，我只说了我们使用部分。而且现在阶段，我们还是一个创业团队，不断地试错是我们的本能，leancloud 为我们低成本的试错提供了很好的支撑，我觉得对得起 “lean” 这个称号。
做为工程师我期待 leancloud 能支持更多的功能：
最后，希望 leancloud 越来越好。
标签：javascrip baas 社交软件 建设 sdk 后台 库存 选型 个人
原文地址：http://www.cnblogs.com/htoooth/p/7754622.html
