物联网架构_对AWS的Greengrass的认识与理解
一，前言：
这段时间有许多的收获，分析，还有总结，其中包括新系统的设计与开发，以及其中新技术的踩坑等等等。
但是最近真的很忙，项目的推进，面试工作等，尤其五月份还有考试。所以，赶紧趁着五一假期有些空暇，先发一些东西。之后，有机会再对自己的素材（周报，技术总结什么的），做一些整理，再发出来哈。
这篇文章，主要是在之前项目架构设计时，了解了现有的一些项目，其中就有AWS的Greengrass项目，这里简单介绍一下自己的认识。
物联网方面的介绍可以参考我回答的百度知道（@link：https://zhidao.baidu.com/question/1501072861578680979.html?entry=qb_uhome_tag）
说简单点，就是物联网会是接下来的五到十年的一个小风口吧。可以试着，去了解，去学习，去感受其中的技术的变革（并不一定非要从事专门的工作，而是从变革中看到技术演变的过程，领悟它）。
这篇文章是简单看了AWS有关物联网的项目Greengrass后，感觉其角度与之前了解的百度物联网架构有所不同，所以查阅了一些资料后，给出我的看法。
（百度物联网的资料，可以参考@link：https://blog.csdn.net/robert_tina/article/details/78979405，条理比较清晰，我就不给出自己的XMIND了）
二，XMIND：
（图片看不清的，请单独打开图片，或放大图片，或下载图片。图片绝对清晰，谢谢）
三，补充：
之前@博达智联写的博客与这个结构图的关注点有较大差异，前者倾向于技术领域，后者虽然重心仍然在技术领域，但是涉及了一些业务，乃至领域性的问题。
如为什么我们需要边缘计算，或者说物联网领域为什么要采用边缘计算，边缘计算的边缘又是指什么？边缘计算的理由，可以看上图中问题及解决/源位置处理数据的价值的三个原因。
如无人驾驶中，车速假定10m/s，前方5m处出现障碍物。系统采集数据（数据清洗），上传数据（涉及网络延迟），云平台计算（可能涉及服务调用等延迟），数据下发（涉及网络延迟），本地数据解析与运用。这样的流程可能需要200ms，即0.2s。那么车子距离障碍物就只有3m了，制动距离可能就不够了。当然这些数据都是假设的，可能不符合实际场景，但是我所要表达的意思是这样的。其中数据清洗，云平台的服务调用等，你都可以通过一定的技术手段去缩减，甚至接近0耗时。但是如今的网络延迟，你是无法大幅度缩减的，因为这涉及到物理定律。你所提出的技术解决方案是不可能打破物理定律的。
那么，我们可以调整一下我们的逻辑模型，进而改变我们的架构。比如我们可以赋予边缘节点（边缘指远离计算中心）一定的计算能力，从而实现简单的处理能力。在上述例子中，我们可以在汽车的计算单元中，简单评估障碍物所带来的危险程度与现在的速度等，决定是缓慢减速，还是急刹车。在0.2s后，再根据云平台发回的精准结果，来进行调整。
当然我只是举了一个有关物理定律的例子，还有经济定律中的资源损耗。如现有阶段，你无法将无人汽车的视频24x7小时的上传，那太消耗带宽了。另外还有国家法律方面的隐私保护，如军事领域的汽车（即便只是首长回家，因为涉及首长安全），恐怕很难允许你获取无人汽车的详细行驶资料。
而这些都是技术之外的。我一直相信，技术与业务之前需要交流与权衡。因为很多问题在业务看来，只是简单地做一些调整与舍弃，却能解决技术巨大的压力。同样，很多在业务看来，很难实现的方案，也许在技术领域来看，只是多写一些服务的问题。所以，团队要注重交流，leader（当然这个leader并不是指绝对的一个人，而是指相关事件的决策者。解释起来比较麻烦，之后有机会，会在敏捷开发等文章中来解释我的这一想法）要权衡技术与业务。
四，分析：
其实简单来说，AWS的Greengrass就是将整个系统分为三个部分：底层硬件（AIOT SDK），计算核心（GGC），云平台（AWS服务）。
其中Greengrass为底层硬件，如倾斜传感器，温度传感器等提供了对应SDK，封装了与上层GGC的通讯等，提高了开发效率。这就类似于我们封装了Jedis，形成JedisUtils，来快速方便调用redis，实现我们的功能。但是底层硬件并无法实现基础计算之外的功能，所以我们需要GGC来帮我们完成边缘计算的计算部分。当然即使GGC也在对应的硬件上时，逻辑上，我们仍然拆分两者，这是为了更好地管理与实现功能。而云平台则是提供了数据的高阶应用，如数据挖掘，机器学习，并为企业决策提供支持等。另外AWS的Greengrass的云平台部分，可以直接调用AWS的数据处理服务，也就是说改云平台与AWS的其它服务是可以横向连接，调用的（其安全性是通过设备上的SigV4凭证实现的）。
五，总结：
AWS的物联网架构值得我们去参考学习，但是于此同时，我们也要根据实际业务场景的需求，进行自己架构调整与设计。
如实际场景中，我所在公司的客户中，有的要求拥有自己的中控平台，并且部分客户为了数据安全，还要求不对云平台提供数据（当然也有要求只提供部分结论数据的）。为此，我们在计算核心与云平台间，增加了企业服务器，完成了不向云平台上传数据的企业的数据处理要求（当然，我们暂时不会对这样的公司提供行业数据的横向分析业务）。
（之后有机会，我会在保密的前提下，简单介绍我负责的系统的分析与设计过程。）