邊緣計算在物聯網(IoT)當中的運用「物聯網架構探索系列」

這裏記錄的是我對物聯網架構的學習、探索和思考，但願對你有所啓發……

　　邊緣計算是指在靠近物或數據源頭的一側，採用網絡、計算、存儲、應用核心能力爲一體的開放平臺，就近提供最近端服務。其應用程序在邊緣側發起，產生更快的網絡服務響應，知足行業在實時業務、應用智能、安全與隱私保護等方面的基本需求。目前，許多科技企業已經在邊緣計算上開始本身的佈局。

　　將來，咱們會看到愈來愈多的像智慧城市、智能工廠、智能製造、智能零售等一系列創新商業模式，它們在運用物聯網技術的過程當中，須要用到數據採集、處理、上傳數據的邊緣端計算設備和網關設備。這些設備或者是相應的解決方案，配合分佈式數據庫和分佈式的數據處理，就構成一個完整的邊緣計算體系。但這個體系不是獨立存在的，它會跟雲計算產生很是多的數據和應用互動。

邊緣計算簡單架構圖

　　提到邊緣計算，咱們會聯想到秒殺時候，使用CDN進行負載分流；可能也會聯想到數據中心和分佈式服務器；或者想到數據中心和設備採集網關；或者想到華爲AI神經網絡芯片、離線地圖，離線語音識別；或者自動駕駛，電動汽車等等……

　　這邊不深刻考究邊緣計算的概念，具體能夠查看維基百科或百度百科

　　邊緣計算的架構圖很簡單，以下圖所示(圖片來源)：

　　

爲何須要邊緣計算？

　　也許你會第一反應是中心計算力不足，網絡延遲，數據量龐大，這些都是常見的因素……

　　

數據上漲

　　隨着芯片計算力的發展、硬件成本的下降，加上網路提速，大概每十年一次變革，數據呈現指數級的增加。也許在2020-2030年，經過5G和AI的變革，計算機正在吞噬一切能夠數字化的東西，那時候數據的增加不知道會是什麼恐怖級別？

　　

　　顯然，這個時候的數據中心，已然沒法承擔集中式帶來的各自延遲，緩慢，痛苦……

成本上漲

　　爲何邊緣計算還能節省成本？

　　

• 幾十萬用戶的公司，只須要處理百級 QPS 的量，只須要 10 臺左右的服務器；
• 上百萬用戶的公司，只須要處理千級 QPS 的量，須要有 50 臺左右的服務器；
• 上千萬用戶的公司，須要處理萬級到十萬級 QPS 的量，須要 700 臺左右的服務器；
• 上億用戶的公司，其須要處理百萬級 QPS 的量，須要上萬臺的服務器。

　　以上數據不是徹底標準的，可是能夠肯定的是像BAT，TMD這些大廠的服務器都是以萬計算的。

　　如上圖所示，十萬用戶到上億用戶，用戶量也就多 100 倍，爲何服務器須要1000倍？由於，當架構變複雜了後，你就要作不少非功能的東西了，好比，緩存、隊列、服務發現、網關、自動化運維、監控等……

　　若是咱們可以把那上億的用戶拆成 100 個百萬級的用戶，那麼只須要 5000 多臺機器。

分擔計算

　　海量數據則可以就近處理，大量的設備也能實現高效協同的工做，諸多問題迎刃而解。所以，邊緣計算理論上可知足許多行業在敏捷性、實時性、數據優化、應用智能、以及安全與隱私保護等方面的關鍵需求。

　　這裏舉個簡單的應用，假如一個項目有5萬個設備點，每隔5分鐘一次採集，那麼一年後的測點數據可能就是100G量級。對這些數據的統計就會是一個耗時耗力的事情。

　　

邊緣計算應用場景

　　既然邊緣計算是一種必然，那麼邊緣計算會應用在哪些場景呢？我以爲至少如下這些場景會用到：

• 處理一些實時響應的業務。它和用戶靠得很近，因此其能夠實時響應用戶的一些本地請求，好比，某公司的人臉門禁系統、共享單車的開鎖。
• 收集並結構化數據。好比，把視頻中的車牌信息摳出來，轉成文字，傳回數據中心。咱們知道大華，海康等主流攝像頭設備自己自帶車牌識別等功能就是一個典型的應用
• 實時設備監控。主要是線下設備的數據採集和監控。好比，設備告警、設備聯動、設備管理、設備統計等
• P2P 的一些去中心化的應用。好比：邊緣結點做爲一個服務發現的服務器，可讓本地設備之間進行 P2P 通信。 
• ……

 

　　邊緣計算的運用場景仍是十分豐富的，還有不少是咱們所想象不到的，咱們正在期待神經網絡芯片助力AI智能，將來的設備必然會更增強大，更加邊緣化。

邊緣計算的技術？

　　邊緣計算涉及到的技術包括方方面面，這裏截取要點分析。

API網關

 　　

　　API Gateway至關於一個門衛的角色，和設計模式的Facade（門面模式）很像，是系統的惟一入口。網關能夠是一臺服務器，也能夠是一個比較強大的設備。

　　網關還能夠進行往下分層級，像衆星拱月同樣，最後經過一個大的門衛做爲惟一的入口。這種星型的網關架構能夠控制每一個子網關或者叫子邊緣計算的粒度。固然這種架構也帶來更大的複雜度。

　　

　　一個網關通常包含如下這些組件：服務註冊，請求路由，負載均衡，彈力設計，安全管控。此外網關對性能、集羣和高可用也是須要考慮的一個要點，對於初創中的團隊，這些其實能夠放在最後去考慮，後續業務起來後依然是一個必須考慮的重點，好比單點故障致使的全部訪問癱瘓，性能低下致使的請求延遲，或者沒有使用異步機制致使的吞吐量低下等等……

服務函數化(Serverless)

　　傳統的作法，咱們都須要在服務器上持續運行進程以等待 HTTP 請求或 API 調用，而Serverless能夠經過某種事件機制觸發代碼的執行。

　　"若是說微服務是以專一於單一責任與功能的小型功能塊爲基礎，利用模塊化的方式組合出複雜的大型應用程序，那麼咱們還能夠進一步認爲 Serverless 架構能夠提供一種更加 " 代碼碎片化 " 的軟件架構範式，咱們稱之爲 Function as a Services（FaaS）。所謂的 " 函數 "（Function）提供的是相比微服務更加細小的程序單元。"——左耳朵耗子

　　不一樣於微服務的是函數化更加碎片，並且無需進程等待，這是他的殺手鐗。最後推薦兩個GO語言的開源框架

• openfaas
• fission

數據同步

　　邊緣和中心的關係千絲萬縷，就物聯網來講，中心須要的數據是什麼呢？大部分是決策數據，也就是那些官老爺要看的數據，至於設備何時告警，何時出故障等等數據不必定要實時或者所有同步到中心，也就是說你的數據延遲一段時間並不妨礙，甚至隔天都問題不大。

　　若是要同步，通常如何作？

• 經過消息隊列寫時複製(Wirte And Copy)，這種方式實時性高，有很好的削峯填谷。
• 經過DB層面發佈訂閱進行數據同步，這種同步是日誌級別的，性能有保障，可是調式有坑，不建議使用。

　　我所瞭解的建築智能化設備設施這個行業，邊緣設備只要不是鬧人命的故障，好比電梯故障，火災報警什麼的，大部分的業務其實都和錢和安全沒有多大關係，也就是對高可靠的依賴是很是弱的。固然不排除醫院或者機場等特殊狀況。

 總結

 　　本文主要探討了物聯網領域的邊緣計算這個概念和簡單架構圖，接着簡單介紹爲何須要邊緣計算以及邊緣計算的使用場景和關鍵技術。邊緣計算和物聯網一塊兒興起，還有不少未知等待探索，一塊兒行動吧……

引用連接：

• 什麼是邊緣計算？
• 華爲雲IoT解決方案
• 邊緣計算、霧計算、雲計算區別
• 邊緣計算：物聯網的下一個風口