android开发|云服务系列文章(一) 阿里云和AWS
【怒草 https://blog.csdn.net/visionliao/article/details/108055806 未经允许严禁转载,请尊重作者劳动成果。】
概述
“云”这个东西程序猿肯定不会陌生,或多或少都有过接触。在如今的大趋势下,大大小小的公司都喊着上云(毕竟连我们这种小公司都上云了),各大云厂商也在疯狂的抢占市场,竞争已趋白热化。这样的好处是,云服务会变的越来越便宜,对于大多数上云的公司来说,这可以使得商业上投入的成本更加低廉。
云厂商的选择
如今市面上可选的云服务厂商还是比较多的,国内的阿里云、百度云、华为云、腾讯云,国外的有 Amazon AWS、微软的Azure、Google Cloud。这些是比较出名的,也是用户量最大的,实际上的云服务厂商更多。那么这么多的云厂商,该如何选择呢?说实在的这真不是一个容易决定的事,各大云厂商都有各自的优缺点,如果在开发的过程中,选了一个不适合你的云服务,那真的会是一件很痛苦的事情。最近一年因工作需要,用过几款云服务,多的不说了,阿里云市占率亚洲第一,AWS市占率全球第一,我就把这两个云拎出来说说它们各自的优缺点,以及后续的文章会介绍这两者的基础功能使用方法。
阿里云 VS AWS
阿里云 | AWS | |
“物”的概念 | 阿里将“物”的概念定义为设备(Device),在创建设备之前必须先创建产品(Product),每个产品下可以创建任意多的“物”。 创建一个产品会自动生成该产品的ProductKey和ProductSecret,作为该产品的密匙对,并且会自动生成阿里预定义的通信Topic父类,如/ota/device/inform/a1j8v6HNxKK/${deviceName}。 在产品下创建的每一个设备都会基础该产品的ProductKey和ProductSecret,加上设备名称(具有唯一性)就形成了设备三元组信息,设备三元组信息是阿里云标识一个设备唯一性的凭证,非常重要。 设备还会继承产品的预定义Topic,比如创建一个名称叫device1的设备,那么从产品中继承过来的Topic就会映射为/ota/device/inform/a1j8v6HNxKK/device1。当然也可以为产品添加自定义Topic。 |
【android开发|云服务系列文章(一) 阿里云和AWS】AWS的“物”就是Thing,可以随意创建,可通过CLI、控制台、Java SDK、Android SDK等任意一个接口创建。AWS Thing的名称必须是唯一的,你无法创建两个Name一样的Thing,所以AWS建议将设备的名称设置为设备的唯一标识,如SN号。 和阿里的设备三元组不同的是,AWS标识每个Thing的唯一性是用物品 ARN,每创建一个Thing会自动生成该Thing的ARN,格式为arn:aws-cn:iot: |
设备认证及鉴权 | 物理设备接入阿里IOT是基于设备三元组来验证权限的,因为设备三元组的唯一性,并且是随着设备创建时就已经创建好了的,所以实际物理设备和虚拟设备是严格的一对一的关系的,一台物理设备要和IOT通信必须先取得IOT平台上虚拟设备的三元组信息,如果多台物理设备取得了同一个虚拟设备的三元组信息,则会造成冲突,后面登录的设备会挤掉前面登录的设备。 设备认证的方式有多种: 1.Java后台调用阿里API创建设备,并且获取该设备的三元组信息,将三元组传递到具体设备端,设备端得到三元组信息即可接入阿里IOT 2.采用出厂烧录文件的方式,预先将设备三元组的信息写入到设备中,设备开机后将三元组信息读取到,也可接入阿里IOT 3.其它方式 |
每个连接的设备或客户端都必须具有与 AWS IoT 进行交互所需的凭证,这个凭证可以是X.509 证书、AWS 凭证、Amazon Cognito 身份、联合身份或自定义身份验证令牌。 有了必须的凭证后就相当于拥有了打开AWS IOT大门的钥匙,但是这并不代表可以为所欲为,AWS 为了控制权限还引入了策略(policy)这个概念,策略是控制每个接入AWS的设备的访问权限的,可以为每一台设备配置不同的权限策略,这样使得AWS的服务更加安全。策略需要附加到证书上,也就是:证书 + 策略 = 访问 + 控制。 设备认证的方式也有多种选择: 1. 使用预置模板进行单一事物预置。 2. 使用在首次连接到 AWS IoT 时预配置设备的模板进行即时预配置 (JITP)。 3. 批量注册,可指定存储在 S3 存储桶内的文件中的单一事物预置模板值。 4. cognito + IAM允许临时身份连接,通过临时身份创建证书以及策略 |
消息通信 | 阿里的消息通信是基于Topic通信的,在通信之前必须实现设备的激活和注册。可以使用阿里预定义的Topic进行消息通信,也可以使用自定义的Topic进行消息通信。 阿里的Topic的格式为/a1j8v6HNxKK/${deviceName}/user/,可以看出是基于设备信息(设备三元组)生成的,这就导致每个设备的通信Topic都是唯一的,这也体现了阿里IOT虚拟设备和实际物理设备一对一的关系。使用一条阿里预定义的Topic或者自定义的Topic,都可以准确的将消息发送到对应的设备端。 |
AWS的消息通信也是基于Topic的,和阿里有很大区别的是,AWS的Topic都是自己定义的,并且可以随意定义。这里也体现出了AWS的架构设计的高度灵活性,只要Subcribe了相关Topic,就可以收到这个Topic的消息流,而且任何客户端或服务端都可以通过任意的Topic Pub消息(当然前提是附加了sub/pub的权限策略(policy))。AWS Iot没有强制性,不需要唯一性,也不需要和实际物理设备一对一,这是个自由的、发散性的概念。 更为便捷的是,Thing是存在AWS Iot上的虚拟物品,它和实际物理设备可以没有任何关联,即使没有在AWS Iot上创建虚拟Thing,实际的物理设备也可通过Sub/Pub收发消息,就像前面介绍的,只需要符合证书 + 策略 = 访问 + 控制的逻辑既可。 |
消息群发 | 如上消息通信里的介绍,因为阿里的通信Topic都是唯一的,这就导致给一个具一定特征的群组群发消息带来麻烦, 最通常的处理逻辑是,获取这个群组所有设备的特定Topic,然后挨个给这些设备Pub Topic消息,这样可以达到消息群发的目的,但是太不灵活,实现起来代码执行效率也低。 阿里提供了一个广播机制,可以对一批设备群发Topic消息,但是一个群组的设备监听量最大为1000,因为这个限制,使得广播群发消息的实现逻辑变得更为麻烦。 |
相比于阿里的消息群发,AWS在实现同样功能的方案选择就多的多,而且每种实现方式都很简单。 1.创建Thing时为每个Thing添加相同的topic属性,客户端可以查询该thing的信息,从而Sub该Topic。 2.创建ThingGroup,为ThingGroup添加Topic属性,客户端可以通过自身Thing信息查询所属的ThingGroup,从而得到相应Topic,最终Sub该Topic。 3.其它未验证的方式 以上的方法都可以通过Java API自动实现创建,客户端自动获取信息并订阅相关Topic,都可以实现自动化处理。AWS将其服务功能拆分的很细,使得用户可以自由组合这些功能。 |
性能及效率 | 在设备数量不多时时延性很低,没有消息漏发等情况出现,大量设备未进过测试 | 在设备数量不多时时延性很低,没有消息漏发等情况出现,大量设备未进过测试 |
日志调试 | 因为阿里的每个设备的通信Topic都是唯一的,这就可以很好的跟踪每个设备的日志情况,包括设备的上线、离线、Topic上行消息、Topic下行消息等,在控制台就可很直观的查看对应设备的日志消息,这对于功能调试起到了很大的辅助作用。 | 相对的,AWS为了安全性,即使是查看日志也需要添加相应的策略(Policy),并需要开启相关的权限,而且日志信息显示的很粗陋,检查起来很不直观,操作也不方便,这一点阿里做到要好的多。 |
资料及文档 | 阿里的技术资料以及文档很适合中国开发者,直观、简洁,每个介绍重点概念的文档下面都附有各个平台的开发示例代码,这使得使用阿里的IOT来开发产品变得容易很多,也就是很好上手,能在较短的时间内开发出相应功能的产品。 | AWS虽然市占率全球第一,但毕竟是外国人的思维习惯,外国人大都是偏技术型的,要使用他们的产品他们首先希望你能理解他们的设计思想。虽然文档资料很全面,但是绝大部分文档都是只介绍概念原理的技术性文档,很难找到相应的示例代码。 虽然现在AWS官网上有很大一部分文档支持中文,但都是翻译文,有些翻译很生硬,很容易造成理解偏差,中国开发者使用AWS的产品体验就会很差,上手项目也就不是那么容易了。 |
技术支持 | 阿里技术支持的特点:响应速度快、免费、随时可提问题,即使在6点后的下班时间也可能会收到回复(中国互联网公司的尿性)。 阿里要求售后支持在客户提出问题的两个小时之内必须给出回复,而阿里的技术支持也确实做到了。但是就是因为这个原因,技术支持只能做到“你问什么他答复什么”,针对问题解决问题。问题确实是解决了,但是客户到底想实现什么样的需求?客户对阿里的这个概念理解的对不对?有没有更好的实现方案? 这些就只能留给客户自己去琢磨了。 |
AWS技术支持的特点:响应速度慢(24个工作小时内,也就是三天之内)、收费(按不同的服务等级收取不同的费用)、6点下班之后绝对不可能收到答复。 AWS的特点和阿里的特点完全相反,但也正是因为这个原因,让AWS的技术支持变得很精致。在AWS每提一个问题,技术支持都会站在用户的角度去考虑实际需求,如果发现你提的这个问题和你的实际需求不一致,那可能是你对AWS的产品理解的有偏差,他会告诉你要完成这个需求还有更好的方案,给你介绍一遍这个功能的实现原理,然后就是相关参考文档链接,如果有示例代码也会发出来。最后,把你提的这个问题的解决办法告诉你,然后再把这个问题对应的文档以及原理都发给你,最终的目的是让你能够很透彻的理解这个概念。 |
总结
总之,目前来看,AWS足够优秀,几乎所有业务都可以囊括实现,但是上手比较难,对中国开发者来说有点难度;阿里也不赖,绝大部分业务需求都能实现,且上手容易,对中国开发者及其友好。
推荐阅读
- android第三方框架(五)ButterKnife
- 赠己诗
- 深入理解Go之generate
- Android中的AES加密-下
- 标签、语法规范、内联框架、超链接、CSS的编写位置、CSS语法、开发工具、块和内联、常用选择器、后代元素选择器、伪类、伪元素。
- 八、「料理风云」
- 带有Hilt的Android上的依赖注入
- 西湖游
- 两短篇
- 9531