前言

很高興有這個機會和大家分享我們總結的關于邊緣計算的架構模式，也就是我們所說的基于能力的系統架構 —— COA。

什么是 COA 呢？我想通過一個很普遍的問題——電源問題來解釋。電源問題一直是移動電腦，特別是手機用戶體驗的一個關鍵問題。我想每個人都有過因為手機電量低而帶來不便的經歷，有的人甚至告訴我，光看到這張圖片，就會引起某種不適。

那么我們是怎么解決這個問題的呢？獲得持續的電力供應，是手機運轉的一個基本要求。

我想每個人對上面這些圖片都不會陌生，機場的充電站、五花八門的充電寶以及各種各樣的共享電源。解決手機的供電是一個問題，那為什么我們有這么多不同的方案呢？這是因為手機獲得持續電源供應的能力，是一個關鍵能力，我們必須用各種手段來保證，在各種場景下對手機的持續供電。

手機需要持續的電力供應

如果把這個問題抽象來看，我們可以看到手機獲得持續電力供應的能力，是有很多不同的方案來支持的。

比如手機集成的電池，這是基本方案，如果沒有，手機也就不是手機了，就變成座機了；充電寶是一個本地方案，因為你手機需要連接在本地的充電寶實例上；而電源插座是基于服務架構的解決方案，你把手機插在插座上，這個插座就是你訪問電力公司電力供應服務的接口；而在更極端的情況下，你可能還會用其他的替代電源，比如太陽能板，甚至手搖發電機。

這個例子說明什么呢？它說明對于系統所需的關鍵能力，比如獲得持續電力的能力，我們經常需要多個替代方案來確保能力的存在。比如您的手機沒電了，你會在乎你的電源插頭插在哪里嗎？你會在乎充電寶的形狀和顏色嗎？這些都不是關鍵。你需要的就是供電的能力，至于這個能力是不是基于服務的架構，以及這個能力是如何提供的，這都不那么關鍵。

這個例子讓我們思考，在設計程序的時候，能不能提供一種設計語言，讓開發者表述系統所需的能力，比如供電，而不是考慮系統能力的交付方式。無論這個能力是通過遠程的服務調用本地的容器，或者是局域網的服務代理實現的功能，這些都不重要，這些都是運維的問題，而不是系統設計和開發的問題。我們希望可以總結出一套設計模式，并在此基礎上建立一個工具和服務的生態系統，這就是我們提出 COA 這個概念的初衷。需要說明一下，COA 這個概念雖然是我們提出的，但是這種架構并不是我們發明的，COA 是我們基于對現有系統的觀察總結，在此基礎上，我們定義了 COA 的一些基本部件，以及這些部件可能實施的方式。

智能應用需要持續的人工智能能力

我們再用另外一個例子對 COA 的意義進行說明，這次我們考慮一個需要人工智能支持的程序。人工智能比如臉部識別，交互的方法也很多，您可以用固化或者半固化的硬件，比如 ASIC 或者 FPGA；您也可以通過調用已有程序庫或 SDK，比如在進程中調用 url 來進行物品識別；當然您還可以用進程外的方式，比如調用一個本地的 Docker 容器；最后您也可以調用云平臺上的服務，比如微軟的機器視覺服務等等。

在這個場景中，獲得 AI 的能力，比如臉部識別的能力是你所關心的，而這個能力是怎么交付給你的？這也應該是運維的問題。而且 AI 的模型層出不窮，對系統的需求也不一樣，把能力交付轉化成運維問題，允許您的程序可以被動地甚至主動地調解本身的行為，來適應不同的部署場景。比如我們曾經有一個智能交通燈的系統，在缺省情況下，它把高清晰的視頻傳到云上進行識別，當發現人行道上有輪椅，它就會延長綠燈的時間，以保證殘障人士有充足的時間過馬路。但是如果網絡帶寬不允許，它就會轉換成低分辨率的圖像，而且如果網絡斷開了，它就會轉到一個本地的模型，本地模型精度差一些，但是還是可以提供持續識別功能的。那么對于這個系統來講，輪椅的識別是一個必要的能力，這個能力具體是怎么交付的，甚至在運行的過程中是怎么選擇的，這個就應該是一個運維問題。

基于能力的系統架構

COA 的理念，就是把運維問題從開發者角度分離，所以 COA 的核心，就是讓開發者專注于能力，而不是能力的交付。如果我們有一個對能力的通用的描述、發現和使用的系統，那么我們很多的系統就可以做到平臺無關、位置無關、甚至技術無關。以手機充電問題為例：

平臺無關：你連到國內的插座和國外的插座這是無關的，至于對不同國家插座的電源、電壓以及插座樣式的適配，這是運維問題；

位置無關：你用哪個插座哪個充電寶，你的手機在哪，與你程序的設計及開發也是無關的；

技術無關：你的電源是電池，還是火電、水電、核電、太陽能……，這些都無關。

COA 就是把這些能力的實施和交互的方式，徹底地從開發者這里分離出來。

我們從另外一個角度看——運營方面，運營也會有更靈活和更精確的控制。比如你隨便選擇了一家數據庫公司，然后用這個公司的 SDK 來進行開發，結果公司倒閉了，這就是個問題。而 COA 允許你在選擇能力供應商時，同時考慮功能性和非功能性的需求。而作為運維，您可以獨立評估選擇供應商，然后根據不同的部署場景，選擇不同的能力供應商。它可能是本地的，也可能是遠程的，甚至是人工的，這都不影響程序的架構和代碼，同時您也可以靈活選擇部署方案。另外您可以用創新性的替代方案來取代原來的方案，回到人工智能問題，大概在一年前，谷歌的 BERT 還很厲害，但現在微軟的 GPT-3展現出了無與倫比的能力，有了 COA 您就可以在運營過程中對這個模型進行選擇，甚至綜合多方的結果提供一個更佳的方案，這些都是一個運維的問題，而不是開發的問題。

能力代理

實現基于能力的系統架構，需要幾個重要的系統部件，第一個就是能力代理。能力代理是指通過代理的方式，把能力供應者的細節封裝起來。能力代理具有如下功能：

第一，根據環境的變化選取能力的提供者。比如上文提到的輪椅檢測方案，根據網絡帶寬的情況和網絡連接的情況，能力代理可以動態地選擇不同的能力提供者，然后能力提供者在此基礎上可以提供更多的優化功能。

第二，提供本地緩存，不需要所有的服務都是遠程調用；它可以批處理，把分散的處理做成小的批次，然后統一提交給服務器；甚至它還可以做一些其他的，例如壓縮、加密等中間件的功能。

第三，在本地環境里，比如在一個局域網內，如果能力代理之間可以相互發現，我們就可以實現更高級的功能——伙伴間的動態調用。例如，在智能家居環境中，用普通的手機進行比較復雜的圖形計算時，我可以把這個能力臨時代理給我的游戲機，通過游戲機的 GPU 功能來進行圖像處理，就可以實現伙伴間的動態調用過程。

第四，基于功能性和非功能性需求動態發現提供者。能力代理的發現功能和我們普通所說的服務發現的過程不太一樣。因為在發現能力的過程中，我們可以同時考慮功能性和非功能性的需求。比如在發現一個能力供應商的時候，我們不但要考慮系統的性能、表現，甚至供應商本身的資質也是我們考慮的要素。

能力發現

說到能力發現，還要解釋它和服務發現有什么不同。傳統范疇的服務發現，是基于語法的發現，比如說我要做一個相加的服務，我可能通過服務發現的模式，找到一個相加的服務，它有相加的名字，但是我無法知道相加服務是不是真的在進行加法的計算。

而能力發現模式是由用戶來提交他所要實現能力的意圖，然后系統根據意圖進行語義上的發現，通過發現的過程可以真正發現一個可以進行相加計算的服務。然后我們可以把非功能性的因素也考慮進來，比如它的 SLA、安全性、供應商資質等，所以能力發現實際上是一個比較復雜的系統。

我認為，能力發現應該是一個基于多向量（包括功能性和非功能性向量）的幾率發現系統。但是在生產部署環境中，基于幾率的發現系統，很可能是不能滿足需要的。因此，我們就設計了，在發現之后可以通過一個固化過程，把所發現的供應商，提供成一個特定的能力組合，在能力組合的基礎上，您可以提供比較明確的版本的控制和供應商的控制。能力發現也需要我們提供表達用戶意圖的方式，通過一個通用的詞庫，基于自然語言的方式來實現對于用戶意圖的解析。

示例：lets 系統

在 COA 的基礎上，我們設想了一個系統——lets，上圖展示了用 lets 進行編程的一些示例。

臉部識別：我們可以通過 lets 命令行：lets detect face→輸入圖片→輸出圖片，系統就可以對輸入圖片進行臉部識別，然后再輸出圖片上疊加臉部的方框；

物品追蹤：在 python 里進行物品追蹤，需要導入 lets 程序包，然后 lets track orange，在 cameraStream1 的視頻流上進行橙子的追蹤；

文字總結：比如用 C# 編程的時候，用 lets class 來調用 summarize（方法：lets summarize 輸入文本→產生輸出文本），對一段文字進行總結。

這就是我們設想的 lets 系統在使用時在開發者上的體驗。大家可以看到，我們把 AI 的能力完全封裝在 proxy 的后面，對于開發者來說， AI 的能力到底是遠程的服務，還是本地的容器，還是本地的 SDK，這些都不重要。你所需要的就是描述你程序所要實現的功能，然后通過 COA 的 proxy 把這些功能呈現給你的程序。作為運維來說，它可以根據具體的部署場景來選擇功能具體的交付方式。

完整 COA 系統架構

完整的 COA 系統，可能還需要很多其他組件，由于篇幅原因，本文只提到了 COA 系統架構的部分組件。COA 并不是我們的發明，而是我們對一些現有程序，特別是一些基于邊緣計算的系統模式的總結，我們希望可以和大家一起創建一個比較通用的 COA 架構系統，來實現我們所設想的通用模塊，可以使 COA 的應用程序更容易地開發和使用。