從Serverless說起，談談邊緣計算的未來
曾經歷過企業(yè)級存儲、企業(yè)級容器平臺等產品的架構與開發(fā)，對容器、微服務、無服務器、DevOps等都有濃厚興趣。
本文整理自1月20日騰訊云微服務架構交流會。
Serverless是一個比較新的概念，2017年開始在行業(yè)內興起，邊緣計算則是一個更新的技術。那么Serverless在邊緣計算中能產生的什么樣的效果、產品以及形態(tài)并推進出來在大家面前呢？今天來為大家分享一下。
首先講講Serverless是什么？下面這張圖可以很清晰的看到，Serverless從架構上可以分成兩部分。
一是Backend as a Service，后端即服務，騰訊云上目前已經提供很多這類產品，例如COS對象存儲、CMQ消息隊列、CDN內容分發(fā)、CDB云數據庫、API網關，這些產品更多的是承載數據的存儲。
二是Function as a Service，函數即服務，也是Serverless比較核心的技術點，騰訊云云函數就屬于這種。
從Serverless或者云函數來看，更多是對用戶的計算進行托管。用戶將代碼和配置提交到云函數平臺上，此處的代碼是指用戶的一份代碼或者代碼包，配置，一個是指本身對于函數運行環(huán)境的配置，使用的是哪種環(huán)境、所需的內存、超時時間等；另一個是觸發(fā)器的配置。因為整個函數即服務的運行方式是觸發(fā)式運行，觸發(fā)就需要有一個事件來源，而事件來源是和騰訊云其他產品進行關聯后而產生。例如COS對象存儲產品，它的關聯就在COS的存儲桶中，當用戶上傳一張圖片或者刪除一張圖片時，就會產生一個事件，這個事件會觸發(fā)云函數的運行；例如和API網關的對接，也可以作為事件來源，在用戶的HTTP請求到達網關之后，API網關會把該請求作為事件轉發(fā)給云函數，觸發(fā)云函數的運行，云函數拿到請求之后進行處理，生成響應給到用戶。
上圖左側，是代碼和配置提交到云函數平臺進行保存，真正事件產生后，針對每一個事件都會拉起一個函數實例，實現觸發(fā)式運行；真正事件來臨時，用戶函數才會運行，用戶代碼運行時才有云函數代碼的數據運算和費用計算。
因為函數本身是托管型的，用戶本身無法感知到實例在哪里運行。云函數平臺背后有個大的計算資源池，用戶實例觸發(fā)之后，我們會從資源池中隨機選取可運行的位置，把用戶的函數實例在對應位置上跑起來。因此整個調度過程，或者事件來臨之后的函數擴縮容過程，都是由平臺進行的。對用戶來說，調度的粒度更細了，而且調度也都托管給平臺了。
而從整個的計算過程來說，為什么會有這種產品的出現？對于傳統(tǒng)的數據存儲過程來說，數據產生后，更多會先把數據進行緩存或者存儲，如以對象存儲文件的形式保存，或者數據庫中以結構化形式存儲下來，再進行分析應用。有了函數服務產品后，我們可以有很大的加速，可以在事件產生的時候就立刻對數據進行處理，因此就變成了先處理，再對結果進行保存使用的過程。
那么，還能不能縮短中間數據產生到數據處理的傳遞過程？
對于傳統(tǒng)應用來說，數據在用戶那里產生，傳到云上進行處理，再進行相應的存儲。這里說的縮短距離實際是把處理過程更加靠近用戶，靠近用戶就可以認為是邊緣計算的過程。并且這里的靠近用戶指的并不是加速網絡速度，而是更多把計算下發(fā)，放到更靠近用戶的位置。
之前無論使用容器也好，或者使用主機也好，運算能力都是在云上提供，而邊緣計算要做的事情是把運算能力下發(fā)到云之外去。
邊緣計算的理念，就是把計算能力下發(fā)更靠近真正的用戶，更加靠近設備這一端。
為什么會有這種需求的產生？
隨著互聯網以及物聯網的迅速發(fā)展，接入的用戶越來越多，設備也越來越多，在這種情況下，產生的數據量也越來越多。無論是個人用戶，還是物聯網接入設備，每時每刻都在產生大量的數據。數據不斷增多的情況下，也同時要求我們對于用戶的響應、設備響應越來越快，本身設備的計算能力也要越來越強。
10年前的一臺PC都比不上現在一臺智能手機的處理能力，設備的計算能力在越來越強的情況下，實現了把計算能力下發(fā)到更加邊緣的位置的能力。
云函數目前在做的探索，從兩方面出發(fā)。一是物聯網方向，物聯網主要是和設備打交道，實現設備上的邊緣計算；從云函數本身的特點來講，它屬于觸發(fā)型運算，真正數據產生之后才會拉起運算。云函數交由平臺托管的調度，可以把云函數調度到用戶設備上去，二把云函數調度到CDN的節(jié)點上去，雖然CDN可以認為是云的一部分，但CDN本身已經很靠近用戶，CDN節(jié)點實際上已經在云的邊緣。
接下來給大家做一個和物聯網相關的效果演示。
先簡單介紹一下幾款設備，***個是樹莓派，熟悉物聯網的同學一般都了解；第二個是光感的傳感器，可以感測環(huán)境光，從中讀取到環(huán)境光的流明值；第三個是LED燈。
目前這個設備已經跑起來了，它所做的事情是當環(huán)境光足夠亮的情況下，LED燈就會暗掉，當環(huán)境光足夠暗的情況下，LED燈會亮起來。演示過程可以看到，當我把光感器遮蓋的時候，LED燈有一個亮起來的動作。目前的環(huán)境光和背景足夠亮，當我打開的時候，因為光足夠亮，所以LED燈會滅掉。
針對這個代碼我做一個解釋。首先大家可以看到目前在樹莓派上跑的一段函數，已經下到樹莓派上跑了，在網上看到的是線上的代碼。接下來我會對代碼進行修改，從代碼中大家可以看到，當從傳感器中讀出的流明值足夠大的時候，GPIO做拉高或者拉低的動作，目前是正常的表現。
剛剛我完成了一個修改，現在我要把代碼下發(fā)到儀器上運行，同時把這里拉起，查看數值是否正確。下面不斷刷新的就是傳感器出來的流明值，目前傳感器已經變化了，因為大家可以看到這個數值已經超過了200，LED燈是亮著的，當我把感光器遮蓋以后，LED燈變暗，這是通過代碼把行為做了反轉的變化。
我們在目前的調試過程中也會做實際的設備調試，這里演示的就是真正把云函數下放到物理設備上進行執(zhí)行的效果。
接下來講的是目前云函數和用戶協同推進的AI能力，用戶數據只要在云上利用CVM、GPU服務器、騰訊TML機器學習，進行AI訓練，得出相應的訓練后模型，再把模型和外圍的導入代碼進行打包，放入云函數，或者是帶有GPU的云函數，就可以對外提供AI的推理能力。用戶真正使用AI的時候，從外面送過來一段用戶需要推理的語音、文本或圖像，在云函數中拉起訓練模型，就可以對這段數據進行推理。
AI能力表面上看起來和邊緣計算沒有關系，其實不然。如果本身已經在物聯網的邊緣設計上具有了云函數的執(zhí)行能力，那么是不是可以進一步考慮把AI能力下發(fā)到設備上去的，比如我們在云中進行數據的收集和訓練，生成模型之后，利用模型更新云上的函數，然后可以利用一鍵下發(fā)把這種能力下發(fā)到設備中，使設備具備更強的AI能力。
通過這種方式可以讓更多的設備接入AI能力，比如讓家里的攝象頭直接識別人臉，認識你的家人，或者讓更多的醫(yī)療設備直接對醫(yī)療檢查結果做出判斷，識別疾病類型等。這些都將會是后期持續(xù)和各個物聯網廠商進行摸索，往前推進的過程。
另外一個角度來說，我們?yōu)槭裁醋鯟DN的邊緣計算？CDN本身是把數據放到邊緣去的一個過程，而邊緣計算是為了把計算放到邊緣去。為了更快的響應用戶的操作需求，對于邊緣傳上來的數據進行更快的處理，這也是云函數對于邊緣的探索。
對于邊緣計算來說，云函數要做到的就是用戶在云中能完成函數的編寫、管理，在所需的位置把云函數下放各個位置運行和使用。
云函數未來在邊緣計算中還會有大量的探索機會，CDN廠商、物聯網廠商、硬件廠商等都將會有持續(xù)不斷的合作發(fā)展，去探索嘗試將邊緣的物聯網能力、邊緣的AI能力、邊緣CDN能力落地。
原文鏈接：https://cloud.tencent.com/developer/article/1044457
【本文是51CTO專欄作者“云加社區(qū)”的原創(chuàng)稿件，轉載請通過51CTO聯系原作者獲取授權】
