1.2.2 Nuclio的架構設計

Nuclio試圖描述并抽象出所有事件信息，當事件發生時（例如，將消息記錄寫入Kafka時、發起一個HTTP請求時、計時器到期時等）能夠將事件信息發送給一段代碼邏輯來處理。為了實現這個目標，Nuclio希望用戶可以（至少）提供關于什么可以觸發一個事件并且在發生此類事件時應該由哪一段代碼邏輯來進行處理的詳細信息。用戶可以通過命令行工具（nuctl）、REST API或者一個可視化的Web端應用程序來描述。Nuclio的架構如圖1-2所示。

Nuclio獲取信息（通常稱為函數處理程序（Handler）和函數配置（Configuration））并發送給構建器（包含在用戶儀表盤（DashBoard）中）。構建器將制作函數的容器鏡像，其中包含用戶提供的函數處理程序及一個可以在接收到事件后執行該函數處理程序的函數處理器（Processor）。然后，構建器將該容器鏡像發布到容器鏡像倉庫中，容器鏡像倉庫可以是DockerHub等開源倉庫也可以是私有鏡像倉庫。在開發、生產中建議使用私有倉庫，這樣函數構建運行速度會加快（私有鏡像倉庫的鏡像上傳和下載速度會比公網快很多）。一旦發布完成，這個函數的容器鏡像就可以被部署了。

圖1-2 Nuclio的架構

控制器將從函數的配置中生成編排平臺所需的特定配置文件。例如，如果是部署在Kubernetes集群中，控制器將會讀取配置文件中的副本數量、自動縮容時間、函數需要的CPU和GPU數量等參數，并將它們轉化為Kubernetes的資源配置（例如，Deployment、Service、Ingress等）。

Kubernetes將會從已經發布的容器鏡像中啟動容器并執行它們，并將函數的配置文件傳遞到容器中。這些容器的入口點（Entrypoint）就是“處理器”，它負責讀取配置文件、監聽事件觸發器（例如，連接到Kafka、監聽HTTP端口等），當事件發生時，讀取事件并調用用戶的函數處理程序。處理器還負責很多其他的事情，包括處理指標、編碼響應及崩潰等。

一旦構建并部署到Kubernetes這樣的編排平臺中，Nuclio函數（即處理器）就可以處理事件，并根據性能指標、發送日志等進行擴縮容，所有這些都不需要任何外部實體的幫助。部署完成后就可以關閉Nuclio的儀表盤和控制器了，Nuclio函數依然可以完成運行和伸縮容。

但是，縮容為零的能力單單依靠函數自身是無法完成的。相反地，一旦縮容為零，當一個新的事件到達時，Nuclio函數無法完成自己的擴容操作。為此，Nuclio有一個擴縮容服務，它解決了將函數縮容為零，以及從零開始擴容的問題。

縮容為零（AutoScaler）服務定時從Kubernetes中查詢指標數據，以決定服務是否進行縮放。決定的依據來源于用戶事先的配置，如在10min中沒有請求到達，服務就會縮容為零。查詢的間隔時間也是由用戶指定的。

DLX（Dead Letter Exchange，死信交換）是當請求首次到達系統時，它會創建一個緩沖區，并結合函數的實際情況更改函數的狀態，然后交由控制器將副本設置為大于零的值，完成從零開始的擴容功能。當服務就緒后，修改對應函數Service（Service是Kubernets中的一個概念，它是將運行在一個或一組Pod上的網絡應用程序公開為網絡服務的方法）中的選擇器，將流量路由回函數服務，這樣再次請求就會路由到對應的函數。后續監控會采集服務指標，以供AutoScaler服務進行決策。