小程序云开发初探

tsunamiGG
301 阅读9分钟

概念与背景

传统开发与云开发有什么区别？ 类比于开零售店，传统开发就是：租店面，进货，卖出；云开发好比连锁店的加盟：租店面，选好服务商，从装修风格到产品体系都不用考虑，完事儿。

其中减少的部分在于：运营成本，用互联网词汇叫做运维成本。 例如：让老板肉疼的：买服务器，宽带流量CDN，数据库

存储，让工程师头疼的：冷备热备、弹性伸缩、负载均衡等等，都不需要考虑。

9102年也是云原生应用开始爆发的年代，谷歌公司早就涉足并推出过相关产品，手机上就可以玩LOL。这是一些题外话，感兴趣的可以自己关注一下。

小程序云开发，是短平快，无需下载，用完即走的微信应用和提供存储，数据库，云函数功能的云服务商腾讯云结合的一种新模式。

云函数

A. 广义云函数的特点：

  • 零运维：不再需要管理底层资源的服务器
  • 秒级部署：运行无状态，轻易实现快速迭代
  • 自动触发：完全由事件触发，空闲时没有资源在运行
  • 聚焦代码逻辑：开发者只关心最核心的代码片段，跳过复杂的、无聊的其他工作

B.微信云函数的构成：

  1. js逻辑代码
  2. 触发方式：定时触发、事件触发
  3. 配置项
    • 运行环境（目前只有NodeJs 8.9）
    • 资源配置（根据指定的内存分配计算资源，CPU按比例自动分配）
    • 超时时间（函数超过该时间仍未结束时，将会被强制中断，不能大于20s）
    • 环境变量（可以使用键/值对的形式定义可从函数代码访问的环境变量。增强云函数的可定制性）
  4. 相关支持
    • 测试（即时在线测试，构造Json参数，获取测试结果）
    • 日志（包含请求ID，返回结果，运行时间，占用内存）
    • 监控（可以查看云函数的调用次数、运行时间、错误次数）
    • 天然鉴权（login云函数直接返回openid，appid）
    • 服务端推送(模板消息)

C.云函数适用场景：

  • 事件驱动及响应式架构
  • 流量突发场景
  • 请求对延时要求不高
  • 低频请求
  • 单项任务资源要求低

业务聚焦

  1. 有什么坑点

    云开发方案怎么与传统后台配合？有什么使用上的痛点？

  2. 有什么优劣

    解决了什么问题，有什么限制？

  3. 推荐实践

    有哪些推荐实践？

云开发方案怎么与传统后台配合？

如果要混合使用云函数和后台，我们就必须得对业务进行更细粒度的划分，考虑那些业务上可以和传统的后台剥离开，完全独立出来。其实，数据是有互相关联性的，很多东西很难完全分开，一定会产生数据冗余。那些功能点采用云函数是合适的呢？

  • 功能页

    纵观现今的所有小程序，大部分都具有个人中心的功能页。这一类型的功能页展现的数据不外乎这三大类：用户基本信息（昵称，手机号，性别等）、用户业务信息（电商类的余额，卡券，积分，交易记录，评价信息等等；出行类的订单记录，卡券，客服消息，积分商城等等）、用户设置信息（清除缓存，隐私设置等等）

    结合前面云函数部分提到的云函数适用场景，个人中心的这些功能点，相较于其他业务逻辑来说。

    1. 请求频次较低，用户70%时间不会盯着个人中心看，而是程序的其他功能页。
    2. 单项任务资源要求低，个人中心的数据相对于主业务的复杂数据结构来讲，较简单，数据量较小。
    3. 个人中心的很多数据总是被动更新（也就是其他业务流变更之后，触发的个人中心更新）而不是个人中心的数据主动更新。个人中心就像订阅者一样，当发布者更新后，它就跟进更新相关信息。

    从这几点来看，个人中心的功能，是适合采用云函数的。稍微不同的地方是，要在其他业务功能点上写一些云函数来触发更新相关数据而不是传统的AJAX发请求给后台。

    如果能够避免数据库的数据上的关联性，在设计数据结构时使其能够使用多个数据库进行“分库”存储，减少数据上的关联性，那样采用云开发和后台配合是OK的，但那样会使得整个结构又变得复杂。

    由此可见，使用云开发是可行的，但前期工作需要做的更多，并且会有问题的不可预见性。探索新东西总是需要踩坑的~

  • 功能点

    一些小的功能点也是可以采用云函数来进行开发的。比如很多程序都带有的点赞功能，这个功能点是十分适合采用云函数进行开发。

    还有就是H5中一些搜索(某种输入或者其他什么动作后)的历史记录，我觉得这也可以采用云开发来作为一种备用方案。

    我只是举个栗子，抛砖引玉，还有很多功能点可以采用云开发，扬长避短。

解决了什么问题，有什么负担？

  • 本质

    前端调用wx原生api来操作数据库，腾讯云做背后的基础服务支撑。

  • 解决问题

    1. 传统开发的联调时间和责任界定问题

      传统数据交互方式： 前端 -> AJAX -> 后台 -> JSON -> 前端。所有数据有关的，服务器，数据库，存储都在后台。俗称：前后端分离。但这样存在的问题是，前后端联调时（前端想要这样的数据结构，后台觉得不好，两者都可以界定数据结构和数据内容）难免会有分歧，出问题后追责也会比较麻烦，可能出现互相泼脏水的情况。

    2. 运维成本

      在服务商提供的基础服务能力支撑下，使用云开发，不用考虑任何运维上面的事情，云服务商已经帮你全部做好了。

    3. 性能提升和天然鉴权

      a.使用云开发后，静态资源全部带上CDN，请求和返回也会被服务商优化，这些都会提升程序的数据在网络传输过程中的速度。

      b.login云函数会直接返回appid和openid，而不是传统的请求授权。整个过程不会与原有后台服务冲突。

      下面是调用login云函数获得的两个id。

      天然鉴权！= 没有鉴权，来看看背后的工作。

  • 增加负担和坑点

    1. 不可避免的学习成本，引入云开发的沟通成本，可能带来的部分数据冗余，些许开发效率的降低。

    2. 数据库的操作只能通过云函数，并且每次云函数的更新都需要手动点击上传，过程比较繁琐。

    3. 坑点和解决方案：

      a.基于Node的数据操作都是异步的，最好使用promise和async、await语法糖，而不是cb。

      b.权限结构仅有四种：

      仅创建者可写，所有人可读，仅创建者可读写，仅管理端可写，所有人可读，仅管理端可读写：该数据只有管理端可读写。详情点击

      简单的四种结构不能满足某些业务下所有需求，需要增加代码层面的控制。比如，在做一个书柜的项目时，希望书柜里的书可以设置可被第三方查看和不可被第三方查看，这时你只能将集合的数据设置为「仅创建者可写，所有人可读」，并通过代码来控制具体信息是否显示，比如加入一个 is_private 字段来进行控制。

  • 限制

    微信云开发依赖于腾讯云，这必然是一把双刃剑。好处是享受到了基础服务支持带来的福利，但也被第三方所限制。

    这些限制导致的最终结果就是小程序云开发：所有的业务逻辑都仅且只能在小程序端完成，不能做复杂的管理逻辑。（因为云函数、云数据库无法在小程序以外的区域调用，因此无法实现强大的 Web 管理界面）

    这其实于小程序本身用完即走的短平快应用理念是吻合的，但现实是很多商家为了节省成本，硬生生把带有复杂逻辑的系统塞进小程序.....

有哪些最佳实践？

  1. 腾讯相册小程序

    云开发+传统后台服务：云函数作为中间路由，然后将 appid, openid，转发给原有的服务。

    腾讯相册之前将评论功能接入了云开发，但一些敏感操作，像删除、编辑评论，这个请求发送到云函数，然后云函数会将用户信息转发给相册原本的后台，然后再将该用户是否有权限返回来告诉云函数，如果有权限，就在云函数里删除评论。

  2. 猫眼电影活动页

    云开发+传统后台服务： 也是对接了猫眼运营工具的后台服务，在小程序上读取相应配置进行活动页的配置。具体过程还是很复杂的，大厂的基础服务设施比较完善，很多东西不用从头开始写。

  3. 腾讯乘车码

总结

现阶段的云开发较适合于个人开发者来开发更轻量的小程序，如果业务逻辑复杂，还是建议与传统后台配置不采用云开发。或者用云函数来转发原有服务达到现有功能的小程序化。这几种方式是推荐的，当然，如果你能解决数据关联性的问题，云开发和传统服务一起用也没问题~

github催生了社会化编程，而云开发则是从SaaS进化到了Faas，让我们期待云开发模式会对未来的编码体验产生怎样的影响吧~

avatar
文章
阅读
粉丝