以下是視訊内容精華整理，主要包括以下三部分：
一、雲原生時代業務架構的變革：從單體邁向Serverless
二、Serverless在網際網路行業的實踐精析
三、案例：函數計算如何助力石墨文檔效率&性能雙提升
分享嘉賓：阿裡雲Serverless計算負責人楊皓然。
（一）産業趨勢
如今，各個行業的企業都在進行數字化轉型， 尤其是新零售、傳媒、交通等行業。數字化的商業形态已經成為主流，逐漸替代了傳統的商業形态。另外一些行業，如工業、制造業等，雖然沒有直接進行數字化轉型，但是也開始利用很多數字化技術，來進行生産力的優化。
企業的數字化轉型，主要面臨如下四個環節：
從雲服務商的角度來看雲的演進趨勢：在Cloud 1.0時代，基礎設施的雲化是其主題，主要是雲托管模式，雲上雲下的應用保持相容，傳統的應用可以直接遷移到雲上，這種方式的核心價值在于資源的彈性和成本的低廉；當基礎設施為我們提供了海量算力的時候，怎麼幫助使用者更好利用算力，加速企業創新的速度，就成為雲的核心能力，如果仍在伺服器上建構基礎應用，那麼研發成本依然很高，管理難度也很大，是以有了Cloud 2.0，也就是雲原生時代，雲服務商提供了豐富的托管服務，助力企業數字化轉型和創新，使用者可以像搭積木一樣基于各種雲服務來建構應用，大大降低了研發成本。雲托管和雲原生應用兩者的差異具體如下圖所示。
（二）雲原生應用要素
雲原生應用有三個非常關鍵的要素：
微服務架構
應用容器化和Serverless化
靈活的軟體傳遞流程
（1）微服務架構
單體架構和微服務架構各有各的特點，其主要特點對比如下圖所示。總的來說單體架構上手快，但是維護難，微服務架構部署較難但是獨立性和靈活性更好，更适合雲原生應用。
（2）應用容器化和Serverless化
容器是目前最流行的代碼封裝方式，借助k8s及其生态的能力，大大降低了整個基礎設施的管理難度，而且容器在程式的支撐性方面提供非常出色的靈活性和可移植性，越來越多的使用者開始使用容器來封裝整個應用。Serverless計算是另外一種形态，做了大量的端對端整合和雲服務的內建，大大提高了研發效率，但是對傳統應用的相容性沒有容器那麼靈活，但是也帶來了很大的整潔性，使用者隻需要專注于業務邏輯的編碼，聚焦于業務邏輯的創新即可。
（3）靈活的應用傳遞流程
靈活的應用傳遞流程是非常重要的一個要素，主要是要做到以下四點：
流程自動化
專注于功能開發
快速發現問題
快速釋出上線
（三）Serverless計算
（1）阿裡雲函數計算
Serverless是一個新的概念，但是其内涵早就已經存在。我們可以了解到阿裡雲或者AWS的第一個雲服務都是對象存儲，對象儲存實際上就是一個存儲領域的Serverless服務；另外，Serverless指的是一個産品體系，而不是一個單個産品。目前業界雲服務商推出的新功能或者新産品絕大多數都是Serverless形态的，比如阿裡雲的Serverless産品體系如下圖所示，包括了計算、存儲、API、分析和中間件等，可以看出，目前雲的産品體系正在Serverless化。
阿裡雲的Serverless計算平台——函數計算有四個特點：
和雲端無縫內建：通過事件驅動的方式将雲端的各種服務與函數計算無縫內建，使用者隻需要關注函數的開發，事件的觸發等等均由服務商來完成；
實時彈性伸縮：由系統自動完成函數計算的彈性伸縮，且速度非常快，使用者可以将這種能力用在線上應用上；
次秒級計量：次秒級的計量方式提供了一種完全的按需計量方式，資源使用率能達到百分之百；
高可用：函數計算平台做了大量工作幫助使用者建構高可用的應用。
那麼，阿裡雲函數計算是如何做到以上四點呢？下圖是阿裡雲函數計算産品的能力大圖，從中我們可以看出，首先函數計算産品是建立在阿裡巴巴的基礎設施服務之上的産品，然後對在其之上的計算層進行了大量優化，接着在應用層開發了大量能力和工具，基于以上的産品能力，為使用者提供了多種場景下完整的解決方案，才有了整個優秀的函數計算産品。函數計算是阿裡雲的一個非常基礎的雲産品，阿裡雲的其他許多産品和功能均是建立在函數計算的基礎上。目前阿裡雲函數計算已經在全球19個區域提供服務。
（2）Serverless如何幫助使用者簡化雲原生應用高可用設計、實施的複雜度
從下圖我們可以看出，雲原生應用的高可用是一個系統的工程，包括衆多方面，完整的高可用體系建構需要很多的時間和精力，那麼Serverless計算是如何幫助使用者簡化雲原生應用高可用設計、實施的複雜度的呢？
下圖是高可用建設更加細化的介紹圖，從中我們可以看出，高可用體系建設要考慮的點包括基礎設施層、運作時層、資料層以及應用層，且每一層都有大量的工作要做才可以實作高可用。函數計算主要是從容錯、彈性、流控、監控四方面做了大量工作來實作高可用，下圖中藍色虛線框所對應的功能均有平台來實作，使用者是不需要考慮的，藍色實線框雖然平台做了一些工作來簡化使用者的工作難度，但是仍需要使用者來進行關注，而橘紅色的實線框代表需要使用者去負責的部分功能。結合平台提供的功能和使用者的部分精力投入，可以極大地減輕使用者進行高可用體系建設的難度。
函數計算在多方面做了優化來幫助使用者建設高可用體系。下圖展示了函數計算在可用區容災方面方面的能力，從圖中可知函數計算做了相應的負載均衡，使得容災能力大大提升。
下圖展示的是函數計算對事件的異步處理，其處理流水線主要包括事件隊列、事件分發、事件消費三個環節，在每一個環節上都可以進行水準伸縮，其中一個比較關鍵的點是事件的分發需要比對下遊的消費能力；另外可以通過為不同函數指定不同數量的計算資源，使用者能友善的動态調整不同類型事件的消費速度；此外，還可以自定義錯誤重試邏輯，并且有背壓回報和流控，不會短時間産生大量請求時壓垮下一個服務。
在函數計算的可觀測性上面，提供了日志收集和查詢功能，除了預設的簡單日志查詢功能外，我們還提供了進階日志查詢，使用者可以更友善地進行日志地分析；在名額收集和可視化方面，函數計算提供了豐富地名額收集能力，并且提供了如下圖所示的标準名額視圖、概覽資訊等視圖，可以更友善使用者進行運維工作。
下圖是應用傳遞的一個示意圖，從中我們可以看出整個流程包括了很多環節。在整個應用的傳遞過程中，隻有每個環節都做好，才能夠建設一個靈活的應用傳遞流程，其核心是自動化，隻有做到了自動化，才能提升整個流水線的效率和靈活度。
下圖展示了自動化應用傳遞流水線的每個環節具體的任務。其中需要注意的是要做到基礎設施即代碼，如此我們才能進行模闆定義和自動化設定應用運作環境，進而實作自動化的持續內建等等。
做到了應用的自動化傳遞之後，對整個研發效率的幫助是非常高的。在Serverless應用上，我們提供了如下圖所示的工具來幫助使用者實作基礎設施即代碼。Serverless的模型有一個很好的能力，就是同一份模闆可以傳入不同的參數，進而生成不同環境的定義，然後通過自動化地管理這些環境。
對于應用本身不同服務版本的傳遞和灰階釋出，函數計算提供了服務版本和服務别名來提供相應的服務，這樣子整個應用的灰階釋出流程就可以簡化成一些API的操作，大大提升了業務的效率。如下圖所示，通過Serverless計算平台提供的這些能力，整個軟體應用的應用傳遞流水線自動化程度得到了大幅度的提高。
函數計算還有一個很有用的功能——對存量應用的相容性。通過Custom runtime我們能夠适配很多的流行架構，相容傳統應用，使其能夠很容易的适配到Serverless平台上面，由控制台提供應用的建立、部署、關聯資源管理、監控等一系列服務。
除了函數計算，我們還可以用Serverless工作流來對不同的應用環節、不同的函數進行編排，通過描述性的語言去定義工作流，由其可靠的執行每一個步驟，這樣子就大幅度降低了使用者對于複雜任務的編排難度。
（四）應用場景案例
函數計算有幾個典型的應用場景，第一個就是Web/API後端服務，已經包括石墨文檔、微網誌、世紀華聯在内的多個成功應用案例。
函數計算的另外一個應用場景就是大規模的資料并行處理，比如往OSS上面上傳大量的圖檔、音頻、文本等資料，可以觸發函數做自定義的處理，比如轉碼、截幀等等。這方面的成功案例包括虎撲、分衆傳媒、百家互聯等等。
函數計算還有一個應用場景就是資料實時流式處理，比如說不同的裝置産生的消息、日志發送到消息隊列等管道類似的服務中，就可以觸發函數來進行流式處理，如下圖所示。
最後一個應用場景就是運維的自動化，通過定時觸發、雲監控事件觸發，流程編排等方式調用函數完成運維任務，大大降低運維成本和難度，典型的成功案例有圖森未來等。
Serverless計算在業界獲得了越來越多的認可和應用，歡迎大家來關注和使用Serverless産品和技術。
分享嘉賓：阿裡雲網際網路團隊解決方案架構師丁建。
（一）Serverless簡介
對于Serverless的定義，目前在業界并沒有一個統一的答案。下圖是目前兩個相對來說比較權威的定義。一個是Mike Roberts在文章所提到的，一類是使用第三方的後端服務（BaaS），另一類是把代碼運作在托管的短時運作的容器中（FaaS），BaaS和FaaS單獨使用或者一起使用都可以認為是Serverless架構，目前通常說的Serverless指的是FaaS方向，本文介紹的Serverless無特别說明情況下指的也是FaaS方向。CNCF對Serverless的定義更加明确，指的是不需要服務管理的情況下構造和運作程式。
目前Serverless計算已經被認為是雲計算的未來，甚至是整個軟體開發的未來。下圖是Serverless架構和傳統的Serverful架構的對比，可以看出Serverless架構在雲時代更有優勢。
如下圖所示，Serverless2012年首次提出，2016年引爆行業，目前進入了穩定發展的階段。這段時間内，Serverless在業内廣泛應用和發展，有了衆多産品出現。
Serverless與K8S都有很強的編排排程能力，那麼有什麼差別呢？簡單來說，針對多變的、不規則的負載，用Serverless比較合适，因為其有超強的、天然的彈性能力；K8S有比較成熟的應用部署的相關方案，比較适合對延遲要求比較低的業務，因為其響應延遲比較小，而Serverless存在冷啟動帶來的延遲問題。當然，這些并非一直不變的，産品也會随着需求的改變而調整自身特性。
Serverless和普通的PaaS對比如下圖所示，當然，AWS雲架構戰略副總裁對兩者差别的定義過于苛刻，目前還達不到其要求。簡單做個比喻，Serverless就像水龍頭，随時打開即用，不用時關閉即可；PaaS就像是飲水機，需要提前規劃用水量。那麼顯然，在按需按量供應方面，Serverless會做得更好。
為什麼我們要了解Serverless呢？相關報告顯示，2019年已經有超過40%的相關企業落地了Serverless，且在剩下未采用Serverless的相關企業中有超過一半的企業計劃在三年内落地Serverless計算技術。面對時代的高速發展，我們每個人都要去了解相關技術的發展，擁抱變化，以至于不被時代所抛棄。
（二）開源Serverless
下圖是CNCF關于Serverless生态的全景圖，包括平台層、架構層以及工具層，其中包括了衆多大家熟悉的廠家，比如華為、AWS、阿裡雲等。
下圖是目前Serverless開源架構的對比圖，從圖中來看目前熱度最高的是OpenFaaS，其次是OpenWhisk，但是從穩定性等幾個方面考慮，綜合來說目前成熟度最高的是OpenWhisk。目前Serverless架構支援的公有雲包括目前主流的各大雲服務商，比如AWS、阿裡雲等等。
Serverless開源架構衆多，公有雲上也有很多的Serverless産品，那麼到底應該如何選擇呢？在OReilly的調研報告中顯示大家之是以用Serverless的原因中排名前三的分别是：1）減少營運成本；2）根據請求自動伸縮；3）不需要操心伺服器的維護。結合以上三點原因，目前我們推薦大家更多的使用公有雲的産品，當然将來如果開源serverless的解決方案能和公有雲的彈性結合起來，架構更加成熟之後，大家也可以嘗試自建的方式。
（三）阿裡雲Serverless
前面提到過Serverless分為BaaS和FaaS兩個方面，阿裡雲Serverless在BaaS方面提供了包括下圖所示在内的衆多場景和應用，對于BaaS方面來說，相當于是買服務，而不是買伺服器。
如下圖所示，在FaaS方面，阿裡雲提供了ECI、Kubenetes、應用、函數“四大金剛”能力，使得使用者可以不再關心Server，隻關注于業務開發。目前，阿裡雲在Serverless方向是各大公有雲服務商中産品線最齊全、能力最強的廠家。
下圖是ECI、SAE、ECS和函數計算幾款産品使用成本的對比分析。從中可以看出，如果我們想要更精确的控制成本，做到成本最優，使用ECS就會比較困難，而其他三款産品有着更細的計費粒度，彈性更大，而且Serverless計算不需要做資源預留，能夠更加有效的進行資源利用。
下圖是阿裡雲幾款Serverless産品在計費模式、啟動速度、計費周期、售賣規格、特點以及适合場景方面的全面對比，大家可以依據自己的業務需求選擇最适合自己的産品。
（四）實踐案例
以下是幾個Serverless産品的實踐案例。
（1）某客戶Presto on ECI方案
（2）某客戶使用ASK應對突發流量彈性
以上兩個案例分别是基于ECI和ASK的解決方案，但是底層都是基于ECI來解決的，ECI典型使用者場景如下圖所示。目前ECI可以基于ASK來實作正常資源和彈性資源的混度，或者實作純彈性資源的拉起，而且也可以通過API的方式來編排到自己的業務系統，并且ECI是按秒級計費，成本方面也會比較低。
（3）某企業基于SAE一鍵啟停開發測試環境
（4）基于SAE的高效彈性、低門檻微服務架構轉型
上面是兩個案例都是基于SAE來落地的，SAE實作了Serverless架構與微服務架構的完美結合，可以用在微服務應用、Web應用、多語言應用等場景，是面向應用的Serverless PaaS平台。SAE産品的核心優勢如下圖所示。
分享嘉賓：石墨文檔資深工程師萬明。
石墨文檔資深工程師萬明從一個數字、兩個好處、三個階段三點介紹了函數計算如何助力石墨文檔效率&性能雙提升。
（一）一個數次
石墨文檔目前有30多個函數，主要是用來處理一些CPU密集型的操作，比如修改文檔表格和幻燈片、進行表格的公式計算等等。目前，石墨文檔每月執行函數計算的次數達到了30億次！
（二）兩個好處
函數計算給石墨文檔帶來了兩個明顯的好處：效率提升和性能提升。
對于效率上的提升主要有以下四點：
簡單：通過SDK調用函數計算即可；
省心：阿裡雲有專門的運維團隊負責相關任務，無需考慮擴容、監控等問題，隻需要專注于業務邏輯的開發；
省事：無需購買ECS、LB等元件，無需運維介入，甚至重新開機服務環節都可以省掉，大大縮短了上線周期和維護成本；
強大：可以用事件驅動的方式去觸發和響應使用者請求，有着多樣的觸發器，除此之外還有豐富的文檔和示例供使用者學習和參考。
性能上的提升主要是以下兩點：
快：響應任務通常是毫秒級，并且本身可以做到毫秒級的伸縮，快速實作底層擴容來應對底層的壓力；
穩定：響應平滑，波動比較小，高可用。
（三）三個階段
伴随着業務的發展，石墨文檔的技術也一直在更新。一開始，石墨文檔使用的是Node.js，後來換成了Golang和Java，技術更新的每個階段中，石墨文檔對函數計算的使用姿勢也在不斷變化。
（1）Node.js 單線程時代
最初，石墨文檔的後端是用Node.js實作的，因為石墨是多人協作平台，伺服器每天要進行大量的文檔改動，還有表格中的公式也需要實時進行計算，有大量CPU密集型操作，而且Node.js是單線程，是以我們想要使用分布式計算平台，但是單獨搞分布式計算叢集有點麻煩，使用函數計算比較符合，于是進行了小部分測試。經過一段時間的觀察，發現函數計算無論是在穩定性還是性能方面都比較優秀。這個過程中有一個小插曲，就是我們發現函數計算有6M的體積限制，于是用OSS進行暫存和中轉，如下圖所示，過程中的延遲在可以接受範圍内。
（2）Golang協程時代
随着業務的發展，石墨的調用次數越來越多，需要在成本和性能之間協調。同時，我們的微服務也在使用Golang開發，Golang的協程非常優秀，于是我們嘗試在Golang的協程中處理文檔改動，把原來函數計算處理的一些服務用Golang重寫，使用Golang的協程，但是帶來了負載不均衡的結果。最後，針對具體情況，決定小改動使用協程本地計算，大改動使用函數計算，在成本和性能之間取了最優。
（3）花樣時代：另類玩法
随着對函數計算的了解，我們開發出了其他的用法， 比如每日資料郵件和報警機器人。
每日資料郵件是給産品經理和Boss發送每日資料郵件的服務，包含了日活、新增使用者數等資訊，使用了函數計算中的定時觸發器來完成，每天中午十二點自動執行。該功能執行的時候大概包括調用内部接口擷取資料、使用puppeteer來初始化執行個體并繪制圖表、将圖表轉為圖檔、發送郵件。使用了函數計算之後，每日資料郵件不需要單獨的腳本，大大降低了成本，且具有較高的穩定性。
報警機器人主要提供了兩個函數，一個定時觸發，一個被動觸發。定時觸發的函數每隔幾分鐘便會用日志服務的接口去擷取最近幾分鐘内狀态碼異常的請求，然後發送到後端釘釘機器人（需要提供手機号）由機器人艾特相應的小夥伴，被艾特的小夥伴可以在消息中進行相關的設定，并且函數會修改自身的環境變量來實作持久化配置。整個報警機器人沒有用到任何資料庫，簡單、持久且穩定。
關鍵詞：Serverless、高可用、函數計算、雲原生、SAE、ECI、ASK