导语 | 云计算的发展为互联产业带来了巨大的变革,云上技术的下一站,又会有哪些新契机呢?本文是腾讯高级生态产品经理高树磊在腾讯云开发者社区技术沙龙深圳站的分享整理,为大家详细介绍微团队利用物联网和云原生在大气监控领域究竟做出了哪些惊人成就。
点击视频查看完整沙龙回放
一、鹅民大气监测项目简介
大家好,我是来自腾讯云联合创新实验室的产品经理高树磊,联合创新实验室是腾讯云和我们的合作伙伴共建的平台,我们共同进行方案的设计认证,通过认证方案后续有会相关的政策扶持,以便提供更多更好的方案给到行业和客户。
我今天带来的主题是关注物联网的技术拓展空间。物联网技术现在已经比较成熟了,大的企业比如小米这几年成长得非常快。而我这边更多关注的是:小微企业究竟在物联网方向能做什么样的事情,以及能做出什么样的成绩?
在深圳这样大的产业环境下,很多物联网小企业人员非常少,可能只有四五个人,但是依托产业链的能力却可以交付上万个充电桩。这就是小团队的能力空间,也是我今天即将分享的方向。
在物联网和微团队之间如果加入了云能够做到什么事情?关于这个点,首先我们来看一个真实具体的案例。如下图所示,这个项目是腾讯内部发起的公益项目:鹅民大气监测项目,核心人员只有5个人,其他的都是相关的志愿者和参与者。5个人的团队是一个非常典型的微小团队,我们这样一个团队做成了什么事情呢?
关于这个项目的起源,先来看一组数据。如下图所示,这是2019年中国生态环境公报的摘要,2019年有337个城市进入了大气质量分析中,其中真正达标的城市数量只有46.6%,不到一半。在这些城市当中,如果按天数来计算的话,20%的时间是处在污染情况下的,并且PM2.5是主要污染物。
然后我们进一步,看一个真实的事件,今年年初3月份京津冀区域大气污染过程的分析,这个报告发布在中国生态环境部的官网,因为这次事件是短时重度污染,所以大家关注度比较高。
基于这些情况,生态环境部近期发布了文件:2020-2021秋冬季大气污染综合治理方案征求意见稿。第一部分覆盖了京津冀,第二部分覆盖了长三角。
那么长三角和京津冀都看完了,大家可能会比较关注珠三角是什么样子呢?我们来看一下深圳有什么样的相关信息可以提供给大家。
中国天气网是隶属于中国气象局的公共气象服务中心,从中国天气网发布的信息来看:深圳有11个监测点,每个监测点每小时会上报数据告诉大家上一个小时的空气质量是怎样的。这里我们可以算一笔账,深圳有2000平方公里,分为11个监测点,每小时同步一次,一共每天上报264次。
我们团队发现,如果有民众很关注空气质量,非常想了解空气对自身的影响,但是却没有办法拿到实时的数据。那么是否能利用云来快速实现这样的能力,帮助我们发现身边的空气事件呢?另外,中国天气网这个项目虽然符合国家标准,但是没有办法反映具体小区的环境情况,于是我们的项目机会就这样诞生了。
二、项目一期:原型
项目一期我们要做的是原型,做原型的时候需要关注两个点:第一个是快速实现;第二个是能力验证。这是小微企业面临的第一个风险,是否能用很短的时间、很小的成本来验证自己想做的方向或这个点是否能真的产生价值?
小微企业不像大企业,没办法频繁试错还可以活得很好,每一次投入都必须要有产出,如何快速验证就是关键点。原型期我们团队同样面临这样的问题,我们只有5个人,而且是利用自己业余的时间,所以我们决定先快速跑起来。
先来看一下我们的架构组成,如下图所示,主要分为三个部分:采集、处理和展示,它实现的效果是把监测到的数据传递到最终的用户。
我们分成了架构层和实现层。在采集这里,监测节点层是用腾讯云兼容硬件,软件用的是TencentOS Tiny,这是腾讯开源的物联网操作系统,成熟度比较高。监测节点拿到的数据通过接入网关层,然后传到平台接入层,也就是物联网开发平台IoT Explorer。到这里为止数据已经上云了,使用TencentOS Tiny很容易就能把你的数据传递上云。
上云以后进入到第二个环节,这也是很多物联网团队不太擅长的环节,就是如何在云上进行处理和深加工。在处理的过程有三个组成部分:使用腾讯云API网关帮我们做鉴权;通过云函数把数据写到数据库里;最后通过腾讯云图直接展示数据。
最开始的原型设计,我们投入了3个人,用了20人时就完成了整个系统从设计到上线。具体来说就是一个人干两天活基本上就干完了,这个成本是大多数的微团队能够承受的。一期的案例我们也已经把它放到腾讯云开发者社区上了,后续大家可以在腾讯云开发者社区上阅读相关文章看看是怎么操作和实现的。
大家可以看到,在架构设计当中,云产品基本贯穿了始终,但是在接入网关层面却没有云产品,这是为什么呢?这是因为我们使用了腾讯云Lora社区网络。
这个社区网络于2019年12月份发布,由开发者共建。如果你使用了Lora终端,只要你的设备在网络覆盖范围内,设备配置好并上电,数据就可以上报,这样开发部署的成本降低非常多。
那么我们一期的原型究竟做出的效果怎么样呢?如下图所示,我们使用了腾讯云图这个产品,用来展现系统的WEB界面图,上面包含了地图组件等各种信息。看起来也许比较复杂,但因为都是组件拖拽式,所以本身开发的成本非常低。配置5分钟,调试了大概15分钟基本就搞定了。
配套的是我们的一个终端,在做终端的时候为了降低成本,我们使用了现成的开发板。这里使用了TencentOS Tiny Nucleo Lora开发套件,因为本身的技术比较成熟,TencentOS Tiny跟开发板的适配性也很好,所以开发成本也并不高。到这里我们终端的原型和系统原型就做完了。
那么我们做的这个东西是不是真的有用呢?接下来来看一个具体的案例。如下图所示:这是今年4月3日,我们5个节点监测到的数据。大家可以看到每个节点的数据都是上升又下降,但是它们的时间点并不相同。
从我们节点分布来看,呈现了西侧先上升下降,东侧后上升下降的过程,于是我们就猜测:是否有一个移动的污染源进入了深圳?
为了验证这个猜想我们做了几个动作:第一步就是去看中国气象局的数据。虽然它是按每小时发布的,但是可以看到数据指标是上升的,说明这个事件是真实存在的。
紧接着再看其他地区的情况,这里我们并没有找到一个官方的带地图的数据,而是使用了第三方的数据,来源是AQICN,是一个总部在北京的全球化组织,向全球的使用者提供大气质量监测的具体数据和情况。
从这里也看到呈现了明显的西高东低的情况,符合扩散的基本原则要求,这和我们的监测数据基本一致。接着我们分析了地形,污染气团可以从很多方向过来,为什么结果是自西向东,而不是自南向北或者其他情况呢?
最后发现,原来是深圳附近的山太多了,如果污染源真的是自西向东来的话,被山阻隔以后只有一个通道,就是通过珠江通道而来。但我们的数据源比较少,所以说这只是一个猜测,并不是绝对准确的信息。
但到此为止已经可以发现:我们的监测数据真的产生了效果!为什么?因为我们每15秒就会上报一个信息,这个频率能够帮我们发现这个趋势,发现一个正在移动的污染气团,这证明了我们的原型是有价值的。
同样的事件不只发生一次,如下图所示,这是今年2月2日的另一个案例。这个案例持续的时间比较长,总共10个小时,分为2个波段,也可以看到明显的上升下降的动作。
到此为止,我们的原型基本达到设计之初所要的效果,接下来我们要做的事情就是把覆盖面扩大,点数增加,提供更多的数据,做更深度的分析。
三、项目二期:拓展
二期的主要目标是拓展,具体包括两个部分:一个是规模运营,一个是数据容灾。
如上图所示,架构这里我们有几个动作,首先我们把中间件层的网关放到了核心环节,所有的东西都要经过它,核心是为了保护我们的数据库。毕竟云图对数据库带来的压力是不可控的,而经过中间件的API网关和中间件,可以保证我们系统的健壮性。
第二部分是我们增加了两个环节,在原有数据库的基础上先是增加了一个对象存储做备份,另外又增加了一个异地数据库帮我们做异地容灾和备份。这样的好处是主数据库用来做实时的查询和入库,从数据库做长时间的大数据量的分析,这样就避免了压力导致数据库崩溃。
为什么要这样做呢?主要是因为我们这个团队太穷了,我们没有钱,只能买最便宜的数据库,再通过架构的方式去优化它。如果大家的团队资金可行的话,云数据库可以有多种选型:单机、双机高可用、三机三地容灾,都可以选用。
二期的架构和逻辑,包括源码,我们都已经开放出来了,大家也可以到腾讯云开发者社区查看相关的帖子,其中包含源码链接,看看我们具体是怎么实现的。
二期阶段我们的节点从5个变成27个,覆盖度有了较高的增长。另外我们优化了终端,如下图所示,第二期的终端我们用的是TencentOS Tiny的RISC-V开发板。这个板很小,大概只有一张信用卡大,同时我们自己设计了转接板,大大提高了它的集成度。终端可以放到最小的气象百叶窗里,这样的话它的部署难度也大大降低了。
关于二期的数据量,我们总结了三个数据:5、100、20000000。
- 5代表着我们团队只有5个人;
- 100指的是我们运营近一年,总投入的开发维护时间是100人时。
- 2000万是我们的数据积累量,我们已经积累了2000万条记录。
为什么这么快?主要是因为云的开发成本非常低。另外我们也没有用到任何运维人员,因为云的产品比较稳定,只要架构上的承载能力可行就能长期稳定运行。我们甚至可以做到一两个月都不用看运行的监控数据,只看真正展示出来的功能数据就可以了。
这个系统上线10个月已经积累的2000万条数据,对我们非常珍贵,因为数据有实时性和稳固性的基础,这2000万的数据量就可以更进一步来分析,就能够开发出更多的应用。
四、项目三期:开放
三期我们关注的是开放,主要分为两个部分,一个是管控体系,另一个是生态建设。
三期的架构更复杂一点,首先我们加入了消息队列,然后配套的加入了云日志服务。消息队列 日志服务达到的效果就是:我们不再是单链路的消息传播,因为有了消息队列,我们有了多个通路,这就达到了数据对账。另外有了消息队列和日志服务,这样整个系统的管控日志也完成了。
接着我们就开始强化用户侧输出的应用能力,基于腾讯云开发和腾讯连连。因为我们关注到,现在很多情况下大家是更喜欢用手机的,并不是每个人都随身带着电脑,那么怎么样让大家随时看到这个数据呢?小程序是一个很好的切入点,于是就引入了云开发和腾讯连连小程序。
腾讯连连是物联网开发平台IoT Explorer自己配套的产品,而云开发具备更多的空间,可以做更复杂的事情,它们的使用维度是不一样的。
同时为了生态,我们提供了一个新的出口,那就是实验数据。后续我们希望把数据开放出来,让大家能够拿到这些数据,并且用这些数据做自己想做的应用。
总的来看,三期阶段我们的计划是完善管控,开放实验数据,我们希望这个系统是越来越稳定的,并且数据可以开放出来。第二步是开源架构,开放实验生态,架构我们也希望把它拿给更多的人看,因为这个架构不仅仅可以用于大气监测,很多其他的应用都可以做。
其它类的应用我们腾讯云伙伴已经开始在做了,其中一个案例就是消防类的监控,让消防设备通过物联网上云,就可以实时知道每个节点当前是活跃还是故障,对于保障消防安全具有很重要的意义。
接下来再谈一谈大家非常关注的问题:项目成本。微团队的成本,除了人力就是资源消耗,4个人的团队花十几二十万验证一个项目,一定是不可行的。
如上图所示,表格上的数据来自于我们真实的运营结果,这里包含了终端硬件部分,也包含云端服务部分,每一部分的价格和消耗都列在上面。当然由于大家购买的硬件不同,所以具体成本上可能会有差异。
云端部分成本相对明确,我们这个项目大量使用了腾讯的云原生相关的产品,比如云函数、API网关,这些产品是按量付费的,它可以帮助大家极大降低实验过程中所产生的成本。举个例子,如果1万个节点需要每分钟上报一次,利用我们二期的架构,每个节点一年成本是2块多钱,而到了三期这里的成本可以降到1块钱一下。
我们现在准备做的动作主要分为三个部分。第一部分是开源,我们把源码提供给大家,大家可以尝试自己的项目。
第二部分是架构,整个系统的搭建和逻辑,我们已写成文章放到腾讯云开发者社区,大家可以参考。
第三个是生态,在生态这个环节,我们项目内部发生过一次讨论。因为我们团队太小了,微团队还是要聚焦自己核心的能力,而我们最核心的能力就是架构,而不是应用。
所以我们选择开放数据,让更多的人用我们的数据做自己想要的应用。源码因为尚不成熟,我们先提供了部分的开源代码,后续更新的源码也会陆续放出。我们提供架构和数据,大家可以提供自己需求来设计,让我们一起来看看这个事情还能做成什么样子。
五、微团队项目开发经验
微团队能力是没有问题的,如何选对方向、如何做对事情是有几个要素的,我们也进行了相关的总结。
1. 项目选型
项目选型关注的是产品要素,也就是价值。主要看用户、市场,和同业,这里为什么没有写竞品呢?因为我们不是盈利性的项目,更多是为了传播技术理念,想跟大家交流,所以用的词是同业。
用户能证明你的东西是否真的有价值,人家是否真的需要你的产品。市场是决定有多少人用,有多少人愿意关注。同业是同行业里其他的产品,它们能够佐证你的这个产品价值的深度在哪里。
大家现在能够拿到的每小时,甚至每秒钟的实时数据就是我们提供的价值。这三个要素综合起来就决定了我们当时立项的重点,最后我们决定把人力、时间和资源投入到这个项目当中来,所以这个项目才会真正启动。
2. 风险管理
接下来是风险管理,也就是技术要素。这里需要关注的两个字就是“生存”,微团队最大的问题就是:不可能停下来完全做一个理想的事情。怎么在自己已有工作不受影响的情况下能够做新的尝试和探索呢?
答案就在于质量、效率和成本。质量代表你的功能,你的功能要有价值,这个产品才会有价值,如果你的功能根本达不到要求,就算投入1块钱也是损耗。
第二个是效率,代表着你究竟能够多快地解决这个问题。一个小团队如果花了3个月才能做出一个东西,那么这个小团队就会面临很严峻的生存问题。
第三个是成本,就是如何低成本做事情,我们这里是一个公益性的项目,也不打算挣钱,控制成本就是我们非常关注的点。而对于一些真正商业性质的微团队,你的成本越低则后续的收益就会越大。
这三个点结合起来就决定了我们的原型要通过云原生来做,最后效果也是达到了我们的预期:人数少、时间短、成本低。
3. 持续运营
最后是持续运营,也就是成长。这里也有三个词要分享:时机、渠道和伙伴。
时机指的就是事件运营,很多东西即使你知道它是对的,但是当用户没有设身处地的感觉的时候是没有办法感同身受的。所以我们的项目运营时间基本放在秋冬季,大家可以很明确感受到空气是好还是坏,关注点就会不一样。
第二个是渠道,也就是从哪里传播运营出去。大家知道微团队重要的是利用产业链的生态和能力,而不是仅仅做好自己,如何让更多人看到你是非常重要的点。
第三个是伙伴,指的是你生态链上的合作者,他们决定了你的整体交付能力和空间。结合实际,渠道和伙伴,最后我们的项目团队选择了和腾讯云开发者社区合作,我们在社区上面开设专栏、阅读清单,发布我们每一期的文章,让大家看到我们正在做什么,以及把我们的能力提供出去。
通过腾讯云开发者社区这个平台很多人知道了我们的项目,目前无论是消防类的项目,还是智能IoT硬件的项目很多也都是从腾讯云开发者社区带过来的。所以渠道和伙伴对微团队非常重要,大家看到你,你就可以闪光。
念念不忘必有回响,不忘初心方得始终。微团队做事情还是要给行业和客户带来价值。如何让自己更快、更便宜、更直接地产生价值就是我们微团队始终关注的点。
最后放出一些合作的空间和入口,首先是我的本职工作的联合创新实验室,如果大家想成为腾讯云的合作伙伴,并且和腾讯云共同共建方案的话可以联系我们,这里有一个调研单的入口,大家可以填相关信息,后续会有相关人员回复大家。
第二个是社区共建,也就是腾讯云开发者社区。微团队最重要的是让大家看到你,希望大家在腾讯云开发者社区上发表更多的文章,和不同的人、不同的团队有更多的交流。
第三个是TencentOS Tiny交流群,TencentOS Tiny的价值非常大,它帮你把上云的通路都打通了,如果想做IoT , TencentOS Tiny是第一个点。在这个交流群里有官方的同学答疑和回复,大家可以加群和我们一起讨论。
六、Q&A
Q:我的问题是关于钱的,刚才在您的介绍里面看到,在第三期的项目当中,整个成本比第一期和第二期有很大的下降,这是怎么做到的?
A:我们的产品数量没有变少,复杂度变高了,为什么反而便宜了呢?大家可以参考我们的三期架构图,逻辑层是我们的核心,我们的开发都在这里,观察这张图你会发现:我们将API网关挪到了后端,而不是前端。
API网关有一个非常强大的能力就是限流、鉴权。我们是每15秒上传一个节点,产生2000万条数据,那么就会产生2000万次调用,但是会产生2000万次查看吗?显然不会,这里真正的调用其实只有几十上百万,这其中的差异就是可以省下来的钱,所以我们把API网关挪到了后端,而前端是消息队列。
这里我们没有取消API网关,是因为这个产品的鉴权与流控能力,对于系统的安全至关重要,并且自建接口的安全管理,面临很多专业的安全要素,很难平衡安全和效率。所以开放的接口,作为承受攻击和异常的第一个节点,安全稳定是第一位的,于是我们将API网关放在下游接口前,保驾护航。
整体来看,成本由固定成本与可变成本组成,物联网产品的可变成本要尽量低,如果可变成本很高的话,一上规模你就会花很多的钱。消息队列虽然成本台阶比较高,但是它是固定成本,消息队列在我们这个体系里可以承载至少20万以上的节点数,而20万以内花的钱都是固定的。经过计算:当体系容纳1600个节点的时候,二期和三期架构会产生成本的均衡点,而节点数超过1600,三期成本就一定是占优的。
Q:大气监控有很多设备,很多不需要联网也可以上报,我比较关心的是这些设备是怎样维护的?比如有些设备可能坏掉了,有些设备后续有新的产品出来,这些设备是怎么管理的?
A:首先不是不联网,只是不用自建网关,不需要自己建一个接入点。不同的开发板有不同的方案和逻辑,因为我们想做成开放的生态,所以我们希望大家并不需要购买我们指定的产品,你手里有什么改造一下就能用,这是最好的,这也是我们为什么开放源码的原因。
只要符合我们的接入逻辑,你自建一个设备也是完全能够接入的,这才是真正的低成本。如果每个厂家都要买你整套方案的话,这个成本就太高了,最好能用他们现成的东西来尝试我们的方案,这也是我们在生态上的考量。
关于故障的问题,我们的逻辑比较简单。我们有数据上报,还有看门狗,这是必须的两个东西,故障以后会及时重启。我们的运营数据会有推送,内部也会定期去看哪个节点下线了并及时跟小伙伴说。我们的项目是春节前后上线的,刚好有一个台风天,这里面一旦发生问题的话,我们会自己处理一下,后面有厂商的话他们也会提起一部分,但毕竟我们是公益性的,所以没有售后服务,大家是自发自愿来做。
Q:关于微团队的定位,我们团队做了一个智慧灯杆项目,有大气、智慧广播、wifi,请教一下微团队在局限性的情况下怎么赶上智慧城市的产品定位?
A:首先产品的目标是什么,产品的目标是要产生价值。你可以先定一个方向,就是你要判断一下,如果你不做这个产品,用户会损失什么;然后进一步看团队是否有积累,具备落地能力;最后根据市场和同业的情况来判断,你是否有持续的竞争力。这三个分析好以后,这个产品是不是要做就一目了然了。
讲师简介
高树磊
腾讯高级生态产品经理
高树磊,腾讯云高级生态产品经理,2015年加入腾讯,历任腾讯云基础产品经理及生态产品经理,拥有9项国家专利,现负责腾讯生态联合实验室建设及相关标准制定。