以下內容來自：「Techo TVP 開發者峯會 ServerlessDays China 2021」圓桌論壇環節，文字內容分爲「上下篇」與大家分享，在 TencentServerless 公衆號回覆「PPT」，即可領取本屆大會演講 PPT。
首次！騰訊雲、AWS、阿里雲、字節跳動，全球 TOP 雲廠商和互聯網企業齊聚一堂，共同探討 Serverless 的現在與未來。
論壇主題：聚焦當下，重構未來：Serverless 全球視野碰撞
主持嘉賓：
- 中國信息通信研究院 雲計算部副主任、騰訊雲TVP，陳屹力
圓桌嘉賓：
- Amazon Web Services 首席開發者佈道師，費良宏
- 阿里集團 Serverless 標準化規範負責人，陳仲寅
- 字節跳動基礎架構函數計算負責人，楊華輝
- 騰訊雲 Serverless 專家架構師，楊政權
「靈魂拷問」環節
Q：中國信息通信研究院 雲計算部副主任、騰訊雲TVP，陳屹力
費老師您作爲 AWS 首席開發者佈道師，在工作中可能會遇到一個問題：什麼是 Serverless？Serverless 並不是一個很容易被理解和廣泛接受的概念。在佈道的過程中，和國外社區相比，國內開發者社區對於 Serverless 的接受程度怎麼樣？對於沒有接觸過 Serverless 的開發者或者非技術人員，如何普及 Serverless 的概念和價值？在佈道過程中會遇到哪些挑戰，以及有哪些方法值得我們借鑑？
A：費良宏，AWS 首席開發者佈道師
這個問題的內容涉及的範圍比較多，我嘗試跟大家分享一下我聽到、看到、觀察到的一些現象。
首先看國內的市場和國外的市場，Serverless 發展的情況。坦率說，我認爲在國外的市場發展勢頭比國內市場要好很多，應用規模、數量、普及程度、開發者的接受程度來說，我看到了非常多有意思的基於 Lambda 或者 Serverless 的項目實踐，以及大規模應用的結果。但是同樣情況在國內看到的項目以及實戰的結果相對少很多。這個原因非常複雜，自己歸納有幾點原因：
1. 雲計算市場的佔有率
在國外市場，雲計算的普及程度或者雲計算的滲透率相對來說比較高。國內市場的情況，一方面是雲計算的滲透率還比較低，傳統IT的比例還是比較高。
2. 雲計算市場份額的碎片化
在國外市場當中，幾個巨頭已經把整個雲計算市場瓜分得非常充分，所以開發者選擇平臺的時候，很容易選擇頭部這樣的平臺作爲開發的基礎。但在國內，我相信很多開發者很困惑：究竟用哪種雲？而 Serverless 作爲一個新出現的技術，它的時間比較短，2014 年底出現這個苗頭，成熟只是這幾年的時間。這麼短的時間出現之後，由於發展趨勢非常好，所以大家都去推進自己 Serverless 的產品，這會出現一個結果，百花齊放，缺少統一的標準。換句話說，在 A 雲上開發 Serverless 的 Function，其實沒有辦法平滑地遷移到 B 雲上去，更何況去 C 雲了。這種情況結果就是選擇了某一朵雲，註定依賴於某一個 Serverless 平臺。
對於很多開發者，更多的是選擇跨雲部署，或者還有混合部署、本地部署、雲端部署。最終的結果，就選擇用妥協的結果，不是選擇 Serverless，而是選擇用傳統的方式，Doker、Kubernetes 等方法替代。所以，國內市場的複雜性，雲計算的滲透率不高，以及開發者對這個新技術的猶豫不決導致了在國內市場 Serverless 的發展速度，相對於國外來說有點遲緩。
對於這個問題的解決，我想有這麼幾種思路，跟大家商榷一下是否能改變。
1. Serverless 本身還是需要有標準化。
無論底層技術如何實現，如果從規範 API 或者調用規模方式來說，有一個標準將對開發者的普及是有莫大的幫助。如同像 S3 的出現一樣。大家知道在雲計算領域當中，對象存儲的缺省標準及工業標準是 S3，不論底層實現是否是S3，但大家在接口上統一了。這樣應用移植或者匹配都會非常容易實現。如果在Serverless這個環境當中，也能夠達成某一種共識的話，用一種標準化方式推進的話，我相信對於廣大的開發者來說是一個非常大的福音。
2. 將雲計算的概念、平臺滲透率提高。
讓大家更多用雲原生和雲優勢這樣的技術去開發雲。而現在很不幸的情況就是，我們在用上個世紀的積累經驗來使用雲平臺，把雲只看作基礎設施、虛擬機、存儲和網絡載體，沒有充分地利用到雲平臺之上的那些託管高級的服務。而 Serverless 是這類服務，如果雲計算的概念深入人心，我們的架構應用完全基於雲計算開發的話，那 Serverless 的普及就是迎刃而解的事情。
對於 Serverless 的推廣來講，我們不要拘泥於 Serverless 本身的定義、看到的一些好處去談它，更多的是看它未來的發展前景。我非常認同一個說法：雲計算 2.0 就是 Serverless。可以設想一下，有一天在開發或者部署新的應用架構的時候，後臺或業務邏輯的實現完全基於Serverless。我們先不假設 Serverless 在實現上的難度或者目前的困境，僅假設 Serverless 是理想環境，完全用 Serverless 建立業務邏輯的話，那這個架構將是多麼漂亮、簡潔、優雅的結構。雖然現在 Serverless 還有些不足，但發展勢頭一定是非常好的。
希望很多開發者、架構師能夠理解到 Serverless 給整個行業帶來的衝擊，不僅僅是快速部署、快速開發、免維護，甚至某種程度來講，是無架構的新模式。架構師在 Serverless 環境面前，變得沒有那麼重要，因爲完全可以用函數將一個業務邏輯簡單封裝連接在一起。如果大家意識到這種變革，這種未來的衝擊，給我們今天帶來很多啓發的話，相信接受 Serverless 就是水到渠成的事情。
Q：中國信息通信研究院 雲計算部副主任、騰訊雲TVP，陳屹力
還有一個更深層的問題，今天我們看到很多演講嘉賓分享的內容，不論是從數據庫、中間件、AI 推理等方向，對於 Serverless 的應用都有非常豐富的經驗。作爲雲廠商非常堅定地認爲 Serverless 是未來的方向，並且有很多實踐，但用戶對 Serverless 還有很多的擔憂或對應用場景有很多疑慮，這中間的 gap，最大的核心點您認爲是在哪裏？
A：費良宏，AWS 首席開發者佈道師
我認爲是 Serverless 標準化的問題。大家會有一個顧慮，當選擇某一個 Serverless 平臺的話，就會出現所謂的 Vendor Lock-in 的平臺綁定的問題，讓最終的選擇失去了靈活性，由於這個顧慮的存在，可能對於這些獨有的技術或者平臺特有的技術望而卻步了。
如果能夠打破這種顧慮，或平臺之間能夠更平滑地選擇遷移，那麼後續 Serverless 的普及將會更容易一些。我在設想有一天有這樣工具的存在，無論某一個雲的平臺，可以用一個工具把函數能夠無縫非常好地部署在任何一個選擇的環境當中的話，可能 Serverless 就變得更爲容易被接受。
Q：中國信息通信研究院 雲計算部副主任、騰訊雲TVP，陳屹力
陳老師經歷過多次淘寶雙十一大促，對大流量高併發的管理非常有發言權。在運維和成本管控方面，Serverless 是否發揮了優勢？目前主流的 FaaS 產品，內存和 CPU 都進行了綁定，按比例擴容，但存在靈活度不足的問題，如何匹配用戶的實際使用場景，造成額外的計算開銷，在這個維度未來優化的趨勢是什麼？
A：陳仲寅，阿里集團 Serverless 標準化規範負責人
阿里巴巴從去年的雙 11、雙 12 到今年的 618 大促，其實已經使用 Serverless 快 2 年的時間。這 2 年的過程中，我們一直在嘗試把傳統的業務逐步遷移到 Serverless 上面來。在這個過程中最有感觸的一點，Serverless 帶給業務的價值：節省成本，這是一個非常直觀的方面。Serverless 的彈性、免運維能夠節省我們大量的成本，機器成本和人力成本。
- 人力成本
阿里去年有一個數字，Serverless 給阿里的人力成本降低了 48%，這個數字是我算出來的。阿里內部會有需求管理平臺，需求迭代時間，加上最終交付產品，一個較爲複雜的計算，最終通過長達一年的時間統計下來得到的。人力成本計算很複雜的，會涉及時間成本、代碼量成本、需求管理成本等各類成本。但是最終會定義在同一個基線上，最終按照一致性的算法，相對地得出了 48% 的數字。這個數字是根據需求、人力開發週期、代碼量，最終得出了這麼一個數字，這是一個人力成本的降低。其中包括業務開發同學無需關心申請機器、流量計算、容器數量以及上線流程方面的優化成本等等，都是算在人力成本里面。
- 機器成本
機器成本比較容易計算。比如按照以往的流量、規模量，估算出需要幾千臺的虛擬機。而如今使用 Serverless，只需要在流量高峯的時使用到比較多的容器，在低谷或者平峯的時候，使用較少的容量，通過這樣的方式，機器成本會節省得更多。
綜合這兩方面，機器成本 + 人力成本，最後的確得出整個 Serverless 體系讓我們阿里的大促成本降低得非常多。所以，這也是 Serverless 一個非常大的優勢。從今天開始，我們所有淘系的大促，包括周邊像飛豬、高德、考拉都是用 Serverless 逐步把傳統的業務遷移到 Serverless 體系上來。目前來看，是非常的成功和值得去推廣的。
CUP 和內存的綁定缺少靈活度，如何優化？這個問題在我們看來還不是問題，因爲目前來說阿里集團大部分使用 Serverless 的基本上都是前端的業務，前端的業務使用 Node.js 作爲底層的容器，其實沒有對資源有非常大的需求，是非常小、輕量快的引擎，只需要非常少量的內存，CPU 只需要固定的量。整個綜合起來，其實按照現在阿里集團前端使用 Serverless 的體系來看，沒有明確一定要把 CPU 和內存的比例分開或者怎麼樣。但是，從最廣的層面，從其他語言 Java、Python 的層面看，可能有這種訴求，特別是 Java，可能一開始就需要一定內存比例。至少目前來看，在前端領域還沒有這麼嚴重地說，一定要把這兩個關係分開。但是，其他特定語言可能需要這麼一種自定義解法。
不同語言、技術棧不一樣，對資源的需求也是不一樣的。比如底層有些 Agent 的確需要大量的資源，的確需要解開 CPU 和內存兩者綁定關係，不同場景下的需求是不一樣，這是當下雲平臺沒有辦法滿足的。但在集團內部的需求是存在的，是允許分開的。所以，未來可能當這種需求出現的時候，雲廠商不管是阿里雲還是騰訊雲，面向這種需求的時候也是一定會放開。因爲用戶需要，所以廠商一定提供這樣的一些能力。
Q：中國信息通信研究院 雲計算部副主任、騰訊雲TVP，陳屹力
字節跳動在 Serverless 大規模落地方面也有豐富的實戰經驗，能否和我們分享實際項目。在進行 Serverless 架構設計以及規模化落地時有哪些誤區？比如技術選型、業務粒度拆分、成本、分佈式事務管理、部署運維等方面，可以結合具體的案例給大家分享一下常見的 Serverless 應用誤區。
A：楊華輝，字節跳動基礎架構函數計算負責人
字節跳動的 FaaS 產品有兩個特點。第一個特點，從一開始就是基於 K8S 來構建的，打破 FaaS 無法在 K8S 上構建的謠言。第二點，字節跳動的 FaaS 承載的 QPS 規模相對其他雲廠商來說是比較大的。在線場景 QPS 是幾十萬的規模，換作是每天是幾百億的調用。Pulsar 消息處理高峯期有 2000 多萬的 QPS，換算成每天是萬億次調用規模。這兩點就是字節跳動整體的 FaaS 的特點。基於這兩點的一些經驗，可以簡單地談一談我們的想法。
首先，規模性。對於這種大規模性，大家可以看到在 FaaS 的早期，都是以獨佔模式作爲第一次推出來的 feature 去落地的，用戶進來的話就是一個容器或一個 instance（函數實例） 在同一時間運行一個請求。對於管理來說很簡單，但是帶來的一個壞處很明顯，中小企業部署 FaaS 技術一開始都是免費的。但是規模大的話，可能會造成成本急劇的上升，怎麼解決這個問題？目前各大雲廠商的 FaaS 產品都逐漸支持在一個 instance 中配置併發數。字節跳動對於這件事情來看，一開始就是支持在一個instance 上配置多併發，而且默認併發比較高，基本上不太能達到限制。
因爲我們覺得併發的強控制是對於一些 CPU 或者內存的密集型的場景比較有用，但是大部分的數據處理，並不是數據密集型，在整體的 pipeline 中，過於管控併發將會導致整個系統非常不穩定，Overhead（系統開銷） 數值特別高。我們在一定併發量上會做 soft limit （軟限制）和 hard limit（硬限制），在每個 container 上會有 sidecar 來進行管控，去避免 instance 被洪峯流量打垮。但是反過來，因爲 FaaS 都會進行流量管控，我們在 gateway 或者流量調度層面做的流量管控也是比較薄，這種有利於去承載大規模流量。如果幾千萬的 QPS 流量打過來，經過中心化的七層 LB，再經過流量調度成本是非常高的。整體 MQ 流量我們是可以接管的，MQ 的流量相當於 event source，這就是 FaaS 內部的範圍，某種意義上繞過內部一些七層和流量管控的組件，直接把流量打到 instance 上面。通過這樣方式，可以做到比較好的擴展性和比較強的整體的水平擴容性。
我相信今天來參加的各位同學，應該不僅是 FaaS 的使用者，也有像我很多年前坐在臺下的感受：我想構建 FaaS 系統，應該注意什麼？這也是我今天想跟大家分享的另外一點。如果想在目前的生態的事實標準上面構建 FaaS 系統，去沿用 PaaS 一些已有的生態以及已有的基礎能力，這是必要的。這可以加快你的迭代速度，最快地推向市場。如果在未來 FaaS 成爲 PaaS 的下一代，可以做到無縫遷移。那對於 K8S 的技術，我們更多情況下把它當作分佈式的運維繫統，如 ansible 或 saltstack，幫你把東西給搭起來就可以了，不需要太多依賴它的服務發現或是冷啓 Pod 的能力，在使用它們之前應該記住這樣一個預設前提，這些能力只能作爲異步撈回的兜底機制。所以，整體內部的路由發現以及拉起 Pod 都應該 FaaS去實現。所以 FaaS 之上運行的各種應用的收益，也主要得益於 FaaS 在 PaaS 層面上多做的這些工作。這是整體上是我對 FaaS 的理解。
Q：中國信息通信研究院 雲計算部副主任、騰訊雲TVP，陳屹力
楊老師是專家架構師，經常需要直接面對客戶，那麼相信有很多客戶會提出一些問題，比如有些客戶會顧慮廠商綁定 Vendor Lock-in 的問題。對於頭部的企業都在多雲、混合雲等場景，增加整體系統的可靠性，也提高了議價空間。目前 Serverless 在對於多雲支持的現狀如何？還有哪些亟待解決的問題？
A：楊政權，騰訊雲 Serverless 專家架構師
從我的視角來看，剛纔費老師也提到標準化以及兼容多個雲平臺的標準，這固然重要，但在我看來，很多時候從企業的視角來說，需要考慮這是否是第一優先級。在我們提到 Cloud Native 概念的時候，重點是 Native 這個詞，如果用 Native 的隱喻來思考一些同類的問題，會有非常驚訝的發現。比如我們作爲中文的 Native Speaker，我們去國外的時候並不會要求我們說出同樣流暢的英語。如果我們是海外的 Native Speaker，來國內時同樣也不會有類似的要求。
所以在提到 Cloud Native 這個概念的時候，關鍵的點應該在於如何更加充分利用雲所提供的原生能力？我們在提 Multi-cloud 時，很容易出現這樣的現象，我們做出了一個通用性的產品，但沒有辦法充分利用每個雲平臺所提供的獨特能力。在做很多研發同學一定會熟悉，比如在做一些繼承或提供公共抽象接口的時候，我們找的一定是一個共性。但是各個雲廠商在實現上往往還是會有一定差異性，比如同樣是 COS 對象存儲、K8S 調度平臺在能力方面都會有些許差異。尋找共性的同時也意味着一定程度上失去了充分利用平臺能力、使用平臺特性的機會，這是我對於 Multi-cloud 的想法。
另外想分享的是 Hybrid Cloud 混合雲的架構。我在接觸一些客戶時，更多的場景是說客戶在自己的 IDC 裏面有很多機器，但是容量不足，希望能夠充分利用 IDC 的算力，同時把溢出的流量放到 Serverless 上面去處理，這是一個很自然的現象，也存在合理性。但是如果說站在一個企業的角度去思考，到底是不是一個最佳的實踐？其實未必，經濟學裏面有個詞叫做 Sunk Cost （沉沒成本），所有一次性的機器硬件投入都是沉沒成本，但是企業關注沉沒成本的同事，往往忽略了其他可變成本，比如繼續維護這臺機器所產生的運維成本，需要有專業的運維團隊來做這件事情，即人力成本，除此之外還有如服務器開銷、服務器保費等。對於 Hybrid Cloud ，看上去是合理的架構，但未必是最佳的解決方案。也許更好的方式是充分利用雲所提供的基礎設施，把應用放到雲上執行從而充分利用各種雲原生能力。
關於騰訊雲對 Multi-cloud 的支持，我們也在做相關的事情，比如業界已經有一些 OAM、Dapr 這樣一些解決方案，包括騰訊雲容器團隊在做的一些 EKS、TKE 在做些標準化的工作。此外騰訊云云函數和 Serverless Framework 有深度集成，不需要關注基礎設施，只需描述對於函數的定義，比如通過 YAML 這種聲明式定義基礎設施定義，不依賴於某一個雲廠商，Serverless Framework 提供不同雲平臺的適配器，基於 AWS、阿里雲或者騰訊雲可以做相關的資源的管理、編排工作。
- 聚焦當下，重構未來：Serverless 全球視野碰撞（下），即將更新，敬請期待！
One More Thing
立即體驗騰訊雲 Serverless Demo，領取 Serverless 新用戶禮包 👉 騰訊雲 Serverless 新手體驗
歡迎訪問：Serverless 中文網！