cq9电子·(中国)官方网站

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

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

  邊緣計算簡單架構圖

  提到邊緣計算，我們會聯想到秒殺時候，使用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层面发布订阅进行數據同步，这种同步是日志级别的，性能有保障，但是调式有坑，不建议使用。