Serverless架構用來描述那些顯著或完全依賴于第三方應用或服務（“在云端”）的應用程序。這些程序經常是移動端APP或者是最近幾年比較火熱的單頁Web應用。這些應用可以完全基于云的服務進行構建，比如AWS的S3和DynamoDB或者是阿里云的OSS和TableStore。
但是總是有一些獨立的服務器邏輯代碼需要運行，傳統(tǒng)的部署方法是使用云服務器來進行進程的托管，但是FaaS (Functions as a Service)的出現(xiàn)改變了這種情況。FaaS能夠讓用戶將自己服務器邏輯代碼以Serverless的方式托管到云上，讓用戶以應用函數(shù)為單位對應用進行開發(fā)、運行、管理，無需基礎設施層面的關心構建和維護工作。
Serverless架構于2014年進入大眾視線，AWS、谷歌云、微軟Azure和IBM Bluemix等云廠商提供服務。業(yè)界認為，Serverless化可大幅降低IT成本，將云的費用減少10%-90%。可口可樂架構師Patrick Brandt曾向外媒披露，向Serverless架構轉移是主要出于降低IT運維費用并且提高服務部署效率。
2017年4月云棲大會 南京峰會，阿里云發(fā)布了函數(shù)計算產品。阿里云函數(shù)計算負責人不瞋認為，從云計算整體發(fā)展趨勢而言，Serverless的出現(xiàn)是意料之中。云計算的第一階段是基礎設施即服務，用戶能夠使用和調動大規(guī)模的計算資源；接下來需要攻關的是如何高效利用資源、更加有效的降低成本，更加彈性的面對業(yè)務波動，這就是函數(shù)計算的用武之地。InfoQ對不瞋進行了專訪，并將內容整理如下。
受訪人簡介
不瞋，函數(shù)計算研發(fā)經理。2010年加入阿里云，參與了阿里云飛天分布式系統(tǒng)的研發(fā)，歷任批量計算的架構師，表格存儲（NoSQL）研發(fā)經理，深度參與了阿里云系統(tǒng)研發(fā)和產品迭代的全過程。對大規(guī)模分布式計算，大規(guī)模數(shù)據(jù)存儲和處理有非常深入的理解。現(xiàn)為阿里云函數(shù)計算產品研發(fā)負責人，致力于構建下一代彈性、高可用的無服務器計算平臺。
什么是Serverless？什么是FaaS？
其實，廣義的Serverless覆蓋范圍很大，很多云服務產品可以被視作Serverless化的。以存儲服務的發(fā)展歷程為例：最初常見是云服務器，此種情況對用戶熟悉的原有開發(fā)方式的模擬，但是需要自行處理云服務器宕機帶來的數(shù)據(jù)不可用問題，云磁盤上的數(shù)據(jù)也不便于分享；后來，對象存儲（OSS），文件存儲（NAS），表格存儲（TableStore），消息服務（MNS）等都屬于Serverless服務。這些服務不再有機器的概念，用戶能夠享受自動的擴容和負載平衡，性能水平擴展，通過API方便的讀寫數(shù)據(jù)，易于共享，并且按實際存儲的數(shù)據(jù)量以及訪問次數(shù)付費。此外，類似阿里云大數(shù)據(jù)計算服務（MaxCompute） 也是Serverless的，提供了MapReduce，和Streaming等多種計算框架，用戶不需要管理計算資源。
Serverless是一個寬泛的概念，很多存儲、計算和中間件服務都是Serverless的。而FaaS是Serverless的子集，也是實現(xiàn)整個應用Serverless化的核心服務。FaaS的關鍵特征是：事件驅動、細粒度調用、實時彈性伸縮，無需管理服務器等底層資源。在不瞋看來，F(xiàn)aaS興起是對現(xiàn)有技術很好的補充，配合使用已有的云服務產品，即可以真正構建Serverless的應用。阿里云之所以研發(fā)FaaS產品-函數(shù)計算，也是觀察到在存儲和計算業(yè)務中，從server-base到Serverless的演變趨勢和用戶的需求。
Serverless與微服務是一脈相承的
微服務和Serverless是契合的，都強調系統(tǒng)的解耦。
將業(yè)務邏輯的實現(xiàn)拆分到Function的粒度再去實現(xiàn)，這種方法其實并不新奇；微服務本身是被越來越廣泛使用的模式，并且已經有Netflix、Uber等公司的成功經驗。用戶完全可以把一個微服務實現(xiàn)為Function。阿里云函數(shù)計算設計的一個重要目標也是使之成為以微服務方式構建應用的最好平臺。微服務式架構其實是很有挑戰(zhàn)的，在拆成成百上千的服務之后，需要高度自動化的發(fā)布部署系統(tǒng)，管理各個微服務之間的依賴。從某種角度而言，Serverless和微服務是不同層面、但又互相促進的：微服務式是開發(fā)模式，Serverless是計算平臺。
不瞋稱其個人理解是，讓Serverless這種計算平臺變成支撐微服務開發(fā)模式的最好的平臺。當越來越多公司熟悉并實踐微服務的開發(fā)模式，那么遷移到Serverless就會更順理成章，因為系統(tǒng)已經被解耦成了眾多松耦合的微服務。
所以，Serverless和微服務的未來發(fā)展是相互借力的。一個有力的例子就是，大規(guī)模使用微服務的方式構建系統(tǒng)的公司，例如Netflix，也在廣泛的使用AWS Lambda這類FaaS服務來構建Serverless應用。
但是，微服務化改造并非易事。將一個巨型單體應用以微服務的方式拆分解耦，繼而改造為Serverless應用，是采用漸進的方式逐步替換還是完全重寫？這是業(yè)界非常關心也經常討論的問題，不瞋認為需要依據(jù)情況而定：有時直接重寫更快；而在系統(tǒng)錯綜復雜的情況下，為了保險起見也可平滑過渡，一點點向微服務化演進。拆分微服務有三個考量，組織結構（參考康威定律），運維發(fā)布頻率（比如將每周發(fā)布兩次的服務與每兩個月發(fā)布一次的服務進行拆分）和邏輯調用頻度（將高頻調用邏輯和低頻調用邏輯分開，在Serverless架構下能夠進一步降低成本）。以上三點需根據(jù)業(yè)務需求情況進行綜合考量，沒有普適性的優(yōu)先級之分。
Serverless適用的兩大場景
場景一：應用負載有顯著的波峰波谷
Serverless化與否的評判標準并不是公司規(guī)模的大小，而是其業(yè)務背后的具體技術問題，比如業(yè)務波峰波谷明顯，如何實現(xiàn)削峰填谷。一個公司的業(yè)務負載具有波峰波谷時，機器資源要按照峰值需求預估；而在波谷時期機器利用率則明顯下降，因為不能進行資源復用而導致浪費。
業(yè)界普遍共識是，當自有機器的利用率小于30%，使用Serverless后會有顯著的效率提升。對于云廠商，在具備了足夠多的用戶之后，各種波峰波谷疊加后平穩(wěn)化，聚合之后資源復用性更高。比如，外賣企業(yè)負載高峰是在用餐時期，安防行業(yè)的負載高峰則是夜間，這是受各個企業(yè)業(yè)務定位所限的；而對于一個云廠商，如果其平臺足夠大，用戶足夠多，是不會有明顯的波峰波谷的現(xiàn)象的。
場景二：典型用例-基于事件的數(shù)據(jù)處理
視頻處理的后端系統(tǒng)，常見功能需求如下：視頻轉碼、抽取數(shù)據(jù)、人臉識別等，這些均為通用計算任務，可由函數(shù)計算執(zhí)行。
開發(fā)者需要自己寫出實現(xiàn)邏輯，再將任務按照控制流連接起來，每個任務的具體執(zhí)行由云廠商來負責。如此，開發(fā)變得更便捷，并且構建的系統(tǒng)天然高可用、實時彈性伸縮，用戶不需要關心機器層面問題。
使用小tips：函數(shù)的執(zhí)行本身是無狀態(tài)的，如果要持久化數(shù)據(jù)則需使用OSS等存儲服務。雖然用戶可以使用本地的磁盤，但是需要假定這些數(shù)據(jù)在函數(shù)執(zhí)行完成后就不再需要了。
Serverless會帶來哪些沖擊？
Serverless不等于沒有運維，但是運維內容變了。
在Serverless出現(xiàn)之前，用戶運維時要考慮機器掛了怎么辦，連接數(shù)暴漲了怎么辦等等。
用戶用云，從某種意義上講是為了提高效率，而效率又分為開發(fā)效率、運維效率和成本效率。Serverless之后，運維從事的更多是業(yè)務運維，摸清依賴關系，設定監(jiān)控項進行健康報警。
運維不再負責機器運維，而是業(yè)務運維。比如函數(shù)A調用函數(shù)B，這樣的依賴關系是否合理；從業(yè)務邏輯上去評估哪些關鍵路徑需要報警，哪些是允許失敗的。原來的機器運維需要關心配置問題、操作系統(tǒng)、Kernel升級和網絡設定等。所以其實Serverless更加推動了DevOps，Ops工作被改變了，Serverless對開發(fā)人員也更加友好。
長遠而講，會沖擊傳統(tǒng)PaaS
如果Serverless平臺可以解決通用問題，并且有吸引力，那確實會對傳統(tǒng)的云計算有沖擊；但是，這是個漸進的過程。Serverless可以部署在公有云、私有云和混合云上。（備注：目前阿里云推出的產品尚限于公有云。）
在不瞋看來，Cloud-Native應用是指基于各種云的服務構建的高可用、可伸縮的應用。例如通過函數(shù)計算實現(xiàn)控制流邏輯、整合對象存儲、離線數(shù)據(jù)處理等云服務，就能快速搭建一個實時彈性伸縮、高可用的業(yè)務系統(tǒng)。因此Serverless是構建Cloud-Native應用的理想方式。
開發(fā)模式和職責的改變
未來，Serverless一旦流行開來，用戶可以依托于云計算廠商提供的平臺類服務，快速構建彈性高可用的系統(tǒng)，從而專注于業(yè)務邏輯的創(chuàng)新。
四問阿里云的函數(shù)計算
阿里云函數(shù)計算是不是一種跟風行為？
函數(shù)即服務（FaaS）并非阿里云首創(chuàng)，2014年10月hook.io推出了首個FaaS服務。同年AWS Lambda問世，2016年Google Cloud Functions 和 Microsoft Azure Functions相繼商用化，具備開源版和商用版IBM Bluemix的OpenWhisk也提供類似的功能。Uber曾經演示過其私有云平臺如何構建去模式化觸發(fā)（Schemaless triggers），和云廠商的FaaS服務有異曲同工之妙的（https://eng.uber.com/schemaless-part-three/）。
不瞋稱，函數(shù)計算的推出其實是因為客戶在使用過程中產生了這種需求，并且同時也確實契合了云的發(fā)展趨勢。
阿里云做產品是由用戶需求驅動，比如觀察到用戶在使用OSS對象存儲時，通常需要由存儲事件觸發(fā)的數(shù)據(jù)處理。例如在音視頻行業(yè)中，上傳的視頻文件通常會進行轉碼、鑒黃等處理。通過對這些需求的分析，然后去思考是否可以抽象為通用的技術解決方案。這是主要驅動力，當然同時也會觀察業(yè)界的發(fā)展，不過本質上還是與所服務用戶的需求相關。
從什么時候開始積累函數(shù)計算的技術能力？
函數(shù)計算的技術可以分成兩個部分去看：
第一部分是服務的內核：包括資源動態(tài)的調度，用戶函數(shù)的隔離運行，還有自動的負載均衡和流控，這是后臺必須要具備的能力。
第二部分是服務的外延：當提供成計算服務供其他人去使用時，平臺需要為用戶提供優(yōu)秀的debugging和tracing能力、函數(shù)依賴的管理、持續(xù)集成持續(xù)發(fā)布等功能。
對于內核部分的技術，包括資源的調度，程序運行的隔離等等，阿里云飛天計算平臺有長期的積累。相對而言，外延部分比較新；業(yè)界也處于早期階段，目前尚沒有統(tǒng)一的廠商構建標準，還有很大的發(fā)展空間。打造好的服務外延的出發(fā)點是，怎么可以讓用戶基于函數(shù)計算構建復雜的Serverless應用，只有解決了這個本質問題，函數(shù)計算才能變成主流的通用計算服務。
除了函數(shù)計算技術本身，，函數(shù)計算的產品生態(tài)非常重要，函數(shù)計算本身是事件、消息和數(shù)據(jù)驅動的計算模式，還需要其他云服務與之協(xié)同配合應用于不同的場景中，比如OSS的多媒體數(shù)據(jù)寫入和訪問、LogService的日志、API Gateway的請求、消息服務的消息到達，這些都為函數(shù)計算的技術生態(tài)提供了協(xié)作關系。此外，對于數(shù)據(jù)處理方案，不瞋稱用戶也可以接入第三方的數(shù)據(jù)處理服務。
按需付費，如何面對“缺斤短兩”的問題？
Serverless計算的一個核心優(yōu)勢是按需付費。因此關鍵的問題是，如何讓用戶能很容易預估費用？如何證明費用的真實性？
不瞋稱，云服務的費用問題不是新問題，Serverless服務需要給用戶提供簡潔的，易于預估的費用模型，非常豐富的計量指標和細粒度的賬單，讓用戶能夠推敲驗證。
此外，好的產品設計還需要考慮到如何幫用戶規(guī)避錯誤。有時候用戶實現(xiàn)的函數(shù)邏輯可能會有bug，導致突然間錯誤消耗大量資源，比如在具有巨大計算能力的云平臺上寫出了無限遞歸調用的函數(shù)；在這個方面，不瞋稱阿里云也有考量，函數(shù)計算允許用戶設置費用上限，并且提供豐富的監(jiān)控和報警功能，幫助用戶減少因為自身失誤帶來的資源過度使用的損失。
函數(shù)計算產品短期和長期的目標是什么？
阿里云的FaaS產品與業(yè)界相比的差異在哪里？坦白講，目前還在發(fā)展的初期階段，未來則會根據(jù)用戶場景進行不斷優(yōu)化。目前使用函數(shù)計算的用戶來自于電商、游戲、IoT等領域，用戶的主要訴求是可以專注于業(yè)務邏輯開發(fā)，不再維護后端服務器；此外用戶也非常看重按需付費，削峰填谷等特性。
短期主攻數(shù)個典型的用戶場景，打造出尖銳的用戶體驗，自下向上的積累理解和經驗。阿里云的函數(shù)計算目前還只支持Node.js，在多語言支持上有待提高。還有一種做法是去語言化，定一個與語言無關的http交互協(xié)議。但是后者的使用門檻稍微高一些：前者是寫一個Function，而后者卻需要用戶實現(xiàn)一個mini web server。
在此基礎上，從云發(fā)展的宏觀角度思考，自上而下地制定中長期目標。持續(xù)改進服務的內核和外延能力，讓平臺變成構建復雜應用的核心計算平臺。
還有，如何拓展技術的邊界，計算場景是否可以發(fā)生在不同的計算環(huán)境中，不同的計算介質如FPGA、GPU、邊緣節(jié)點、端設備。其中邊緣節(jié)點計算需求在工控領域中尤為突出，比如如何收集偏遠地區(qū)風力發(fā)電站的數(shù)據(jù)以實現(xiàn)智能化？在惡劣環(huán)境下，網絡傳輸并不總是可靠且成本很高，這時就需要在本地對數(shù)據(jù)進行處理，然后再將提煉的數(shù)據(jù)傳到云端。為什么這種情況函數(shù)計算適合？因為它已經脫離了機器概念，抽象出了統(tǒng)一的計算模型去支撐云端和邊緣計算。
基于Serverless寫的程序，是不需要考慮如何部署、管控和重度運維。用戶可以自己在遠端的辦公室進行調控，比如將某些計算任務部署到邊緣節(jié)點上，實現(xiàn)和云端類似的監(jiān)控，在網絡良好時，再進行數(shù)據(jù)的傳輸。而且在本地對噪聲數(shù)據(jù)進行處理提煉，能有效的降低傳輸?shù)皆贫说臄?shù)據(jù)量，大幅降低成本。
Serverless未來光明，但挑戰(zhàn)猶在
比起微服務、DevOps，Serverless的落地和流行將更快。
使用函數(shù)計算構建Serverless架構，以很高的開發(fā)效率去構建一個系統(tǒng)，并且這個系統(tǒng)天然就是實時可伸縮的。對于用戶而言，良好落地Serverless的要點主要在于架構設計，用戶需要首先理解Serverless，然后從現(xiàn)有的業(yè)務中提煉出業(yè)務邏輯。即Serverless流行起來難度不在于開發(fā)門檻，而在于思維和架構的轉變。如果熟知微服務，對Serverless的理解會更加方便。
正如前文所說，Serverless讓微服務的實現(xiàn)更輕松，更適應基于微服務的松耦合系統(tǒng)設計。但是反觀微服務化和DevOps改造實施起來比較重，技術門檻不低。而Serverless很輕，和微服務的目標趨同，但是發(fā)布、運維等環(huán)節(jié)的云服務化更徹底；用戶只需設定資源和發(fā)布部署等規(guī)則，因此Serverless會更加容易落地。
不過，Serverless對于用戶而言，還是很新的概念。縱然DevOps、微服務等已經被廣泛認知了，但是全面落地尚且遙遠，怎么看待Serverless的推進呢？任何新的概念的落地，本質上都是要和具體業(yè)務去結合，去真正解決具體問題。這要取決于，一開發(fā)人員對技術的理解度，二是用戶在實施中的漸進與積累，三是企業(yè)對按需付費的強烈意愿。
沒有什么業(yè)務需求是空穴來風，也沒有什么技術發(fā)展是一蹴而就。
京公網安備 11010502049343號