物聯網架構_對AWS的Greengrass的認識與理解

物聯網架構_對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的物聯網架構值得咱們去參考學習，可是於此同時，咱們也要根據實際業務場景的需求，進行本身架構調整與設計。

如實際場景中，我所在公司的客戶中，有的要求擁有本身的中控平臺，而且部分客戶爲了數據安全，還要求不對雲平臺提供數據（固然也有要求只提供部分結論數據的）。爲此，咱們在計算核心與雲平臺間，增長了企業服務器，完成了不向雲平臺上傳數據的企業的數據處理要求（固然，咱們暫時不會對這樣的公司提供行業數據的橫向分析業務）。

（以後有機會，我會在保密的前提下，簡單介紹我負責的系統的分析與設計過程。）