關注阿里云官方Serverless微信公眾號阿里云開發者“藏經閣”前言隨著云計算的不斷發展，Serverless架構逐漸成為了近些年來會引領云計算下一個十年的技術架構，Serverless架構一方面繼承云計算優點的同時，另一方面也為業務帶來了極致彈性、按量付費、低運維等優勢；在Serverles的技術選型之時，其也暴露出了包括調試困難，廠商鎖定嚴重，為什么寫作本書低運維等特性，在很多領域發揮著越來越重要的作用；而伴隨著Serverless架構越發火熱，Serverless架構在工具鏈層面的匱乏逐漸顯露；以提高研發效能為核心優勢之一的Serverless架構，因為沒有完善的工具鏈體系，導致開發困難、調試困難、管理困難、運維困難；此時ServerlessDevs應運而生，在Serverless架構持續賦能傳統應用整體效能提升的同時，關于本書作者劉宇：國防科技大學電子信息專業博士；阿里云Serverless產品經理，開源項目Serverless本書主要內容第三章：通過一些常見的，有趣的AI案例，幫助讀者可以更為深入的學習和了解Serverless如何閱讀本書第一遍先將書通讀，主要弄清楚概念，再完成ServerlessDevs的基礎入門，并對基于第二遍通過對本書在不同領域的實踐案例，進行進一步的學習和探索，了解Serverless會存在失效的情況，但是筆者會盡快在每個案例的代碼倉庫中更新代碼，希望讀者可以切實利致謝（筱姜在本書對外宣傳過程中給予的幫助和支持；感謝、羅松（西流）、張千風（千2.快速入門與功能案例3.Serverless架構下AI最佳實踐5.Serverless應用開發經1.1從云計算到Serverless來，計算機科學與技術的發展就從未停止過前進的腳步，尤其是近些年計算機的發展更是日新可以認為是云計算的一個“最初的”，“超前的”遐想模型，它翻SUN公司聯合創始人JohnGage（約翰·蓋奇） 密特（EricSchmidt）在搜索引擎大會（SESSanJose2006）首次公開正式地提出“云計算”在最近正快速變為商業現實。在該文章中，明確的為云計算做了定義：云計算包含互聯網上的應用服務及在數據中心提供這些服務的軟硬件設施。同時在該文章中，也提出了云計算所面臨快遞硬盤；數據備份/獲取；更加低的廣域網路由開銷；更高帶寬大規模分布式系統中的錯誤江蘇南京建立首個“電子商務云計算中心”（即現在的次將“Serverless”這個詞帶進了大眾的視野。2014年Amazon發布了AWSLambda讓體系結構，至此再也不需要在服務器上持續運行進程以等待HTTP請求或API調此后AntStanley在2015年7月名為ServerareDead**…的文章中更是圍繞著AWSLambda及剛剛發布的AWSAPIGateway這兩個服務解釋了他心目中的Serverless，并說Serverless翻譯成中文是無服務器，所謂的無服務器并非是說不需要依靠服務器說開發者再也不用過多考慮服務器的問題，可以更專注在產品代為服務出現，而不是作為服務器的概念出現，Serverless是一種構建和管理基于微服完整流程，允許用戶在服務部署級別而不是服務器部署級別來管理用戶的應用部署。與傳統架能只存在于一次調用的過程中）在計算容器內，Serverless部署應用無需涉及更多的基礎設施注于單一責任與功能的小型功能塊為基礎，利用模組化的方式組合出復雜的大型應用程序，那小的程序單元。例如，可以通過微服務代表為某個客戶執行所有CRUD操作所需的代碼，而賬戶”事件后，將通過函數的方式執行相應的“函數”。單就這一層意思來說lPlatform9首席執行官SirishRaghuram：Kubernetes將在Serverless產品－AWSTwoStepsBack任何一個新的技術、概念出現都會遇到一定的挑戰和擔憂，就如同當年云計算出現時，也被一經歷各種挑戰和質疑之后，才能更茁壯地成長，Serverless也不例外，從2019年開始，ss而言是非常關鍵的一年，也是Serverless具有里程碑式發展的一年，被很多人定義為云計算的下一個十年，Serverless迅速地，未來的方向和形態卻是模糊的，沒人知道云計算的終態是什么。誠然，現在有人說1.2Serverless架構簡介仍然在圍繞著服務器轉。不過，這不會持續太久，云應用行了進一步完善描述：Serverless是指構建和運行不需要服務器管理的應用程序概念。它描述擴展和計費，以響應當時確切的需求。與此同時，在2019年UCBerkeley的文章《ClProgrammingSimplified:ABerkeleyViewonServerlessComputing》中也同樣從概念也有相關的描述：無服務器（即Serverless）是一種架構理念，其核心思想是將提供服務按使用收費。這種架構體系結構消除了對傳統的海量持續在線服務器組件的需求，降低了開發和運維的復雜性，降低運營成本并縮短了業務系統的交付周期，使得用戶能夠更高的業務邏輯的開發上。至此，Serve1.3Serverless架構應用場景焦業務的核心價值。Serverless架構作為云原生技術未來的演進方向，無服務器架構技術的企業部署無服務器架構。Serverless將進一步釋放云計算的能力，將安全、可靠、可伸縮等需求交由基礎設施實現，使用戶僅需關注業務邏輯而無需關注具體部署和運行，極大地提高應用開發效率。同時這個方式促進了社會分工協作，云廠商可以進一步通過規模化、集約化實現由此可見，Serverless架構將會成為采納，成為其技術選型。那么再進一步的深究，Serverless在什么場景下可以有非常優秀的表現，在什么類型的場景下可能表現得并不是很理務CNCFServerlessWhitepaperv1.0在描述Serverl景包括視頻處理、數據ETL處理等；API網關更多會為用戶賦能對外的訪問鏈接以及相關聯的1.3.1Web應用/移動應用后端1.3.2實時文件/數據處理視頻應用、社交應用等場景下，用戶上傳的圖片、音視頻往往總量大、頻率高，對處理系統的實時性和并發能力都有較高的要求。例如：對于用戶上傳的圖片，可以使用多個函數對其分別配置對數據進行實時處理，例如：對對象存儲壓縮包進行解壓、對日志或數據庫中的數據進行1.3.3離線數據處理通過對象存儲相關觸發器觸發數據拆分函數進行相關數據或者任務的拆分，然后再調用相關處易情況并整理出該時段交易量top5；每天處理一遍秒殺網站的交易流日志獲取因的錯誤從而分析商品熱度和趨勢等。函數計算近乎無限擴容的能力可以使用戶輕松地進行大容1.3.4人工智能領域裝在調用函數中，在實際用戶請求到達時再運行代碼。相對于傳統的推理預測，這樣做的好處1.3.5IoT等物聯網領域目前很多廠商都在推出自己的智能音箱產品，用戶可通過互聯網將這句話傳遞給后端服務，然后獲得到反饋結果，再返回給用戶。通過Server1.3.6監控與自動化運維監控的網址和預期的時間閾值，由監控平臺部署在各地區的服務器定期發起請求對網站或服務說大部分的監控平臺很難直接實現，所以定制開發一個網站狀態監控工具就顯得尤為重要。除此之外，在實際的生產運維中，還非常有必要對所使用Serverless架構的很重要的一個應用場景就是運維、監控與告警，通過與定時觸發器進行結合1.4ServerlessDevs簡介1.4.1工具鏈建設的必要性所謂的工具鏈匱乏，一方面表現在市面上工具鏈不完善鏈的匱乏導致本來就擔心被廠商綁定的Serverless開發者變得更難與廠商解綁。2020具集完善程度，這些數據背后透露的實際上是：開發者對于完善工具鏈的強烈需求。盡管，有上通過各個云廠商的控制臺進行函數的創建、更新也會更為方便。但是不可否定的是，發工具、運維工具，尤其在開發態的調試如何保證線上線下環境的一致性；如何在運維態可綜上所述，作為可以提升Serverless應用開發效能，降低Serverless架構使用難度的項目，還可以在Serverless應用全生命周期進行項目的管理，并且非常簡單快速的將1.4.2六大優勢l開源形式建設：項目通過開源代碼，開放生態進行建設，開發者可以隨時查看和參與1.4.5設計哲學lServerless開發者：通過開發者工具（包括命令行工具以及桌面端等工lServerlessRegistry：類似于一種組件、應用的管理工具或者規范模型；類似于PythonlComponent：指的是組件；是由Packagedeveloper開發并發布的符合Serverless開發者工具被加載，并按照預定的規則進行執行某些動作。例如，將用戶的代碼部署到效率，通過該模型，開發者可以通過一種更靈活、更通用的方法使用不同云廠商以及開源的本，更是從簡單的效能提升，變成了更加規范、更加科學的效能提升。希望可以通過11月，ServerlessDevs被CNCFLandsacpe收錄,成為國內首個進駐的12月，ServerlessDeveloperMeetup在深圳召開，并嘗試性的對外展示了1.5阿里云函數計算（FC）組件簡介1.5.1ServerlessDevs和FC組件的關系1.5.2五大亮點1.5.3功能支持指標查詢2.1ServerlessDevs基礎入門2.1.1工具安裝2.1.2密鑰配置獲取密鑰命令式密鑰配置通過環境變量配置有相當一部分的開發者會將密鑰信息放在環境變量中，這樣在使用工具的時候，就需要從環境變量中讀取密鑰信息，此時，通過環境變量配置密鑰的方法就顯得尤為重要，為此，密鑰使用注意事項.1安全相關威脅。強烈建議開發者遵循阿里云安全最佳實踐，使用RAM子用戶AccessKey來進行.2關于密鑰配置中Alias的設計思路l有兩個賬號，分別是阿里云賬號和騰訊云賬號，那么配置密鑰的時候就可以設置別名.3密鑰使用方法/.4密鑰使用順序相關l使用通過環境變量配置的``default_serverless_devs_access`密鑰信息.5密鑰的其他相關操作2.1.3Yaml的使用規范l格式必須符合Yaml規范元數據相關描述accessvarsServiceaccessactions變量賦值服務順序行為描述通過命令操作應用備任何業務相關的能力（值得包括不限于函數的部署、應用的構建、項目的測試等所以，。。。test.1應用級操作服務在執行過程中出現了錯誤，系統則會報錯，并終止下一步的操作，此時，系統的exit.2服務級操作2.1.4多種操作模式下的工具體系眾所周之，目前大部分的Serverless開發者工具均是通過Yaml等進行資源描述，少部分的特點對比行為描述的Yaml文件的應用目錄下，執行組件對可以一鍵部署一個完整可以通過該命令一鍵部候與一些自動化部署、運維等批量操作時更在任何目錄下，通過子命非常簡單的與自動化流Yaml格式/規范的學習對于一些復雜項令行中寫過多的更適合項目的設計思路例如想要查看某個服務下的函數列表，查看某個地區下的服務列表，因為這樣一2.2案例與體驗2.2.1項目上手體驗l此時只需要選擇對應的選項，按照引導進行操作，即可。例如選擇AlibabaCloud數---2.2.2功能上手體驗測試項目創建...--調用相關.2指標查看其他功能d/。。2.3讓發布更安全的：線上異動感知本地記錄的服務本地記錄的函數本地要部署服務本地要部署函數與線上與線上--互線上服務與函數將會被線上服務與函數不做任在與線上---互線上服務與函數將會被線上服務不做任何操在在----互線上服務與函數將會被線上服務與函數將會被本地記錄的服務本地記錄的函數本地要部署服務本地要部署函數與線上與線上與線上與線上互線上服務與函數將會被線上服務與函數不做任與線上與線上與線上與線上互線上服務與函數將會被線上服務與函數不做任2.3.1部署前檢測2.3.2部署異動感知2.3.3在自動化流程中的策略2.4性能心中有數：一鍵壓測函數計算2.4.1實現原理2.4.2操作案例2.5從工具看函數資源評估2.5.1內存探測模式本示例以探測CPU密集型場景事件函數為例，介紹如何實現內存模式的探測。請執行以下命式下分別被調用十次后取平均值，例如目標函數在128MB內存格式下被調用十次后取平均值，最終對目標函數在這四個不同內存模式下分別被調用十次后的平均值進行對比，獲取探測......l圖中紅色的線表示執行時間與內存大小的關系；藍色的線表示。。。。2.5.2并發度探測模式......。。。。2.6ServerlessDevs與Funcraft/Fcli的對比2.6.1形式對比????2.6.2功能對比??????????????????層?????????2.6.3場景對比?義，例如部署前需要進行build，部署后需要進行版??的調試等。?在進行項目部署時，Yaml需要從環境變量獲取一些敏感???2.6.4遷移案例從Funcraft遷資源信息重新同步：這種方法是將線上的函數資源，直接同步到本地，包括線上函數的代碼和3.1PaddleOCR項目開發與部署增強、學習率變換策略、正則化參數選擇、預訓練模型使用以及模型自動裁剪量化8個方面，3.1.1本地開發通過將圖片轉換為Base64編碼，并以POST方法請求剛剛啟動的Web服務，可以看到3.1.2部署到Serverless架構部署前準備項目部署項目測試3.1.3項目優化通過冷啟動與熱啟動的對比，可以發現，在熱啟動時，l部分流程進行優化，例如在PaddleOCR項目中有明確說明：“paddleocr會自動下載中，相對比熱啟動還增加了一個模型下載和解壓的流程，所以這一部分在必要時是可以打入3.2Tensorflow與目標檢測系統一步封裝，ImageAI項目提供用于圖像預測的4種算法包括SqueezeNet，ResNet，3.2.1本地開發如果在使用過程中覺得模型resnet3.2.2部署到Serverless架構部署前準備在本地完成ImageAI的基本測試運行之后，可以將項目部署到Serverless架構上。在項目部署項目測試可以看到，預測結果和前文在本地執行的結果是一致的。至此，已經成功的將本地的3.2.3項目優化由于FaaS平臺的環境在很多情況下都會和開發者的本地環境有一定的差異，所以些需要編譯的依賴時會存在一定的無法跨平臺運行，所以此時就需要準備和FaaS平臺一致這種比較細粒度的功能開發往往會給后期的項目維護帶來了極大的不便，包括不限于函數管理更加科學、安全的持續集成和部署過程，不僅僅會讓整體的業務流程更加規范，也會在一定程4.1.1與GithubAction的集成密鑰和對應的Key配置到GithubSecrets中，例如在上面的案例中，需要AccessKeyID,關于密鑰的配置：密鑰信息的獲取是通過$*進行獲取的，所以此時，需要將所需要的密鑰應的Key配置到Gitee的環境變量管理即可，例如在上面的案例中，需要ACCESSKEYID,4.1.3與Jenkins的集成在準備將ServerlessDevs集成到}}}}}}}_4.1.4與云效的集成4.2CustomContainer的CI/CD最佳實踐案例4.2.1實驗準備。。。4.2.2流程自定義Setup.sh流程l在本例子中dockerbuild行為是由ServerlessDevs幫做的，但是此出也可以不選擇s自定義Setup.sh流程4.2.3項目測試4.2.4案例總結與注意事項如果配置的密鑰權限不夠（例如是子賬號則可能會導致用戶無法創建某些權限，進而導致4.3基于GiteeGo的函數代碼更新與版本發布4.3.1實驗準備4.3.2基于Gitee的CD能力建設4.3.3案例總結5.Serverless應用開發經驗/常見思路5.1如何上傳文件與FaaS平臺之間傳遞的數據包有大小限制，所以一般使用這種上傳方法的通常是上傳頭像容進行預簽名操作，并將預簽名地址返回給客5.2文件讀寫與持久化方法應用在執行過程中，可能會涉及到文件的讀寫操作，或者是一些文件的持久化操作。在傳統的云主機模式下，通常情況下是可以直接讀寫文件，或者將文件持久化某個目錄下，但是在5.3慎用部分Web框架的特性5.3.1異步函數計算是請求級別的隔離，所以可以認為這個請求結束了，實例就有可能進入到一個“靜默”執行狀態將不會返回。如果用戶希望獲得異步調用的結果，則可以通過配置異步調用目標來實5.3.2定時任務所以這就導致一些自帶定時任務的框架沒有辦法正常執行定時任務。因為函數計算通常是由事如果沒有通過觸發器觸發該函數，那么該函數是不會被觸發，函數也不5.4要注意應用組成結構5.4.1靜態資源與業務邏輯資源都在函數中，并通過函數計算對外暴露，不僅僅等，更是要注意將靜態資源與業務邏輯進行拆分，否則在高并5.4.2業務邏輯的進一步拆分費的。如果一個函數的內存設置不合理，會導致成本成倍增加。想要保證內存設置合理，更要---5.5善于利用函數的廠商特性各個云廠商的FaaS平臺都有一些“平臺特性”，所謂的平臺特性就是說這些功能可能并不是臺根據自身業務發展和訴求，從用戶角度出發挖掘出來，并且臺或者某幾個云平臺所擁有的功能，這類功能一般情況下如果利用得當會讓業務性能等有質的以阿里云函數計算為例，在平臺發展過程中，挖掘出用戶痛點（尤其是阻礙傳統/PreStop