开发者学堂课程【云原生中间件产品销售红宝书:微消息队列 MQTT 销售指南】学习笔记,与课程紧密联系,让用户快速学习知识。
课程地址:https://developer.aliyun.com/learning/course/629/detail/9889
微消息队列 MQTT 销售指南
内容:
一、产品系列
二、经典客户案例
三、功能指南
四、架构实现
一、产品系列
1、互联网
消息队列 RocketMQ
阿里巴巴自主研发及双11交易核心链路消息产品,阿里云主打品牌,
主要面向业务消息处理,打造金融级高可靠消息服务;
全力开展 RocketMQ 开源战略,抢占开发者心智,成为开发者首选;
2、大数据
消息队列 Kafka
聚焦大数据生态链, 100%融合 Kafka 开源社区,大数据应用领域中不可或缺的消息产品;
3、移动互联网&物联网
微消息队列 MQTT
基于 MQTT 标准协议自研,拓展消息产品的领域与边界,延
伸到移动互联网以及物联网,实现端与云的连接;
4、拥抱开源
消息队列 AMQP
100%兼容AMQP事实标准协议.全面融合RabbitMQ开源社区生态;
5、消息通知服务(对标SNS)
消息服务 MNS
聚焦云产品生态集成&消息通知服务(HTTP Endpoint. FunctionComput事件通知、移动推送等) ;
阿里云消息产品家族从最早上线开始到现在已经有四五年的历史,期间也发展很多款产品,从最早的RocketMQ消息队列是阿里巴巴内部的电商的交易核心的消息产品,到现在大数据流计算里面的kafka产品或者是开源的amqp产品。
6、在消息领域的模型里面,比如电商或者是其他的公司业务,它在后台服务的场景里面用的都是RocketMQ产品,进行后台业务系统的连接,像大数据或者流计算之类的产品选kafka,都是给客户要搭后台业务用,用户的业务场景不只有后台业务,还会有端上的场景,比如做app肯定是既有后台也有前台,前台终端的场景产品,跟它云端后台的服务性通讯,matt的定位让端和云进行通讯,端上智能设备或者是手持的app,在应用市场里面各种下载的app,还有外围页面,h5页面的场景。
7、微消息队列MQTT
(1)微消息队列MQTT特点跟传统的后台服务不一样,最大的特点是端的场景规模比较大,装机量百万千万级的app很多,场景比较复杂有很多种场景,安卓都是的客户端平台,服务器场景现在主流的是linux或者是windows的服务器平台,单一,稳定,但是端上比较特殊。
(2)端(浏览器、Android、 iOS、智能设备、互动直播、传感器)与云的消息传输与双向通信。
(3)特点总结:第一点是分布式的语音服务,后台的容量是无限扩的,用户可以随时保证很大容量的负载,同时支持很多设备的同时在线,收发消息或者推送消息,也是毫秒级的服务指标,同时支持很多协议,包含标准的mqtt协议或者websocket的长链接的推送或者是物联网或者新能源的国标或者其他的特种协议,对于开发语言和平台上主要集中的是mqtt协议,所以它也支持多种语言,用户选择时不会因为某一种语言不支持,没法接入mqtt产品。另外特点是在产品家族里面它是其中一部分,内部产品的联动导致有很好的效应,端上的设备通过mqtt产品,连接进来时数据和消息家族的其他产品是天然互通的,也就是云和端的通信,用户不用再关心设备数据传上来,服务的后台的服务器的程序怎么写才能收到数据,数据在后台的消息里面,可以直接做后台应用的开发即可。不需要自己关心数据的流转。
二、经典客户案例
1、智能餐饮
(1)背景及使用情况:
随着物联网行业的快速发展,智能点餐服务已成为餐饮行业中的标配,消费者可通过手机 Apps(如 Android/iOS)在餐桌上扫码,并可以连接商家的智能系统,从而实现自助下单与自助支付;
(2)全智能交互:
消费者、商家、后厨,全自助的智能设备端+云服务的双向通信能力,快速形成高效的智能点餐系统;
(3)消息队列 MQTT 优势:
智能设备端之间,云端微服务之间,智能设备端与云端微服务之间,完全互通,完美配合。
2、新零售-电子价签
盒马,永辉,新零售的商场,生鲜超市,背景及使用情况:
(1)新零售电子价签通过MQTT以实现商场超市、公共场所电子标签、多媒体屏幕的数据更新管理。
(2)智能AP负责转发上报价签的状态数据,并接收改价指令。
(3)智能AP按照门店或者场所分布,使用MQTT协议接入阿里云微消息队列MQTT,该链路采用SSLTLS加密传输,防止数据泄露。
管理比如今天价格从一块钱改到两块钱依赖一套消息的引擎做数据传输。后台服务跟消息对列打通,前端通过mqtt和各个商场或者是公共场所的电子价签,多媒体屏幕进行互动,实现价签数据的管理。
3、音视频通信
(1)背景及使用情况:
通过微消息队列MQTT和音视频通信RTC,快速搭建各种实时通信场景品,譬如在线音视频会议、1对1语音通话应用的解决方案。
音视频管控服务和终端App之间通过阿里云消息队列产品完成信令传输,通过阿里云音视频通信RTC产品完成业务数据交互。
(2)产品优势:
弹性扩缩,按需使用,动态扩缩,轻松应对突发流量高峰;
网络覆盖范围广,提供全球部署,实现服务就近接入,避免自建跨区跨匡成本;
建设周期短,接入简单,无运维建设过程,人力和硬件成本低;
安全可靠,所有服务节点支持SSL/TLS加密,媒体流支持SRTP保护。
直播,钉钉发起语音通话时,除了媒体流语音通信,在发起媒体流的语音通话之前需要唤醒对方,通知有个人要打电话或者视频,依赖消息做事情,在场景里面mqtt也是连接用户的im app之间连接的枢纽。
4、车联网平台
(1)阿里云方案
完整技术解决方案,包括车辆实时连接,分布式应用支持,分布式数据库,大数据分析,云计算环境等。
支持海量车辆的实时交互,消息TPS和数据量无传输瓶颈。
(2)价值体现
基于云的高效灵活架构,可以大大节约开发和运行成本,提升运维效率;
强强合作。阿里云提供了先进可靠的基础技术平台,车企可以专注于对车联网业务的深入挖掘和持续创新上,以产生更大价值。
厂家会在车上安装嵌入式的平台,平台里面会跑程序,程序会在后台通过车载的信号卡把车辆的数据的上报到车的后台系统,还能通过app控制车比如查车的位置或者车上的指定的下发环节里面也是mqtt的发力点,一方面做数据的采集,另一方面做指定的下发,国内有主流的厂商也会接入阿里云的消息队列产品。
5、产品选型对比
对比项 |
微消息队列MQTT |
开源MQTT网关 |
|
弹性&成本 |
成本消耗 |
ECS机器成本固定, |
ecs机器成本固定 |
弹性和扩展性 |
存在瓶颈,无法无限扩展 |
存在瓶颈,无法无限扩展 |
|
服务支持 |
技术支持 |
7*24小时工单支持 |
x |
服务监控报警 |
√ |
x |
|
功能对比 |
消息持久化 |
√ |
部分支持 |
消息转发MQ |
√ |
x |
|
消息保留时间 |
√ |
部分支持 |
|
权限控制 |
√ |
x |
|
设备轨迹 |
√ |
x |
|
设备上下线通知 |
√ |
x |
|
消息回执 |
√ |
x |
|
管控API |
√ |
部分支持 |
|
顺序消息 |
√ |
部分支持 |
|
P2P消息 |
√ |
x |
|
完整QoS支持 |
√ |
部分支持 |
|
资源报表 |
√ |
x |
mqtt 是标准协议也相当于有开源的实现,用户在选型时选择阿里云消息队列,而不做开源自建。做对比,弹性成本,服务服务技术的支持以及功能对比三个方面,云产品都有很多的优势,因为云产品不只是实现标准协议同时还做很多商业化的功能增强,用户成本很低,因为都支持按量付费的模式,成本消耗都是随着它的实质用量增长,但是如果它要自己自建,机器的成本是省不下来的,同时很多开源产品会有局限性,比如有性能瓶颈的问题以及如果要进行自建,很多开源产品都是国外的产品,很难提供全天的技术支持,云服务有很大的优势,在功能层面做很多增强性功能,功能都会极大的降低用户的运维成本,排查问题或者是管控成本,是很大的卖点。
三、功能指南
从用户mqtt场景,用户接入流程介绍商业产品的增强在哪一方面,有哪些功能。
1、实例管理
用户接入阿里云产品使用消息队列产品,从资源管控层面开始入手,开始创建资源,最基本的实例,阿里云公共云的产品已经在绝大多数阿里云都已经开服,比如亚太地区或者欧美的主流都已经开服,对外的付费模式有两种,一种是预付费的包年包月,另外一种是按量付费,两种模式都会有计费的项目,主要有三个方面,连接数,订阅关系,消息调用的api技术,预付费的模式支高级用户,大客户推荐的一种铂金版专享实例,跟普通的共享实例的区别,它是真正物理隔离的实例,相当于它跟普通版是很多用户共享物理集群,因为逻辑隔离层面会有风险,所以建议大客户都推荐铂金版专享实例,而且还有很多定制的高级功能。
2、计费说明
(1)官网上也可以看到微消息队列for lot产品的预付费模式和后付模式都有三种计费项,第一个连接数的上限,连接数是可以对比app的日活,客户买实例,每一天同时在线的客户端终端的数量。比如十点时有1000个在线的,11点时有500个在线,取日活也就是取一天中在线日活的峰值是计费的项目,项目按规格买是一万或者两万。第二个项目是订阅关系,在消息产品里面,收消息要先告诉关注消息,告诉服务端要关注消息,这种关系叫做订阅关系,是源数据的一种,它也需要存储成本,所以也是个计费项,同样要看用户实例一天中维护的生成订阅关系的规模,一天中存在的最大值也是日活的概念。第三个是消息的tps,指实例下面一天互动的消息在tps峰值,对于包年包月计算规格和峰值,对于按量付费,前两个日活的规格还是看一天最大值是多少,按照单价折算,对于消息它不是tps的计算,它是把tps折算成调用次数,统计一天有多少个次数,按次数折算,比如一百万次,四块钱。
(2)举例,比如用户有三个设备,设备a设备B和设备C,设备A:订阅1个topic,发了1条消息,设备B:订阅了2个topic,收了2条消息,设备C:没上线
连接数计费: 2个(A和B)
订阅关系计费: 3个(A1 个,B2个)
API调用计费: 3个(A1个,B2个)
通过方式统计出用户的实例,三项的计费规格今天的消耗耗量,根据对应的规格或者是总量做计费。
3、实例绑定
当用户买实例之后,它还要做绑定,接入流程里面的概念,mqtt实例是天然和后端的消息产品家族里面的消息做映射,消息要存到后端的消息产品上,只要做关键映射即可,剩下的不用管,终端设备直接通过mqtt网关做数据输发,后台的应用也可以通过直接对应的消息产品,比如去其他产品里面获取数据。
4、Topic管理
映射关系:
(1)Topic 拆分成父级+子级
(2)系统header转成属性
(3)消息负载不变
在接触过程中还有 Topic,mqtt 产品收发时有数据类型,和另外数据不一样,Topic代替需要管理起来,所以需要在控制台里面创建。
5、Groupld管理
一个用户它有很多的终端,但是每个终端有版本或者有平台,比如ios终端或者安卓设备终端,可以让它建分组,分组关联起来,分组下面全是ios,另外分组全是安卓,建立分组关联,分组可以管理起来,可以基于分组做很多的事情,比如统计分组下面的设备的总量,可以知道ios的占有率或者安卓设备平台的注册量有多少,可以做管理性的操作。
以下mqtt三个主要的资源,三个资源管理搞定之后,可以做消息输发。
(1)MQTT Clientld :客户端的唯一标识,Clientld = Groupld +分隔符+ Deviceld
(2)MQTT Groupld:建议业务.上一组相同功能的设备共用一个Groupld,便于区分和管理
(3)MQTT Deviceld:建议业务上以设备的唯一信息做标识,例如登陆账号Id,或者设备Id,需要保证唯一性
资源操作完之后,客户会做功能的开发,也会介绍支持语言和平台方便大家在遇到客户时,可以对客户做介绍。
6、运行环境
平台\需求 |
消息发送 |
消息接收 |
权限管控 |
状态查询 |
移动终端开发 |
MQTT SDK |
MQTT SDK |
\ |
\ |
后台服务开发 |
Server SDK |
MQ SDK |
Server SDK |
Server SDK |
用户有终端场景,比如客户要做app,做手机端和各种终端设备的app的开发,同时它还会做后台服务的开发,后台服务的开发两种场景会分开,移动端的开发用MQTT SDK,后台的开发用Server SDK做操作。
7、开发语言&SDK
在多语言的地方,无论是移动端的平台,还是后端服务的平台都会有很丰富的多语言sdk,所以客户在介绍时不用担心语言不支持,同时在mqtt服务的支持上面还会支持很多种协议,比如有些用户对安全性或者加密有需求时都是支持原生tcp,tls,ssl加密传输,同时在web端也支持websocket方式方便有些用户做h5页面的web浏览器的开发。
8、权限认证
(1)AccessKey 签名认证
特点:接入逻辑简单、权限时效永久、账号级别授权。
(2)MQTT Token 授权认证
特点:接入逻辑复杂、临时授权,过期后需要重新申请、单客户端级别,支持子级topic权限。
开发完语言平台,客户会有问题,比如最显著的问题权限认证,因为终端产品的开发会有安全性的顾虑,安全性的顾虑块有两种方案针对移动端的方案支持阿里云标准的accesskey签名认证的方式,同时还支持自己商业化产品拓展的一种token授权的功能,两种功能的区别是accesskey签名模式很多产品都有,它的权限通过账号的accesskeyK再加上签名认证,认证通过之后客户访问代表是这个账号,好处是接触比较简单,但是缺点是它是个账号级别的,范围比较大,都是一个账号会相互受影响而且它的权限是账号,除非把accesskey给禁掉,否则它会永久,对于端上的开发不太容易满足,token服务针对不足进行拓展,稍微复杂一点,但是好处它是个临时的,像平常拿到授权码,授权码是有实效性的,它只能在一段时间内使用,过段时间之后它过期不能再用,要再用必须再重新申请token,同时token可以支持很细级别的权限,两个客户端可以用不同的token代表不同的权限,相当灵活,基本上可以满足所有用户短时间的访问需求,对于后台服务,就是阿里云标准的套路,有账号本身的accesskey签名认证,同时阿里云所有的产品都会支持sts token的方式认证。
(3)token认证
终端设备会向用户自己的后台服务登录,比如要做钉钉app会有登录,账号密码登录成功之后,换取token,像后台服务登录成功之后会向mqtt产品块申请token,生成成功之后再返回客户端,客户端用token访问,token过一段时间会失效,再重新换起新的 token。
9、推送管理
消息回执:微消息队列会将MQTT终端接收消息成功的事件转换成回执消息通知到应用以便发送方确认消息的接收结果。
客户要知道消息发给设备是否成功,怎么知道其实是消息回执的概念,消息的发送方,发消息的人需要知道销售方有没有收到,什么时候收到的,把功能打包成叫回执的功能,当时客户端收到成功之后会把信息记下来,通过消息方式再返回给它的发送方,发送方可以通过自己再订阅特殊的回执的信息获取刚才消息谁收到了,什么时候收到的,功能可以满足。
四、架构实现
在功能开发完之后很多时候用户上线之后会有些问题,问题怎么排查,针对常见的设备的问题以及消息的问题都有很丰富的运维工具。很多时候用户想知道,设备今天有点异常,它什么时候在线,什么时候不在线,有三种功能,第一种功能上下线通知功能。
1、设备管理-上下线通知
上下线通知:微消息队列会将MQTT终端上线下线的事件转换成事件消息通知到应用以便业务后台应用统计终端的活跃行为。感知设备变化的功能。
2、设备管理-设备轨迹
功能控制台上支持消息轨迹的查询,把上下线通知功能变成很简单的web控制台的功能,阿里云控制台的功能可以让用户不用写代码就能查设备,什么时候在线,什么时候订阅过或者时候发个消息等,除了设备轨迹以及上下线通知,还支持控制台opi的查询,opi的查询跟设备轨迹是一个概念,通过管控的方式查,总共有三种功能可以完成设备的管理。
除了完成设备的管理,消息的管理也很重要,有些用户的消息比较重要,消息没有收到,拿着关键信息,比如消息发送的发送方,客户端的信息id或者是消息的id之类的信息,查时会告诉用户消息什么时候发的,在哪个机器发过来的,什么时候收到的,在哪个机器收到的,信息一目了然,功能都是商业化产品才有的功能,像标准的msgld的开源产品很多时候都不具备这种功能。
3、监控报警
除了消息的查询还支持整个实例级间的监控报警,消息的gps,订阅关系的数量,因为都是计费的,所以很多时候用户会关注它的费用 关注它的用量,东西都是有完善的报表以及监控,比如也可以查询消息,用户业务的topic等,今天有什么规模的消息输发,还支持多种过滤的条件。
4、管控 OpenAPI
运营数据统计,统计终端规模以及消息量。
实时大盘展示,查看实时在线曲线。
设备信息查询,查看单一设备的在线情况和订阅关系。
OpenAPi接口 |
说明 |
OnsMqttGroupldList |
查询所有注册的Groupld |
OnsMqttQueryClientByClientld |
查询单个设备的在线情况和订阅关系 |
OnsMqttQueryClientByGroupld |
查询某个分组的在线设备数 |
OnsMqttQueryClientByTopic |
查询订阅某个topic的在下设备数 |
OnsMqttQueryHistoryOnline |
根据时间段查询历史在线终端数 |
OnsMqtQueryMsgByPubInfo |
查询LMQ消息 |
OnsMqttQueryMsgTransTrend |
查询消息收发量曲线 |
OnsMqttQueryTraceByTraceld |
根据消息ID查询投递数量 |
控制台暴露很多管控api,可以把控制台的web功能通过 api 的方式暴露出用户,如果不用 web 页面的控制台,可以自己集成做自定义的开发。