分类
未分类

分布式架构设计篇(十二)-分布式事务总结篇

– 总述 –

​ 咱们前面分别对分布式事务的几个分支:XA、2PC、3PC、TCC、Saga、事务消息、最大努力事务进行的详细介绍。本篇作为分布式事务设计的收尾篇,讲对前面的内容查缺补漏和总结,最后对市面的一些开源框架做一些介绍。

– 查缺补漏 –

1. 补偿型事务

柔性事务分补偿型事务和通知型事务。但对补偿型事务没有进行详细介绍,那什么是补偿型事务呢,在Atomikos 公司Guy Pardon的论文《Business Activities》中有这样的描述:

​ 大致含义是,”补偿是一个独立的支持ACID特性的本地事务,用于在逻辑上取消了先前ACID交互的影响。对于一个长事务来说,基于补偿的方法可将事务资源锁定时间保持在最低程度,从而避免了事务资源长期占用等缺点。”。

2.TCC事务模型补充

咱们前面文章说了不推荐TCC,并且认为Seata的AT模式从理论上来说更像是Saga的变种,而非TCC的变种。目前有很多资料自行将TCC分了几个分支:

  • 通用型TCC:标准TCC模型实现,从业务服务需要提供Try、Confirm、Cancel
  • 补偿性TCC:子服务只需要提供 Do 和 Compensate 两个接口
  • 异步确保型TCC:主服务是可靠消息服务,而子服务则通过消息服务解耦,作为消息服务的消费端,异步地执行。可靠消息服务需要提供 Try、Confirm、Cancel 三个接口。Try 接口只负责持久化记录存储消息数据;Confirm 接口确认发送,这时才开始真正的投递消息;Cancel 接口取消发送,删除消息数据。

原始论文《Life beyond Distributed Transactions》和 Atomikos 官网上并没有类似的划分,这些划分其实是一些公司在内部实践中,自行提出的概念。但是并未找到比较大的公司进行背书。所以其实咱们从论文上去看:

  • 补偿性TCC并未提供Try接口,其实已经更接近Saga了,反而应该认为是Saga的变种。
  • 异步确保型 TCC中 子服务不需要提供try、confirm、cancel三个接口,称为TCC貌似也不合适,从本质上其实事务消息的一种可靠投递方式而已。

3. Saga 事务模型补充

咱们说过Saga设计必须遵循允许空补偿、保持幂等性、防止资源悬挂三个策略,但因为Saga事务不保证隔离性,在极端情况下可能由于脏写无法完成回滚操作。比如举一个极端的例子, 分布式事务内先给用户A充值, 然后给用户B扣减余额, 如果在给A用户充值成功, 在事务提交以前, A用户把余额消费掉了, 如果事务发生回滚, 这时则没有办法进行补偿了。这就是缺乏隔离性造成的典型的问题,所以新增一个隔离性保障策略,实践中一般的应对方法是:

  • 业务流程设计时遵循“宁可长款, 不可短款”的原则, 长款意思是客户少了钱机构多了钱, 以机构信誉可以给客户退款, 反之则是短款, 少的钱可能追不回来了。所以在业务流程设计上一定是先扣款。
  • 有些业务场景可以允许让业务最终成功, 在回滚不了的情况下可以继续重试完成后面的流程,所以要求Saga除了提供“回滚”能力还需要提供“向前”恢复上下文继续执行的能力, 让业务最终执行成功, 达到最终一致性的目的。

Saga 实现分两种,一种是Saga 状态机实现,一种是Saga AOP Proxy实现,但是前文缺少对比,补充如下:

​Saga 状态机实现,在关于参与者服务编排实现又有集中式和协同式两种分支,他们的对比详情如下:

4. TCC VS Saga

补偿型事务事务主要分TCC 和 Saga。咱们前文中说到Saga 没有Try行为,直接commit,所以会留下原始事务操作痕迹。TCC Cancel是完美补偿的Rollback,补偿操作会彻底清理之前的原始事务操作,用户是感知不到事务取消之前的状态信息的。最近回看文章时,发现比较多人对此有疑问,所以进行补充诠释下:

  • 从业务流程上说,TCC的Try行为是尝试阶段, Comfirm 和Cannel是确认/回滚。是两阶段的广义实现,在页面表现上可以使用定时回查结果,那么对客户的说就是完美补偿行为。而Saga直接commit,在业务流程上存在的客户感官上的脏读现象。
  • 在数据层面上来说,TCC利用了数据的中间态,Cannel针对中间台数据进行回滚,从而不存在数据污染问题;而Saga使用的是反向操作,存在数据变化记录影响,有数据污染嫌疑。

TCC 和Saga 的对比 补充一个适用场景的相关对比信息:

  • TCC 适用于执行时间确定且较短、对一致性要求比较高、数据隔离强的业务,比如支付场景。
  • Saga 适用于业务流程长、业务流程多的业务,在银行业金融机构使用广泛。比如互联网微贷、渠道整合场景
– 总结 –

​ 单数据库事务可以满足事务ACID 四个特性,提供强一致性保证,但在分布式事务要完全遵循 ACID 特性会比较困难。在互联网时代中,我们通常追求分布式系统的高可用和高吞吐,所以分布式事务一般选择最终一致性。

咱们把提供强一致性的事务称之为刚性事务,把提供最终一致性的事务称之为柔性事务。刚性事务可以完全满足 ACID 四个特性,柔性事务对事务的 ACID 特性的支持情况如下:

  • 原子性:完全支持。
  • 一致性:只提供最终一致性支持。
  • 隔离性:不完全保证,通常为了系统的吞吐和性能,会一定程度上放弃对隔离性的要求。
  • 持久性:完全支持。

在分布式系统中,CAP理论通常是指导思维,而BASE理论是CAP理论中的AP延申,是对 CAP 中的一致性和可用性进行一个权衡的结果,理论的核心思想就是:我们无法做到强一致,但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性。而柔性事务其实就是BASE理论的实践产物。

因为分布式事务难免会对系统造成一定的性能损耗,所以在互联网高可用和高吞吐的要求下。我们通常处理分布式事务的原则是:业务规避 > BASE柔性事务 > CP刚性事务。柔性事务通常推荐 同步Saga、异步事务消息;刚性事务推荐 XA实现。

​- 开源框架推荐 –

从结论上我们可以看出业务规避其实已经没有了分布式事务的必要性,因此如果实在无法业务规避或者规避成本更加昂贵下,我们必须有分布式事务来处理数据一致性问题。这时我们需要选择一个合适的分布式框架来处理事务。我对业界常见分布式事务做了一定比较,其实有大厂背景背书、经过大量生产实践、开源组件的只有华为的ServiceComb Saga、阿里的Seata、Apache Camel Saga。但是华为ServiceComb Saga和 Apache Camel Saga只提供了Saga实现,而阿里Seata提供了AT、Saga、XA(4月新出,不建议生产使用)。从广度上来说,其实Seata是占比较大的优势,我刚好对Seata又有比较深的研究,所以强烈推荐Seata

​- 作者介绍 –

孙玄

毕业于浙江大学,奈学教育创始人兼CEO,前转转公司技术委员会主席,前58集团技术委员会主席,前百度资深研发工程师,腾讯云TVP,阿里云MVP,在线直播大课《百万架构师》品牌创始人。

林淮川

毕业于西安交通大学;奈学教育《百万架构师训练营》讲师、企业级源码内源负责人,前大树金融高级架构师、技术委员会开创者、技术总监;前天阳宏业交易事业部技术主管;多年互联网金融行业(ToB)经验。

分类
未分类

从零到一,Serverless 平台在滴滴内部落地

本文整理自 ServerlessDay · China 大会 – 《从零到一,Serverless 平台在滴滴内部落地》分享,讲师滴滴弹性云平台负责人张健、滴滴资深前端开发工程师陈钦辉。滴滴 Serverless FT成员来自:滴滴基础平台部、车服技术部、金融事业部、普惠产品技术部。

为什么(前端)要推动建设 Serverless

  • 更快地创建一个服务且免运维:大量的 Nodejs 服务,创建服务,需要申请节点、申请机器,对接构建、部署、日志、监控,还要持续运维服。我们希望能更快创建一个服务并且免运维。
  • 更灵活的隔离能力:前端 BFF 接口聚合、微前端等业务场景,需要创建大量的接口服务,快速创建服务的同时,还希望可以以不同粒度灵活进行接口间的隔离。
  • 更低的成本:大量低峰期时间cpu/内存利用率很低,服务不再使用了,资源却仍然占用。

我们的方案

我们调研了业界的 Serverless 方案,最终决定了自己的方案:K8s + Knative + Istio 搭建应用级 Serverless。他的优势是:

  • 社区相对繁荣,未来充满希望。
  • 应用级 Serverless, 和传统通过 Docker 镜像开发,部署相近,现有服务迁移成本低。
  • 应用级 Serverless, 通过 Serverless。路由,可以灵活控制隔离的粒度。

通过 Serverless 升级研发模式

那有了 Severless 基础能力,如何通过他来升级我们的研发模式呢?

  • 我们提供 npm 包打通公司的基础能力,包括数据存储相关、通信相关
  • 上层封装层 各种框架的中间件
  • 再上层是面向业务领域的框架,express/koa/以及我们基于egg打造的degg框架,他一定程度上方便了从零到一创建一个公司内部标准的服务。现在我们称之为面向 Serverless 的高级模式,业务同学可以更专注于业务编码,简单、高效完成这么一个日常开发迭代的流程

Serverless 全局图 – 研发视角

从研发视角看下,整个 Serverless的全局,自上而下是:

  • 业务场景解决方案 ,基于 Serverless 平台,在Serverless-cli 插件规范下的场景解决方案
  • Serverless -cli 和 Vscode 插件,作为面向开发者的统一入口
  • 面向业务的研发层,开发IDE, 包括本地的、云端的
  • 两层网关,业务层网关到 Istio 打造的Serverless网关
  • Bass SDK,用来与后台基础能力通信
  • 运行在集群里的应用,包含三类
  • 右侧是Appication是传统服务
  • 左下是Runtime, Application, 他是将日常业务场景进行抽象,将不变的沉淀到Runtime里。
  • 业务工程里只有变的东西,云函数情况下就可以是上面这个Funciton
  • Nodejs 框架
  • 底层集群, K8s /Knative 集群

右侧:是业务服务环境,下面是常规的日志、监控、报警、性能分析的能力

左下侧:是Nodejs生态体系,包括业务框架、SDK、Nodejs性能分析平台

左上侧:是面向Serverless 研发体系的共享市场

在虚线框里,就是面向一个业务场景,基于 Serverless 能力打造的一个通用解决方案。

Serverless 流程图 – 研发视角

将上面 Serverless 全局图拆分,我们把它分成三部分,这三部分也是我们年初立项,多个团队合作做这件事的一个模块分工,分为底层、平台层,和面向业务的研发层。

在开发者使用过程中,他们的流程是这样的:

  • 上层不同场景的工程,使用统一的cli, 也可以通过Vscode插件可视化来完成整个开发流程,Vscode也调用cli能力
  • 然后由cli调用平台的能力,再由平台进行权限验证,调用下层通用构建、部署能力
  • 最后调用Serverless底层接口,将服务部署到KNative+K8s集群上

Serverless-cli 的定位

我们再来看下 Serverless-cli,  它的定位是,基于插件式命令行扩展框架。他包含如下3个核心能力:

  • 与Serverless平台联动,完成服务构建、部署等操作
  • 提供规范,灵活的命令扩展能力
  • 打造开发者生态,场景方案共享,并保持开发体验的一致性

serverless-cli 的设计

cli 设计包含核心模块、默认命令、webpack相关、配置规范、以及基于cli 框架上层打造的插件生态。

场景方案

场景方案 – FaaS(云函数)

第一个场景方案:云函数。函数即服务,用户快速编写一个函数接口,这里创建了两个接口, 每个接口暴露一个函数,入参为param 和 context, 通过 async 返回函数同步异步结果。这个场景的插件为 @didi/sls-cli-plugin-faas, 用户通过 package.json 中声明依赖即可。FaaS工程类型的优势,是简单高效,并且通过Serverless 路由可以灵活控制隔离粒度。

场景方案 – Sma(微应用)

第二个场景方案:微应用。

页面即服务,前后端代码一体化,service.js 里保留出两个接口 list 和 add, 此时可以在前端组件中,类似远程调用,直接调用这两个方法,如同本地函数一样。另外它的服务端代码上下文和 FaaS 保持一致。

场景方案 – Sma-light(微应用-轻量版)

因为是应用级Severless方案,服务部署过程还是需要经历构建代码、编译镜像、以及整个应用级的部署。故我们基于Runtime的设计,结合Nodejs热更新能力,来支持页面级发布能力,轻量微应用类型工程。它支持

  • 静态页面、接口
  • 动态页面、接口
  • 页面模板、中间件等抽象,打造该工程类型的物料生态

不同场景方案,一致开发体验

我们来感受下,不同场景下一致的开发体验,包括创建、构建、开发、部署等 执行dev 时会一件启动前端资源webpack服务,同时启动服务端runtime服务,打开导航页面。

另外部署,可以执行 sls deploy, 通过 cli 将服务、按场景先后,按流量分组部署到 Severless 平台。也可以通过 Vscode 插件可视化方式进行操作,进行部署、回滚。

云端开发

更进一步,我们提供了云端开发能力,来满足一些如云函数,这类轻量创建服务的方式,开发者可以通过平台创建函数、页面,完成开发、调试,上线,且它的开发体验与本地是完全环境一致,并且是复用的。

基于 Serverless 面向业务聚合

我们来看一个业务使用案例。

这是我们普惠的工作台,是一个面向运营,集合了多个业务线后台系统。这里的菜单栏是配置集成起来的,每个菜单项是一个独立的页面,目前我们还没有采用微前端的一些轻量的隔离方案,使用的是简单、有效的iframe来进行隔离的。每个页面即服务,由每个业务线团队里的每个同学,用他们熟悉的技术栈,通过的前面介绍的微应用解决方案,独立运维。

最后

最后,我们也在积极探索用 V8 Isolate 与我们现有应用级Serverless + Runtime设计结合,实现面向nodejs更轻量高效的Serverless 隔离方案。

One More Thing

3 秒你能做什么?喝一口水,看一封邮件,还是 —— 部署一个完整的 Serverless 应用?复制以下链接至 PC 浏览器访问:

china.serverless.com/express

3 秒极速部署,立即体验史上最快的 Serverless  HTTP 实战开发!

传送门:

  • GitHub: github.com/serverless
  • 官网:serverless.com
分类
未分类

QQ音乐Android客户端Web页面通用性能优化实践

QQ音乐 Android 客户端的 Web 页面日均 PV 达到千万量级,然而页面的打开耗时与 Native 页面相距甚远,需要系统性优化。本文将介绍 QQ 音乐 Android 客户端在进行 Web 页面通用性能优化过程中的问题、思路、方案和效果,并尝试对跨端场景的常见瓶颈和对策进行归纳。文章作者:关岳,QQ音乐客户端开发工程师。

一、问题与目标

作为一款注重于内容运营的应用程序,QQ 音乐 Android 客户端的 Web 页面日均 PV 达到千万量级,评论页、MV 页等核心页面均有 Web 页面参与,或完全由 Web 实现。

客户端内 Web 页面的打开耗时与 Native 页面相距甚远,需要系统性优化。然而,现有的前端和跨端优化方案,存在一定局限性。

1. 前端优化的局限

针对 Web 页面的耗时优化,在优化思路、方案、服务、工具链等方面都已经建设得非常详细。然而,在客户端内 Web 页面这一场景,纯前端优化存在以下两个局限:

  • 无法规避 WebView 初始化耗时
  • 受限于 WebView 生命周期范围

从客户端角度,除了思考优化 WebView 初始化耗时之外,还可以从 “扩展前端生命周期” 的角度出发,思考优化方案。

2. 跨端优化的局限

现有跨端优化方案,包括离线包、VasSonic 等,为了达到最好的优化效果,均需要前端终端共同参与改造。这导致存量页面的逻辑改造增加,对线上页面不够友好,引入额外的成本和风险。在前端开发资源不足时,这些优化的开展存在一定难度。

从减少前端开发工作量的角度来看,需要思考更具通用性、前端感知更小的优化方案。

3. 目标

基于本次优化的背景,本次优化提出以下两方面的目标:增强通用性、减少前端改造成本

二、指标设计

在展开优化思路和实施的同时,需要建立衡量优化效果的性能指标。

1. 客户端现有性能指标数据

接下来基于客户端内 Web 页面加载过程,描述客户端现有性能指标代表的时机。

(1)客户端 WebView 回调

基于 Android WebView 的过程监控回调和页面框架能力,可以实现的性能监控包括:

其中,onMainFrameFinished 取第一个非主请求 (HTML) 的资源被拦截的时机。对于绝大多数页面来说,此时已经完成主请求 (HTML) 的下载,并已经开始解析;可以粗略代表主请求流程结束。

(2)W3C Performance Timing

与客户端回调相比,W3C Performance Timing 提供了更细致的加载过程信息,但是不包含 WebView 开始初始化的时间点。下图中仅列出部分:

2. 各端单独采集的局限

(1)前端采集的局限

  • 无法独立获取 WebView 开始初始化的时间点。
  • 想获取最精确的加载完成时间点,主要依赖手动埋点。

(2)客户端采集的局限

SSR (服务端渲染) 和 CSR (客户端渲染),页面内容可消费的时间点不一致

对 WebView 页面加载周期来说:

  • CSR 页面需在前端页面框架加载后再展示数据,内容请求完成并上屏,发生在页面加载完成之后
  • SSR 页面的首次内容上屏可携带首屏数据,因此在页面加载完成之前,页面内容已经可以被消费

客户端回调时机不够完整或过于“苛刻”,测不准“页面内容可消费”的时间点

通过追溯客户端 onPageFinished 的回调时机,发现对应的 Blink 代码要求必须满足:页面解析完毕、 没有正在下载的资源等条件。

按照这个标准,一旦存在某个图片一直处在加载中,但页面框架的其他内容均已处理完毕,onPageFinished 回调也会等待图片加载完成才回调,与实际上的 “页面内容可消费” 时间点存在差异。

3. 指标设计方案

结合上述分析,可以确定:

  • 最准确的页面加载完成时机来自前端
  • 最准确的 WebView 初始化时机来自客户端

因此,完善的耗时测量需由客户端和前端协同完成。

(1)前端侧

前端自行完成结束时间点的设置,并从客户端获取 WebView 初始化时间点,统计上报打开耗时。

  • 前端通过手动埋点或监听 DOM 节点数变更,获取加载完成时间点。
  • 前端统计时调用客户端提供 JSAPI,获取以 WebView 初始化时间点作为起点的耗时。
  • 并由前端完成加载耗时的计算和统计上报。

(2)客户端侧

作为一个补充方案,客户端可以通过 JavaScript 注入获取上述 W3C Performance Timing 中的 domInteractive 时间点,作为结束时间点。

  • 前端 domInteractive 时,已完成所有页面展示必需资源的请求和处理
  • 耗时的差异,可以体现任何页面的客户端通用优化效果
  • 可以衡量SSR(服务端渲染) 页面的可消费耗时,和CSR(客户端渲染)页面的首帧耗时

webView.evaluateJavascript(     script = “(function(){return performance.timing.domInteractive;})();”,       callback = { value ->          responseEndDuration = value.toLong() - getOnCreateTimestamp() } )

虽然 WebKit 负责维护 Performance Timing 的值,但是 WebView 并未提供接口获取上述时间点的值。

三、优化方案和效果

1. 优化方案概述

基于客户端内 Web 页面的加载流程,从 “WebView 初始化耗时优化”、“资源加载耗时优化”、“逻辑处理耗时优化” 三个方面,提出了 5 个优化项。

  • TBS (X5 内核) 环境预加载
  • WebView 实例池
  • 主请求并行加载
  • Web 公共资源池
  • 跟肤逻辑优化

各优化项在 Web 页面加载过程中的生效时机如下:

2. 优化手段说明

(1)WebView 初始化

经过前期分析,WebView 初始化耗时本身的耗时压缩空间比较有限。因此优化手段主要以初始化逻辑前置为主。例如,“WebView 实例池” 通过在应用位于后台、主线程卡顿影响不明显的时机进行 WebView 预初始化,置换启动 Web 页面时的初始化耗时。

(2)客户端自建缓存

为了实现前述各项资源加载优化,客户端需要独立于 WebView 的缓存机制,自建一个资源缓存。

自建缓存参考客户端常用的三级缓存机制,基于 WebView 的强生命周期,设计了 “冷-热缓存循环” 的缓存生命周期。

例如,在 WebView 初始化的同时,自建缓存把页面需要的资源从文件系统加载到内存;向 WebView 资源拦截回调输入字节流时,自建缓存一定从内存缓存中输出,输出完毕后即可立即从内存缓存中被清除。这一机制可以使内存缓存的淘汰更积极,字节流在内存中停留的时间更短,减少内存占用。

(3)公共资源内联

在完成公共资源池开发后,页面打开耗时出现了负优化的情况。经过分析,确定与资源拦截回调的性能瓶颈有关。

  • 单线程模型导致读写性能下降
  • 被拦截资源的数量越多,对性能的影响越容易被放大

因此,为了减少资源拦截回调的性能影响,从减少拦截次数的角度,引入了公共资源内联优化。

  • 公共资源加载到热缓存后,转换为对应的 HTML 节点
  • 主请求并行加载完成后,直接在主请求字节流中替换其对应的外联节点;替换后的新字节流返回 WebView

引入公共资源内联后,基本抵消了资源拦截回调的性能影响,页面加载耗时提升 3.2%。

3. 优化效果

QQ 音乐 Android 端内评论页:

  • 加载耗时降低 26.2% (1932ms → 1426ms)
  • 跳出率降低 
  • 停留时长中位数增加

四、跨端场景的瓶颈与对策

基于在 WebView 场景下的优化过程,推及跨端场景可能存在的类似问题,本文尝试给出一些跨端场景中可能的性能瓶颈及应对方式。

1. 前终端通信通道效能不足,考虑 “少次多量”

跨平台方案 (WebView、React Native 等) 普遍存在前终端通信通道效能不足的问题。

  • WebView 通道不支持较大量级数据的传递
  • 通信线程多为单线程,甚至需要在主线程发起或处理通信
  • 对传递次数的敏感程度大于对传递数据总量的敏感程度

因此,当在跨端场景出现大数据量传递时,需要优先考虑当前通信通道的可用性。在需要传递数据总量无法压缩的情况下,如果通道允许,尽量减少传递次数,增加单次传递的数据量。

“公共资源内联” 即是这一思路的实践。

2. 扩展生命周期

前端生命周期有限。客户端可以利用在前端生命周期以外的时间,进行适当的资源前置和逻辑前置,降低页面加载耗时。

例如上述优化中的 “公共资源池”、“主请求并行加载” 等,体现了扩展生命周期的思想。除此之外,微信小程序的双线程模型[1]通过引入 JSCore,增加前端代码的可执行时长,并通过离线包等手段帮助前端扩展生命周期。

3. 精简 / 前置公共库代码

如果前端页面共用公共库,随着前端业务的复杂化,公共库的自然膨胀,可能会放大脚本解析与执行的耗时。

针对 Web 页面,可以通过精简基础库的方式,减少无关代码的执行;针对 React Native 页面,可以通过进行分包和实例预加载,让更多基础库代码在页面加载前执行,从而降低页面启动时执行的代码量,减少耗时。

五、总结与展望

本文基于客户端内 Web 页面的加载特点,针对 WebView 初始化、资源加载和逻辑处理现状中的问题和瓶颈,设计并实施了 5 个优化项,优化效果比较明显。并且尝试对跨端场景的瓶颈与对策进行归纳,尝试为后续跨端场景的优化工作提供思路。

未来,团队还将进一步丰富客户端与前端的协同性能监控,并允许前端通过更精细化的方式启动客户端 Web 页面框架。远期,还将尝试探索 CGI 前置、引入 JSCore 等手段,进一步提升特定场景下的 Web 页面加载耗时。

分类
未分类

云开发 X 涂鸦:当小程序遇见物联网IoT,几行代码搞定智能插座控制

在 5G 热潮的推动下,与其紧密结合的物联网(IoT)正日益成为个人和企业工作生活中的重要组成部分,它为企业和个人带来了操作流程的改进和更好的生活体验,随着人工智能(AI)技术的日趋成熟,IoT 与 AI 的结合愈发紧密,IoT 也被赋予了越来越多的能力和价值。

另一方面,小程序提供的蓝牙 BLE、Wi-Fi、iBeacon、NFC 等接口能力、“即开即用”和低门槛等优势,能帮助 IoT 开发者提高设备配网率、使用频次和实现设备分享功能,这让小程序参与到 IoT 流程中成为可能,在此基础之上,通过与云开发这一新的开发模式的整合,能让物联网开发更加的简单、易用。

由此,全球化“AI+IoT”平台涂鸦智能结合云开发,推出 Tuya-Weapp-CloudBase SDK,其包含涂鸦云平台的鉴权、接口分发,可以帮助开发者省去服务端的开发,也省去了“云-云”对接的步骤。通过 Tuya-Weapp-CloudBase SDK + 云开发,您可以灵活简便的开发出自有品牌的小程序,轻松实现对 Powered by Tuya 设备的控制与管理。

云开发是什么

云开发(Tencent CloudBase,TCB)是腾讯云提供的云原生一体化开发环境和工具平台,为开发者提供高可用、自动弹性扩缩的后端云服务,包含计算、存储、托管等serverless化能力,可用于云端一体化开发多种端应用(小程序,公众号,Web 应用,Flutter 客户端等),帮助开发者统一构建和管理后端服务和云资源,避免了应用开发过程中繁琐的服务器搭建及运维,开发者可以专注于业务逻辑的实现,开发门槛更低,效率更高。

产品文档:https://cloud.tencent.com/product/tcb

技术文档:https://cloudbase.net

让物联网开发更简单

基于 Tuya-weapp-cloudbase SDK,开发者可以通过简单的几行代码,就完成针对 IoT 设备的操作、设备的管理、数据的推送等十余种场景,让开发者开发小程序,变得更加简单。

img

使用攻略

一、获取 Tuya-Weapp-CloudBase SDK 授权

  1. 登录 涂鸦 IoT 工作台
  2. 点击 APP 工作台,选择 小程序 SDK
  3. 点击 创建小程序
img

4.输入小程序名称(和你的小程序同名)、小程序 AppID(可在微信小程序后台查看)、小程序描述、小程序 Icon,点击 确定。

img

创建成功之后,可以获取到专属于你应用的 Schema,AccessID,AppSecret。其中 Schema 用来标识一个你的应用(在这里就是表示你的小程序),而 AccessID 和 AppSecret 用来生成 token 信息。

二、启动示例项目

接下来,我们通过示例项目来体验 Tuya-Weapp-CloudBase SDK

1.代码准备

克隆项目代码

git clone https://github.com/TuyaInc/tuya-miniapp-demo.git

安装相关依赖

npm install

开启自动打包

npm run dev:weapp

2.小程序接入

启动微信开发工具,点击 导入项目,导入你的项目,如下图所示:

img

选择项目目录,填写你的 AppID,点击 导入,如下图所示:

img

小程序导入之后,会自动进入小程序的设备列表页,如果看到 “网络错误” 的信息提示,表明项目导入成功,但是未能上传云函数(上传云函数可以理解成就是将云函数部署在腾讯云的 Serverless 服务器上),可以参考下一步来上传云函数。

img

三、 上传云函数

初始化项目结束后,接下来需要上传云函数,从而实现对涂鸦云的访问。

  1. 点击上方的云开发按钮,开通云开发环境
  2. 在小程序开发者工具中选中云函数目录的 ty-service(该目录是我们的涂鸦云函数目录,主要是登录、token 生成、统一接口调用等功能的封装) 上传上去。如下图所示: img
  3. 项目中调用云函数的工具方法在 src/Utils/Request.ts 中,通过云函数调用涂鸦的 Open API 的方式可以参照下面的示例:
const params = {   
    name: 'ty-service', // 云函数名称
    data: {      
      action: 'hello', // 涂鸦云接口名      
      params: {} // 接口参数    
      }  
   }  
   // 调用 Request   
   return Request(params)

四、 腾讯云云开发配置

云开发配置主要是为了配置你之前获得的的 Schema,AccessID,AppSecret,用于在云函数云端生成 token 并提供给小程序使用。这些信息存储在云开发的数据库中,可以保证云函数能够方便调用的同时还能最大限度的保证信息安全。可以根据下面的示例来操作

  1. 点击 云开发,进入 数据库,添加名称为 “iot-collection” 的集合,点击 确定。如下图所示:img
  2. 选择 “iot-collection” 集合,,选择项目目录 db/data.json 文件,点击 导入 按钮,即可导入相关字段。如下图所示:img
  3. 导入完成之后填写涂鸦 IoT 工作台上的 SchemaAccessIDAppSecret 的内容。如下图所示:img
  4. 配置完成之后,刷新一下小程序,可以看到一个 “欢迎使用涂鸦云小程序云函数”,说明云函数配置成功。如下图所示:img

五、设备配网

目前小程序支持 AP 模式(慢闪热点)配网,后期还将支持蓝牙配网。通过配网,可以将一个设备配到你的账号下,你就有权限控制这个设备。

配网操作的流程如下:

  1. 点击微信小程序开发工具的 预览,在弹出的二维码使用微信去扫码。
  2. 在手机的小程序中点击 添加设备 按钮,进入配网页面,如下图所示:img
  3. 将设备重置到 AP 配网模式,可以参照下面的视频来操作

视频地址:https://images.tuyacn.com/rms-static/3c093900-a414-11ea-96f0-cda03b175b6c-1591021740176.mp4?tyName=13014c80-a407-11ea-9d30-317d0567c96b-1591016087880.mp4

4.设备重置 AP 配网模式后,开始在小程序上配网,可以参照下面的视频来操作

视频地址:https://images.tuyacn.com/rms-static/f38382f0-a407-11ea-96f0-cda03b175b6c-1591016464543.MP4?tyName=6833349112827573083.MP4

img

总结

基于涂鸦开发平台和小程序 SDK,可以快速实现一款智能小程序,如果你手头有涂鸦的三明治开发套件,也可以用它搭建一个产品原型来实现最后一个步骤。心动了没有?赶紧来试试吧!

what’s more

此外,云开发的支持能力还有taro、Chameleon 开发框架等,想了解云开发更多 SDK 能力,点击此处查看:https://cloudbase.net/sdk.html?from=10004

参考文献

如果你希望获取更多关于 Tuya-Weapp-CloudBase SDK 的说明和调用信息,可以访问文档查看