1. 頭條 ByteFaas 架構(gòu)

來自：掘金2022開發(fā)者大會微服務(wù)與Serverless（侵權(quán)刪）

如何解決冷啟動問題

• 減少冷啟動頻率

• 減少冷啟動速度

2. Knative 如何解決的調(diào)度：

Autoscaler（自動伸縮器）和 Activator（激活器）

Knative Serving為每個Pod注入QUEUE代理容器（queue-proxy），該容器負(fù)責(zé)向Autoscaler匯報業(yè)務(wù)容器的并發(fā)指標(biāo)。Autoscaler接收到這些指標(biāo)之后，會根據(jù)并發(fā)請求數(shù)及相應(yīng)的算法，調(diào)整Deployment的Pod數(shù)量，從而實現(xiàn)自動擴(kuò)縮容

基于流量請求數(shù)實現(xiàn)服務(wù)自動擴(kuò)縮容

Autoscaler基于每個Pod的平均請求數(shù)（并發(fā)數(shù)）進(jìn)行自動擴(kuò)縮容，默認(rèn)并發(fā)數(shù)為100。Pod數(shù)=并發(fā)請求總數(shù)/容器并發(fā)數(shù)。如果服務(wù)中并發(fā)數(shù)設(shè)置為10，并且加載了50個并發(fā)請求的服務(wù)，則Autoscaler就會創(chuàng)建5個Pod。Autoscaler實現(xiàn)了兩種操作模式的縮放算法，Stable穩(wěn)定模式和Panic恐慌模式：

• Stable穩(wěn)定模式。在穩(wěn)定模式下，Autoscaler調(diào)整Deployment的大小，以實現(xiàn)每個Pod所需的平均并發(fā)數(shù)。Pod的并發(fā)數(shù)是根據(jù)60秒窗口內(nèi)接收所有數(shù)據(jù)請求的平均數(shù)來計算的。

• Panic恐慌模式。Autoscaler計算60秒窗口內(nèi)的平均并發(fā)數(shù)，系統(tǒng)需要1分鐘穩(wěn)定在所需的并發(fā)級別。但是，Autoscaler也會計算6秒的恐慌窗口，如果該窗口達(dá)到目標(biāo)并發(fā)的2倍，則會進(jìn)入恐慌模式。在恐慌模式下，Autoscaler在更短、更敏感的緊急窗口上工作。一旦緊急情況持續(xù)60秒后，Autoscaler將返回初始的60秒穩(wěn)定窗口。

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? | ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Panic Target---> ?+--| 20 ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ?| ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| <------Panic Window ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?| ?| ? ? ? Stable Target---> ?+-------------------------|--| 10 ? CONCURRENCY ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? | ?| ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ?<-----------Stable Window ? ? ? ? ? ? ? ? ? ? ? ? ?| ? ? ? ? ? ? ? ? ? ? ? ? | ?| --------------------------+-------------------------+--+ 0 120 ? ? ? ? ? ? ? ? ? ? ? 60 ? ? ? ? ? ? ? ? ? ? ? ? ? 0 ? ? ? ? ? ? ? ? ? ? TIME

3. KEDA 一個基于事件驅(qū)動的伸縮控制器

keda是一個基于事件驅(qū)動的伸縮控制器，可以實現(xiàn)應(yīng)用縮容至0，以及從0開始擴(kuò)容。目前已支持像CPU/Memroy、Mysql、Prometheus、Redis等20多種事件來源(Scaler)。

參考

knative指南