云服务系列文章(一) 阿里云和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。	AWS的“物”就是Thing，可以随意创建，可通过CLI、控制台、Java SDK、Android SDK等任意一个接口创建。AWS Thing的名称必须是唯一的，你无法创建两个Name一样的Thing，所以AWS建议将设备的名称设置为设备的唯一标识，如SN号。 和阿里的设备三元组不同的是，AWS标识每个Thing的唯一性是用物品 ARN，每创建一个Thing会自动生成该Thing的ARN，格式为arn:aws-cn:iot:<Region>:577850053356:thing/<ThingName>
设备认证及鉴权	物理设备接入阿里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开发时最直观的感受，整理发出来供大家参考。我是在一个项目上用阿里云实现了后，再用AWS实现了一遍的，一开始真的很排斥AWS，对于我这种英语不咋地、AWS提供的示例代码又很少的情况下，用老外的设计思维来完成中国人的业务场景，真的是一种折磨。但是随着时间推移，发现AWS真是越用越顺手，而我只能"卧槽，卧槽，这个屌！”。用完两者最直观的感受就是，用阿里云感觉就像逛淘宝，啥东西都有，但是质量又感觉不是那么好，但是便宜啊！用AWS感觉像逛天猫精品店，贵是贵了点，质量上还是稍微有保障的。我这么说并非是贬低阿里云，AWS在“云”这一块的耕耘无疑是时间最长的，技术上也是处于领先地位，不然也做不到全球一哥，AWS的功能设计、架构设计无疑成为了云厂商的模范，它积累了足够多的业务场景和技术支撑，现在无论使用哪种云服务，都会出现AWS的影子，很多功能其实是直接照搬AWS的。而阿里在短短的几年内能够起到追赶AWS的态势，已经很不错了，做技术的都知道，技术这东西是需要精耕细作、慢慢积累的，所以阿里云目前虽然实现了AWS的大多数功能，但毕竟时间还是太短了，在云这方面没有AWS积累的深厚，这导致阿里在设计上还是有业务短板的，至少我在使用的过程中就碰到过，技术支持也明确不能实现，另外还碰到一些小缺陷，导致不能100%精确等，这个以后有机会再说。

总结

总之，目前来看，AWS足够优秀，几乎所有业务都可以囊括实现，但是上手比较难，对中国开发者来说有点难度；阿里也不赖，绝大部分业务需求都能实现，且上手容易，对中国开发者及其友好。