物聯網架構_對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的物聯網架構值得我們去參考學習，但是於此同時，我們也要根據實際業務場景的需求，進行自己架構調整與設計。
如實際場景中，我所在公司的客戶中，有的要求擁有自己的中控平臺，並且部分客戶為了資料安全，還要求不對雲平臺提供資料（當然也有要求只提供部分結論資料的）。為此，我們在計算核心與雲平臺間，增加了企業伺服器，完成了不向雲平臺上傳資料的企業的資料處理要求（當然，我們暫時不會對這樣的公司提供行業資料的橫向分析業務）。
（之後有機會，我會在保密的前提下，簡單介紹我負責的系統的分析與設計過程。）