什么是Serverless
目前，開發人員使用OpenStack或Kubernetes進行業務開發時，仍然需要關心很多和虛機、容器相關的后端工作，如應用的負載均衡，虛機的存儲和計算資源，橫向/縱向的擴展能力，甚至容災穩定性等非專業邏輯的開發。這些后端的運維和開發知識降低了開發者的開發效率。
如果云平臺能自動解決上述問題，讓開發者只專注于業務邏輯，云平臺負責應用的部署和運行，這樣是否可以提升開發效率和產品質量？這種不用關心后端如何支撐服務運行而只需要實現服務本身的理念，稱之為Serverless。
Serverless有一個更具有描述性的名字是FaaS(Function as a service)，就像IaaS、PaaS、SaaS一樣，FaaS是云計算的一種。通過FaaS，用戶為應用的某一特定功能購買必要的功能。
Serverless也可以指一部分服務邏輯由應用實現，但跟傳統架構不同在于，他們運行于無狀態的容器中，可以由事件觸發、生命周期短暫、完全被云平臺管理。這種思路是Functions as a Service / FaaS。用戶通過云平臺可以運行自定義的代碼（函數），函數是無服務器架構中抽象語言運行時的最小單位。
Serverless的使用場景
Serverless架構主要分為以下特點
實現了細粒度的計算資源分配
不需要預先分配資源
具備真正意義上的高度擴容和彈性
按需使用，按需計費
根據Serverless的這些通用特點，歸納出下面幾種典型使用場景，供大家參考
-
低頻請求
在物聯網行業中，由于物聯網設備傳輸數據量小，且往往是固定時間間隔進行數據傳輸，因此經常涉及低頻請求場景。
例如：物聯網應用程序每分鐘僅運行一次，每次運行50ms，這意味著CPU的使用率為0.1%/小時，這也意味著其實有1000個相同的應用可以共享計算資源。而Serverless架構下，用戶可以購買每分鐘100ms的資源來滿足計算需求，通過這種方式就能夠有效解決效率問題，降低使用成本。
-
定制事件
例如用戶注冊時發郵件驗證郵箱地址，通過定制的事件來觸發后續的注冊流程，而無需再配置額外的應用來處理后續的請求。
-
固定時間觸發
事件觸發固定時間觸發，例如在夜間或者服務空閑時間來處理繁忙時候的交易數據，或者運行批量數據，來生成數據報表，通過Serverless方式，不用再額外購買利用率并不高的處理資源。
-
流量突發型事件
移動互聯網應用經常會面對突發流量場景。例如：移動應用的通常流量情況是QPS 20，但每隔5分鐘會有一個持續10s的QPS 200流量（10倍于通常流量）。在Serverless架構下，開發人員可以利用彈性擴展特性，快速構建新的計算能力來滿足當前需求，當業務高峰后，資源能夠自動釋放，有效節省成本。
使用案例（新浪微博 × 阿里云）
用戶需求
微博客戶端上顯示多種格式的圖片，為了適配不同的手機屏幕和操作系統，需要對圖片進行個性化 的處理。微博有海量用戶，系統每日要能處理海量的調用請求，并保持穩定的延時。
解決方案
微博將用戶上傳的圖片存儲到阿里云對象存儲中，在函數中實現個性化的圖片處理邏輯。手機客戶端 獲取圖片時，通過阿里云 CDN 服務回源到函數計算，函數從阿里云對象存儲中下載原圖，實時處理后將結果圖片返回。
使用效果
開發人員只需要專注于圖片處理邏輯的開發，工程效率大幅提高。函數計算自動實時擴容底層計算資源，確保應用在負載動態變化時仍能保持穩定的延時，平滑處理海量的調用請求。使得微博不再為峰值負載預留計算資源，降低了成本。
Serverless的實施
OpenStack中的Serverless方案
OpenStack中發起了新的項目，名字叫做 Qinling （ 靈感來自于中國的秦嶺山脈 ），目標就是在 OpenStack 平臺上提供 Function as a Service 的功能。
Qinling利用OpenStack中已有的組件來支撐用戶自定的Function運行。OpenStack提供豐富的IaaS層資源以及用戶驗證（ Keystone ），事件監控（ Adoh ），負載均衡等功能。用戶自定義Function可以靈活地利用這些資源和服務達到效果。
目前Qinling支持的功能比較簡單，對應的實現也比較簡單：
- 用戶通過代碼的方式定義Function的行為。
- 通過Qinling的CLI，指定代碼文件創建Function。
- Qinling收到請求之后， 獲取用戶指定的代碼文件，生成Docker image，通過Container COE以容器的方式運行用戶定義的Function，執行結束回收這個容器。
最后，值得注意的是，目前Qinling只支持OpenStack Rocky以上版本
