隨著物聯網越來越火，同時伴隨著物聯網而來的，就是各種概念和各種技術，其中壹個就是邊緣計算，當然還有霧計算。其實邊緣計算和霧計算都差不多，霧計算只是和雲計算是相對的。只是叫邊緣計算呢，比較高大上吧。
下面我們要通俗地講壹講邊緣計算。
為什麽要通俗的講呢，怕如果不通俗，妳聽不明白。新的東西在出來的時候，往往是需要壹個接納和理解的過程。就像以前互聯網剛出來的時候，很多人都不知道互聯網，於是就得慢慢科普，讓大家慢慢接受和理解呀。誰現在還解釋什麽是互聯網呀。
而邊緣計算也有壹段時間了，只是隨著物聯網的發展，邊緣計算的概念也開始流行起來。我們先看壹段非通俗的介紹邊緣計算的概念：
邊緣計算，是壹種分散式運算的架構。在這種架構下，將應用程序、數據資料與服務的運算，由網絡中心節點，移往網絡邏輯上的邊緣節點來處理。
或者說，邊緣運算將原本完全由中心節點處理大型服務加以分解，切割成更小與更容易管理的部分，分散到邊緣節點去處理。
邊緣節點更接近於用戶終端裝置，可以加快資料的處理與傳送速度，減少延遲。
以上是我從網絡文章摘抄的壹段對於邊緣計算的解釋。整個解釋基本都是專業術語，搞工控的妳，看完這段話，妳來告訴我什麽是邊緣計算。
作為壹名參與研發產品邊緣計算的程序員，我決定寫壹篇文章來通俗講解壹下這個邊緣計算。
首先，我要舉壹個不太恰當的例子。
比如有壹款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個電表，雲服務也毫無計算壓力，因為它並不需要計算。
這就是通俗的講壹講邊緣計算。