從單體到微服務，再到 Serverless，應用在逐漸地輕量化。有人可能會有疑問，微服務都還沒有順暢的搭建起來，現在又出了 Serverless，應該怎麼辦？
其實兩者之間並不是一個相互替代的關係。我們可以看到，現在有單體應用在跑，也有微服務的應用在跑，那麼以後 Serverless 這種應用也會有一定的用途。而微服務裏也可以調用 Serverless 的函數（function）。
Serverless 定義
Serverless 類似於之前大數據的概念，大家都知道，但不是特別確切瞭解其中的含義。
CNCF 有一個 Serverless 工作組，在 Serverless 的白皮書中進行了定義。簡單來講就是，Serverless 等於 FaaS(Function-as-a-Service) 加上 BaaS(Backend-as-a-Service)。我們可以將應用程序以函數的形式打包，然後上傳到 FaaS 平臺。這樣我們就不用關心底層服務器的運維，因爲它能自動擴展，而且是按需收費。
Serverless 有一個很重要的特徵，就是事件驅動模式，即依賴於外部事件去觸發它運行。
至於 Backend-as-a-Service，你可以理解成支撐 Serverless 運行的一些 API 的服務，比如對象存儲或者是數據庫服務。
Serverless 處理模型
下圖是 Serverless 的處理模型。上文講到，它的模式是事件觸發，所以它會有事件源產生事件，然後 FaaS 的 controller 是根據這些事件去啓動 function 的 instance，而且能夠實時的去擴展，能夠 scale 到 0，這樣動態的去給用戶提供服務。
函數生命週期
函數（function）是有生命週期的，也就是函數部署流水線的流程。首先提供 function 的源碼和 spec，然後把源碼 build 成 docker image，再把 docker image 部署到 FaaS 平臺上。
涉及到函數，肯定會有函數的創建、更新、發佈等操作，因篇幅關係，這裏就不再贅述了。
Serverless 應用場景
對 IoT 設備數據進行分析
目前邊緣計算，還有 IoT 的應用都在逐漸地興起。 比如 IoT 中的一個傳感器，它會源源不斷的產生一些數據（例如傳感器溫度超過了 60 度），我們可以調用一個雲端的函數來處理這件事情（發個通知或者做一個應用）。所以 Serverless 和 IoT 這個場景可以很好地結合起來。
AI 模型服務
AI 也在逐漸興起。邊緣或者是雲端提供模型的服務，因爲很多模型的推理都要佔用 GPU，所以如果一直佔用 instance，非常耗費資源，而且還增加了成本。但是如果用 Serverless 這種方式去提供服務，比如利用 Kubeflow 項目下的 KFServing 提供推理服務，在空閒的時候可以 scale 到 0，有流量的時候會自動 scale up 起來，所以能很好地節省成本。
其他場景見上圖，因爲篇幅關係不再一一展開講述。
Serverless 優勢
- 降低成本
- 提高資源利用率
- 無需關係底層基礎設施的運維及管理
- 靈活可拓展
- 提升開發效率
開源 Serverless 平臺
我們針對開源的 Serverless 平臺做了一個調研。下圖中列出的都是開源的 Serverless 平臺，可以分爲兩類，一類是 Knative，另一類就是非 Knative。
爲什麼這麼分類呢？因爲上文講到，Serverless 主要就是有一個 FaaS 的功能，但 Knative 並不是一個嚴格意義上的 FaaS 平臺，而其他開源的 Serverless 平臺都屬於 FaaS 平臺。
下圖是在 Google trend 上查詢到的數據。在過去一年中， Knative 的熱度基本是最高的，OpenFaaS 的熱度在 FaaS 平臺中是比較靠前的。而過去 5 年的數據也類似，可以說，Knative 自問世以來，熱度一直居高不下。
下圖是 CNCF 去年做的一個調查，調查顯示，在可安裝的 Serverless 平臺裏，Knative 是比較領先的，然後 OpenFaaS 在 FaaS 平臺裏是比較領先的。
Knative 的優勢
大家可能會有疑問，上文說到 Knative 並不是一個嚴格意義上的 FaaS 平臺，那麼它爲什麼在 Serverless 領域會這麼受歡迎呢？
有以下幾個原因：
- Serverless 有幾個要素，首先它是事件驅動的，所以它要對事件有很好的支撐。通過 Knative Eventing，可以對事件的管理有很好的支持，也形成了一套 cloudevent 規範，用於 Serverless 負載的交互。
- 我們上文講到了，它需要把函數的源碼去 build 成一個 docker 鏡像，所以它也要有 build 的能力。之前這個組件叫knative build，現在叫 Tekton。然後在函數發佈的時候，可以利用 Knative serving，進行部署和版本管理。也就是說 Knative 是一個平臺的平臺。基於 Knative，你可以去構建更多的 Serverless 平臺或者 FaaS 平臺。
- 之前大家對 Knative 比較詬病的地方，就是它比較重，因爲它依賴於Istio。Knative 自身的安裝，可能也就幾十兆，但是裝上 Istio 之後，會佔用幾 g 內存。然而目前它已經不再強依賴於 Istio 了，Istio 只是其中一個選項。你也可以使用別的組件，比如 ambassador、Gloo、Kong 去替代它做 API Gateway。這意味着 Knative 也在逐漸的輕量化。
Serverless DevOps
函數要 build 成鏡像會有一個 build 的過程，那麼在 devops 裏這個過程就是持續交付。然後把鏡像部署到生產環境，在 devops 裏面這個過程就是持續部署，所以 Serverless 和 DevOps 也有很多結合點。
Serverless CI
Serverless 的 CI 也是需要的，但是因爲它是函數，不是一個完整的 source code，所以它有一些不一樣的地方。但是肯定也需要代碼的質量掃描、單元測試這樣的工作。
Serverless CD
對於 Serverless CD，build 的過程也就是函數的創建過程，會自動的把這個函數打包成鏡像，這是由 FaaS 平臺去完成的工作。
如果要將函數鏡像發佈到生產環境，需要進行審覈。
Serverless CI/CD 工具
build 的過程，我們可以依賴於 tekton 去管理流水線。但是從 kubernetes 1.20 開始，不再支持 docker 作爲它默認的一個運行時了，也就是說以後 kubernetes 裏可以不安裝 docker daemon。
CNCF 官方的文檔中，推薦了幾個 build docker 鏡像的工具，比如 Kaniko，img，buildah。他們各有各的優劣勢，但是有一個共同點，就是不依賴於 docker daemon。你可以用 Kaniko 在 docker 裏面 build 一個 docker 鏡像，但是不需要連接 docker daemon。
另外一個比較新興的工具是 Cloud Native Buildpacks，它更進一步，連 Dockerfile 都不需要了，根據源碼就能檢測出來，然後能夠 build 出一個 docker 鏡像。很多國外的公司，比如 Google、Pivotal，都在使用 Buildpacks。
Serverless/FaaS 痛點
目前有很多雲廠商，而且幾乎每個雲廠商都有自己的函數平臺。開源平臺又有很多。所以大家會面臨應該如何選擇的問題，另外也會有廠商鎖定的問題。
KubeSphere Serverless 路線圖
我們做 Serverless 有一個想法，能不能做一個廠商中立的 FaaS 平臺？它是一個平臺的平臺，你可以基於它去構建自己的 FaaS 平臺。
通過 KubeSphere Serverless 平臺，你可以在 kubernetes 裏邊去運行各個雲廠商的雲函數，運行開源 FaaS 平臺的雲函數。當然，運行雲廠商的雲函數有個前提，就是它的 runtime 必須是開源的。
KubeSphere Serverless 平臺大概率也會開源，到時候希望社區的小夥伴能夠積極的參與進來。
另外一個就是 Serverless 的應用，你可以把它想象成一個 deployment + service 的替代品。它有一個額外的能力，就是可以動態的擴展，然後它也能夠 scale 到 0。簡單來講，你可以提供一個 docker 鏡像，然後你就擁有了一個能夠自動伸縮的 service。
多雲及邊緣可觀察性
KubeSphere 在 3.0 版本中已經支持了多集羣的管理，將會在 3.1 版本中支持邊緣計算。所以這就產生了一個話題——多雲及邊緣計算的可觀察性。
需求和挑戰
-
多雲及邊緣集羣的全局視圖 很多用戶使用 KubeSphere 管理多集羣，希望能在一個統一的界面看到各個集羣使用資源的情況。目前這個功能還在開發中。 也有社區用戶反饋，KubeSphere 已經支持聯邦的 federated 的這種調度，能不能在一個界面看到 federated 聯邦的部署，各個集羣裏邊，對運行的資源的佔用情況，這也是一個需求。
-
跨集羣監控指標 workspace 可能是跨了幾個集羣，那麼能不能在一個界面裏面看到 KubeSphere 在 workspace 中跨集羣的資源的使用情況？
-
多雲及邊緣集羣的全局告警 因爲邊緣節點的資源是比較受限的，邊緣集羣的監控和告警怎麼解決？
-
網絡狀況各有不同 每個集羣的特點都不一樣。有的集羣能夠連接外網，也能夠被外網連接。有的集羣只能訪問外網，不能夠被 Host 集羣主動連接。
架構
針對 Member 集羣的連接方式，如果是像上圖中左上角這樣的集羣，它只能連接外網，我們就可以用 prometheus 通過 remote write，把監控數據寫到 Host 集羣的存儲上去。
對於上圖中左下角的集羣，可以雙向訪問，可以直接查詢數據，然後到 Host 集羣上做一個聚合，這樣就能夠把多集羣監控的數據展現出來了。
有的用戶尤其是企業用戶，在單個集羣上存儲的數據可能不是很多，如果只想存一兩年應該怎麼辦呢？
還有一個方案就是可以把它存儲到對象存儲中。Host 集羣上也可以去查對象存儲裏時間比較久遠的監控數據。
以上是監控的解決方案，那麼告警是怎麼解決的呢？
各個集羣可以有自定義的告警，KubeSphere 3.1 會支持這個功能。對於 Host 集羣，也可以做對於全局的監控指標的告警。KubeSphere 也有一些自己研發的組件，比如 Kube-Events、Kube-Auditing，這些組件也會發出一些告警，發到 Alertmanager 中，最後通過 Notification Manager 發到雲端。
對於邊緣集羣，它的資源比較受限，它的配置通常是兩核 4 g、一核 2 g，如果去使用 prometheus 往雲端發送數據，資源佔用會比較多。
對於邊緣節點，它的帶寬較小，如果源源不斷的把監控數據傳輸到雲端，會浪費帶寬。
我們的想法是，可以利用一些邊緣的流失處理組件，比如 EMQ 的 Kuiper 這樣的組件，然後配合我們雲端下發告警的規則，能夠實時的把邊緣的一些設備、節點的數據進行實時的過濾。當超過了閾值，就發到雲端告警。這就是對邊緣節點的支持。
本文由博客一文多發平臺 OpenWrite 發佈！