通俗講解邊緣計算
隨着物聯網越來越火，同時伴隨着物聯網而來的，就是各種概念和各種技術，其中一個就是邊緣計算，當然還有霧計算。其實邊緣計算和霧計算都差不多，霧計算只是和雲計算是相對的。只是叫邊緣計算呢，比較高大上吧。
下面我們要通俗地講一講邊緣計算。
爲什麼要通俗的講呢，怕如果不通俗，你聽不明白。新的東西在出來的時候，往往是需要一個接納和理解的過程。就像以前互聯網剛出來的時候，很多人都不知道互聯網，於是就得慢慢科普，讓大家慢慢接受和理解呀。誰現在還解釋什麼是互聯網呀。
而邊緣計算也有一段時間了，只是隨着物聯網的發展，邊緣計算的概念也開始流行起來。我們先看一段非通俗的介紹邊緣計算的概念：
邊緣計算，是一種分散式運算的架構。在這種架構下，將應用程序、數據資料與服務的運算，由網絡中心節點，移往網絡邏輯上的邊緣節點來處理。
或者說，邊緣運算將原本完全由中心節點處理大型服務加以分解，切割成更小與更容易管理的部分，分散到邊緣節點去處理。
邊緣節點更接近於用戶終端裝置，可以加快資料的處理與傳送速度，減少延遲。
以上是我從網絡文章摘抄的一段對於邊緣計算的解釋。整個解釋基本都是專業術語，搞工控的你，看完這段話，你來告訴我什麼是邊緣計算。
作爲一名參與研發產品邊緣計算的程序員，我決定寫一篇文章來通俗講解一下這個邊緣計算。
首先，我要舉一個不太恰當的例子。
比如有一款APP，用戶在使用這款APP的時候，就會收集用戶的信息，比如收集這個用戶的年齡，性別，手機號，地址位置，搜索記錄等等信息，而收集這些信息主要是更好地分析這個用戶的行爲和感興趣的東西，比如車，房子，書，美食等什麼感興趣。然後更爲準確地爲其投放內容及廣告。
這個是很常見的一個功能，但是就是這樣一個功能，怎麼和邊緣計算掛鉤呢。
在邊緣計算之前，就是雲計算了。
如果是使用雲計算，這款APP的行爲是這樣的：
APP收集到信息後，把所有的基本信息，上傳到服務器中，然後由服務器來執行算法，計算和識別出用戶的興趣愛好，甚至可能推算出這個用戶的消費能力。然後服務器就可以根據這個推算出來的結果，爲用戶投放其感興趣的內容和廣告。
如果是使用邊緣計算，這款APP的行爲就是這樣：
APP收集了信息後，不上傳到服務器中。然後由APP自己計算和識別出這個用戶的興趣和愛好，也可以推算出這個用戶的消費能力，也就是服務器的計算功能，直接由APP來完成。然後服務器只需要問一下APP,哪個用戶是有可能是年薪百萬的，哪個用戶是單身的。APP只需要告訴服務器說，這個一路向東用戶很帥，而且還單身，喜歡旅遊，寫詩，可以爲其投放相親美女內容。
就這樣，整個過程並沒有服務器參與計算，服務器也沒有參與收集信息。因爲這個信息在APP本身收集和計算，並沒有進行上傳，所以也沒有涉及信息收集。
而，這就是邊緣計算。
也就是以前由服務器作計算的部分，現在改由信息採集的設備直接計算了，再把計算的結果，直接輸出到服務器中。服務器只要結果，並不需要過程的數據。
下面我們就以回答問題的形式來通俗的聊一聊這個邊緣計算吧。
所以，什麼是邊緣計算呢。
邊緣計算，說白了，就是（服務器）雲計算懶得算了，就這點數據，你在數據採集的時候，順便自己算得了，什麼都丟到服務器來算，很累的。於是，邊緣計算就這麼來了。
那麼，工控領域行業中使用到邊緣計算的都有哪呢
這個就太多了。隨着很多PLC，控制器和觸摸屏等都開始接入到物聯網中，每個設備需要採集的信息不一樣，有溫度，溼度，產量，生產數據，運行狀態等。而不同行業的參數指標，性能數據都不一樣，這很難在服務器通過雲計算來形成一套標準，這使得PLC，控制器等，都會用到邊緣計算。
爲什麼以前的DTU，或者物聯模塊等不流行邊緣計算，現在開始流行了呢。
因爲現在的IoT使用的模塊或者芯片的處理能力也越來越高，資源也比較豐富，隨着一些芯片成本的下降，以及開發模式的簡化，使得一些芯片或模塊在處理基本的數據採集功能後，仍存在資源過剩及功能利用率低的情況，也就是一個100%的芯片或模塊，你只使用了10%的來採集數據，那還有90%你可以用來作計算
那麼，使用邊緣計算的優勢在哪裏呢。
1 可以使得設備的支持數量提升幾個數量級。
比如一個服務器有10000點血。而接入一個設備，就要消耗1點血，如果再對這個設備進行數據分析，需要消耗9點血。也就是接入並計算一個設備就需要10點血。那麼這個服務器最多隻能接入1000個設備就掛了。
如果服務器只負責接入設備，不進行計算和分析，那麼接入一個設備，消耗1點血，由設備自己進行數據計算和分析，再輸出結果。這時候服務器就可以接入10000個設備了。
沒有使用邊緣計算，服務器可以接1000個設備。
如果使用了邊緣計算，服務器可以接10000個設備。提升了一個數量級。而對於一些複雜的設備，特別是一些工廠，現場作業等需要數據量多的，如果使用了邊緣計算來給服務器節省空間和資源，這個優勢更能體現出來了。
2 讓計算變得更爲靈活和可控
前面說到，接入設備的服務器很難做到統一的計算分析標準，因爲物聯網可是一個萬物接入的網絡，每一個設備採集的數據不一樣。如果使用了邊緣計算，就可以單獨針對每一個設備進行相應的計算和分析。當然，如果相同的設備或者相同參數的，可以進行復制使用同一套計算標準或算法。如果將計算腳本開放出來給用戶，用戶就可以自定義去添加自己的計算公式和行爲。
邊緣計算的模式和拓撲結構是什麼樣的呢。
比如要在一套數據採集系統裏，以一個雲服務器爲中心，移動客戶端，PC客戶端或第三方接口等接入到雲服務器獲取數據，而數據採集方呢，由數據採集模塊來連接到雲服務中。
數據採集模塊可以採集PLC，變頻器，智能儀表等，將數據上傳到雲服務器中，由服務器進行數據分析和計算，然後PC或移動客戶端，第三方接口就可以獲取數據分析的結果。但是這種情況下，隨着設備的接入越來越多，雲服務器的負擔也會越來越重，而且接入的PLC，控制器等的種類也越來越多，原來的雲服務數據計算模式難以滿足越來越複雜的應用。這時候邊緣計算就應運而生了。
在原拓撲結構不變的情況，可無縫引入邊緣計算。在數據採集模塊端開放邊緣計算功能，將複雜的計算，策略，規則等，由數據採集模塊進行運算，得到輸出結果後，只需要將結果上傳到雲服務中。再由PC客戶端，移動客戶端及第三方接口從雲服務獲取。
比如數據採集模塊需要採集一個電錶，電錶能採集的數據有電流，電壓，偏偏沒有功率。當然現在的電錶採集不到功率很少了，只是舉例。
那怎麼辦呢，偏偏客戶很想看到功率。那在沒有邊緣計算的時候，爲了要看到功率，只好在雲服務裏，增加一定的計算規則，將採集到的電流和電壓通過計算得到功率。如果有1000個電錶，雲服務器就要對這1000個電錶進行計算。這就增加了雲服務器的工作量和負擔了。
如果有了邊緣計算，那麼在數據採集模塊，就可以添加計算功能，直接將採集的電流和電壓通過計算得到功率，只需要把功率上傳給服務器就可以了。這樣，即便有50000個電錶，雲服務也毫無計算壓力，因爲它並不需要計算。
這就是通俗的講一講邊緣計算。