2020 年，Serverless 將給大前端帶來什麼樣的變化？

做者 | 杜歡（阿里巴巴高級前端技術專家）、王文婧

導讀：雲 + 端模式成爲當前前端開發的新風向，由此而來的 Serverless 正幫助前端工程師提高開發能力和效率。近日在 2019 ArchSummit 全球架構師峯會北京站，阿里巴巴高級前端技術專家杜歡（風馳）接受了 InfoQ 記者的採訪，爲咱們詳細梳理了阿里巴巴近兩年使用雲 + 端的 Serverless 來探索前端演進過程的經驗和體會。

Question：杜老師，您好！請您介紹一下您的從業經歷，以及目前在阿里雲戰略 & 合做部負責的工做。

杜歡（風馳）：目前我在阿里雲戰略合做部，負責阿里雲的開發者業務，更多的是在考慮怎麼在雲的時代幫助整個廣大的開發者社區和生態可以在成爲雲時代原住民開發者的狀態下，有個更好的開發環境。

Question：您從事前端工做多久了？對這個行業有過哪些困惑與思考？

杜歡（風馳）：我其實進入到前端行業仍是頗有趣的一個過程，我最先是在 2001 年左右開始接觸到 Web 開發。那個時候，就是作網站，作網站前端、後端、數據庫，而後發佈運維都要作。那個時候其實也沒有如今這麼多崗位，基本上就一個崗位——開發，全部的事情都作。

後來隨着公司業務的拓展，開始去接一些 Browser 端的工做，當時有一個詞叫作 BS，它和 CS 是對應的，CS 叫 Client Side，就是客戶端。Client 和 Server，就是客戶端和 Server。BS 是 Browser 和 Server。從那個時候開始，這種 BS 結構的應用出現，這種結構的出現其實當時是爲了解決開發成本和部署成本的問題。就是有些企業想作一個系統，這個系統能夠很容易地讓整個企業內部不一樣的團隊、不一樣的角色很好地利用，部署的成本不要那麼高，開發成本也不要那麼高。

因此那個時候開始有這種業務類型出現，這種業務類型操做的主要界面就在 Browser 端，那 Browser 端就會遇到一個很大的挑戰，也就是說，你的操做行爲、表現、習慣跟原來傳統的客戶端軟件開發的那種操做體驗是不太同樣的。由於 Browser 是瀏覽器。瀏覽器裏邊就是頗有限的幾個元素 API。而後主要客戶就會提一些要求說，你須要幫我把傳統的那種體驗交互保留下來。由於對我而言，我只是換了一個軟件提供商，可是我和個人同事在使用的時候不能有什麼感知，對他們來說應該是同樣的。

那個時候遇到的挑戰是，在瀏覽器裏如何實現和傳統的開發軟件裏的 UI、組件同樣的行爲。舉個例子，好比說你在搜索框裏輸入任何一個字符，它會有下拉提示，這是很是常見的一個 UI，但在那個時候是沒有的。這個 UI 至今也是沒有原生提供的，都是前端去模擬出來的。

因此那個時候我作的就是這些事情。作着作着，我發現挑戰很是大，至關於你要徹底模擬出一套傳統的開發體系裏的整個 UI 體系。那個時候就想，我能不能把這個作得更好一點。因此慢慢地開始加入到前端的一些社區。認識了當時的一些朋友。就這樣進入到前端行業，一直作到今天。

Question：前端的發展很快，在研發體系的升級上，阿里雲是如何部署的？

杜歡（風馳）： 前端升級確實是讓人又愛又恨的。並且這種升級，在我看來，好比說框架層，它可能要解決的是一些新的研發形態，可是對業務而言，它其實並無很大規模地解決上一個階段遇到的問題。

舉個研發效率的例子，好比咱們如今作工程化、框架的演進，和最先用 jquery 的時候，相對業務而言，有什麼變化嗎？沒有什麼變化。並且有時候反而使你的整個協同成本、交付成本、人力成本在必定程度上變高了。由於你引入了工程的概念，你就要去作工程化，工程化不是全部人都能作得很深刻。由於工程化自己就是一個領域，因此你又得爲了把工程化作好去準備一些特定的侯選人，組建一個團隊。相對來說，你又多了一批作業務的人，業務流程又要變慢。原來可能你在 UI 上作完，JS、HTML、CSS，你怎麼作立刻就能夠看到。如今你是看不到的，你寫完以後要編譯，工程化和編譯完以後，你可能才能看到。

我想表達的是，前端不斷地在演進，它實際上是更精細化了，質量更有保障，在必定程度上效率可能也有提高。可是從更宏觀的角度，從業務的角度來看，它可能不必定真正解決了業務痛點。就好比說今天咱們提到，有的業務指望是，人一進來立刻就能幹活，幹完活立刻就能上線。從業務的視角來看，前端這幾年的演進可能還不是一個終態，它處在一個摸索的階段。

Question：因此就像您說的，工程化如今尚未達到它的預期效果？

杜歡（風馳）： 咱們認爲，工程化的出現和持續演進將來必定是能幫到業務的，可是它還在摸索的階段。自己作工程化須要消耗人力、資源，包括流程的新增，這些其實在這個階段是會下降業務交付效率的。因此咱們也不能說它不對，由於它畢竟有一個發展的過程。只是在它尚未到達終態以前，無論是框架仍是這種工程化的這種演進，相對來說都是比較痛苦的。

可是將來若是終態來臨，隨着將來結合雲原生 Serverless，從寫代碼到最終發佈一體化的時代來臨，可能全部的問題就迎刃而解了。

Question：我以前採訪過一個專家，他說，前端工程化就是在作「消滅」本身的工做，您怎麼看？

杜歡（風馳）：我是這麼理解，若是是消滅本身，那意味着，前端這個崗位目前作的事情將來會有一個東西替代它。
那今天前端的崗位在作什麼事情呢？核心是在作用戶交互行爲的開發，在廣泛的基礎上，若是加上業務的特性，用戶交互行爲就會有不少定製化的東西。再加上，由於每個業務都要差別化才能生存，尤爲是 to C 的產品類型，它必定會在用戶側尋找和競品的差別化，用戶側更多的表現就是怎麼讓用戶看起來更舒服，操做起來更舒服，整個體驗更好。這些每每會表如今真正的用戶交互行爲上的差別。

這裏有一個矛盾的點，抽象出來的那些東西，經過工程化確實能以必定的手段來替代，可是差別化的東西怎麼來作，是否是可以徹底替代，這個還很難說，至少今天尚未一個你們都以爲可信的方案說可以替代掉。就像今天的企業級定製開發也是相似，之因此叫定製開發，就是它至少在提定製的這個時間點，沒有一個可抽象、可覆蓋它的一個通用的東西，要否則它就不須要定製了，就用通用的就行了。

因此我以爲工程化可以消滅那種通用抽象的東西，可是定製的東西至少目前來看還不能，除非將來機器學習演進到可以理解真正不一樣的需求，而且可以把這種需求跟現有的技術體系、科學體系完整地連接起來的時候，那我以爲是有機會的。

Question：阿里經濟體的前端技術架構是什麼樣的？它經歷了哪些發展階段，能否提取幾個重要的時間節點談談？

杜歡（風馳）：阿里經濟體的前端在必定程度上，至少能表明國內的前端行業發展的階段。首先，據我所知，在國內，前端這個崗位最先就是在阿里出現的。那個時候爲何會出現前端？已經從原來的全部的應用由一我的開發變成一種用戶需求導向，用戶以爲你這個應用雖然好，可是操做起來不好，或者整個體驗很差，因此能不能有人把這塊作得更好？因此在業務的需求下產生了職業精細化的要求。這個精細化的需求在前端崗位誕生的時候，它的核心是把結構、表現、行爲這三者作精細化的處理或演進。這是這個崗位誕生之初阿里前端在作的事情。

後來隨着業務體量逐漸增大，開始覆蓋到的人羣，以及人羣所在的地理位置都不太同樣的時候，愈來愈多的來自網絡比較差的環境的用戶會說，打開特別慢，體驗很差，那個時候又經歷了作性能優化的時代。性能優化主要的目的是，讓不一樣的地理位置的用戶都可以以最好的速度訪問到咱們的業務，讓你們的體驗儘可能是最好的。

第三個階段，Node.js 的出現，爲咱們前面談到的工程化提供了基礎。由於作工程化意味着你要去作編譯、文件處理，操做一些事情，這些東西須要有一種能力讓它可以跑在本地，跑在系統裏面，不僅是在 Web 頁面上。Node.js 當時幫助前端有能力作這件事情，而後開始演進出前端如何進一步地把行爲、樣式、結構分離，如何作模塊化的設計、模塊化的開發。拆開以後，這個頁面你就看不到了，你想看到，怎麼把拆開的東西從新聚合起來？那個時候就是經過 Node.js 作這種總體的工程化。

第一更精細化，第二更精細化以後，可以把它編譯在一塊兒，可以看到，同時去解決或優化和原來後端的協同方式。其實在這個階段以前，前端和後端的協同方式是比較粗暴的，是那種交接式的。就是前端作完頁面，而後把產物交接給後端，後端拿着前端作的頁面，在那些特定的區域操做，好比說一個表格，表格裏面應該有數據，前端會填一些假的數據在裏面佔位，後端再把真實的數據塞在裏面，那是最先的階段。有了工程化體系以後，前端和後端的銜接就能夠經過 API 的方式來作。在有 API 以前，前端能夠去模擬這個假數據，經過約定的 API 規範之類。這是第三個階段，就是工程化帶來的這種更精細化的設計、模塊化的設計，以及這種先後端協同的演進。

再日後的演進就是無線時代，前端開始向混合開發模式演進，好比幾個框架的誕生。阿里內部也誕生了一些框架，好比你們知道的 Weex，最近的 Rax 等等。這是在 all in 無線業務背景下前端的演進。阿里內部有不少中後臺的業務，它有不少相對固定的結構形態，其實咱們在工程化上又進一步演進了，就是誕生了這種中後臺的研發模式。這種低代碼的研發模式，更多地體如今頁面的搭建，當咱們有足夠多的設計資源，已經抽象好的、比較通用的、設計好的模塊，那麼就能夠簡單地經過一些框架，把這些模塊組裝在一塊兒，而不用寫代碼，或者寫不多的代碼。這是中後臺的演進。

如今，結合雲的到來，企業但願經過雲去提升效率。這只是一個願望，必定要通過一個技術的演進才能落地。相應地，從今年年初到「雙 11」，咱們整個阿里再一次演進了本身的技術體系，升級到了 Serverless 的研發體系。它不只能夠幫助前端完成面向用戶交互的開發，還可以完成整個應用的開發，整個應用的開發基於雲計算的實時彈性的能力可以快速作好，而且可以真實地在線上服務好「雙 11」這麼大的流量，真正幫助企業實現用雲來快速商業化、節約成本的初衷。

Question：阿里是何時開始採用 Serverless 的？

杜歡（風馳）：2017 年，阿里就開始討論這個事情，正式啓動是在 2018 年。阿里內部因爲開發環境、網絡的客觀緣由，暫時不能直接使用阿里雲的公共資源，因此咱們要內部實現一套公共雲上有的 Serverless 的能力，因此咱們在 2018 年本身建設了這麼一套能力。2019 年，咱們開始作上層研發的架構和模型，到今年「雙十一」咱們正式投入使用。

Question：雲 + 端是一個老生常談的話題，阿里雲的雲 + 端和其餘企業的雲 + 端有哪些不一樣之處？

杜歡（風馳）：爲何今天雲出現了這麼久，你們提雲 + 端也提了這麼久，提 Serverless 也提了有一段時間，可是真正的實踐那麼少呢？由於在研發實踐當中仍是須要很挑戰的一些東西去幫助它推進。

第一個是頂層的設計，由於你是研發生態，而不是簡單地利用雲的能力去作一個任務，這是不同的兩件事情。若是是利用雲的能力去完成一個任務，這個很簡單，不少人都在用。可是如今真正利用雲 + 端，利用 Serverless 的能力去幫助本身提高研發能力是沒有的。問題就在於你們都缺少對整個研發架構的改變。由於你要真正利用它，研發模型要發生改變，研發的流程鏈路也要發生改變，這個你們沒有參考。

今天阿里做爲前期的實踐者，願意分享本身的設計，爲你們提供參考，將來真正要在本身的研發體系裏實踐，大概要怎麼設計，有哪些環節，哪些關鍵節點，哪些特徵等等。第二個是真正的實踐，若是阿里巴巴也只是停留在設計上，沒有拿本身的業務去實踐，我相信你們也缺少信心，也可能會認爲這只是咱們的想象，可是今天咱們真正地經過「雙十一」這個很大的場景來考驗。

其實我相信這可以給到整個行業一些信息，咱們不只在思考和設計整個 Serverless，整個雲 + 端落到真正的研發模式上，同時咱們也經過本身的業務去驗證了咱們的設計是可行的。最後咱們也但願，不只是分享咱們的架構設計，將來咱們本身內部的整個研發平臺能有機會經過阿里雲開放給整個行業，讓外面整個開放的生態也可以使用。你們都使用同樣的方式、同樣的平臺、同樣的架構。

Question：正如您所說，今年「雙 11」是 Serverless 在阿里的第一次大檢驗，取得了振奮人心的效果，可是這個過程中確定會有一些坎坷，您能分享一下這方面的經驗嗎？

杜歡（風馳）：最痛苦的仍是 Serverless 底座的建設。我花了比較多的時間和你們講爲何不要去自建這一層的緣由是，由於落地和實踐 Serverless，不是一個技術訴求，而是一個業務訴求。爲何？由於雲自己是幫助企業用低成本高效快速地實現商業化，技術只是爲了讓這個業務訴求落地，是這樣的一個關係，因此說若是沒有 Serverless 底座是很痛苦的一件事。而且若是它的能力不行，基本上也是不可用的，由於落地 Serverless 意味着你的全部服務都是跑在上面的。若是它掛了，你的業務也掛了，沒有人願意這樣。

Question：因此說，小企業可能不太適合作 Serverless？

杜歡（風馳）：小企業最好不要本身去建設 Serverless 底座資源能力。第一，存在技術上的挑戰；第二，存在資源規模化的挑戰。由於 Serverless 的核心要素是，它是按量使用的，按量使用意味着若是今天的量很小，你就用不多的資源；若是今天的量很大，就會給你調不少資源。「雙十一」的時候，流量都是億級的流量，若是你的企業內部沒有按億級作單位的這種流量的機器資源，你怎麼去調度這些資源給他人使用呢？你沒辦法實現按量調度。因此小企業，或者不具有這種資源規模化的企業，不須要去自建 Serverless 能力，不是說不能去實踐 Serverless，能夠用公共雲，好比說用阿里雲或其餘的雲。

咱們遇到的最困難的也是這個事情，就是內部研發網絡環境和生產運行網絡的問題。咱們也是不互通的，咱們內部也很難直接在公共雲環境去使用阿里雲這些已有的能力。咱們其實花了一年的時間，在阿里內部推進不一樣的團隊去建設 Serverless 底座。這是第一個我認爲比較挑戰的點。

第二，整個研發模型對研發體系帶來了挑戰。其實不少時候這種東西一出來，看起來是幫助前端拓展了邊界，拓展了價值能力，可是相應來說，後端同窗可能第一反應就是，那這是否是把我革命了？我就不須要幹活了？其實不是這樣的。好比阿里的導購業務就是取數據展現的場景。這種事情讓一個後端來作，沒有任何技術價值、技術沉澱、技術成長，可是現有的研發模式就是須要有後端同窗進來開發。因此其實對他們來說，Serverless 研發模式的演進有助於幫助他們往更底層演進，讓他們聚焦於真正須要作技術研究的部分。好比，這些數據的能力、服務的能力，怎麼作得更好、更紮實，這是咱們指望看到的。可是這個研發模式乍一看，若是你們沒有深刻了解的話，就會認爲對整個研發模式、研發流程挑戰很大，那麼就須要去和你們溝通、佈道，講它對每一個崗位會帶來的價值。

第三，回到前端來說，這個東西雖然看起來很美好，但若是你真正下決心要進去，對每個前端來說，是撕裂的成長。由於咱們要開始知道這個業務是什麼，爲何要作這個業務，這個業務到底服務誰，關鍵的指標是什麼，怎麼作。這個時候他已經從前端變成一個業務的功能，整個業務都是他去開發、交付。

這是從技術準備、研發體系的協同，到前端崗位的挑戰三個層面的難點，是我以爲印象比較深入的，多是將來你們在實踐當中都會遇到的。

Question：我在網上了解到，有人說 Serverless 存在不適合長時間的運行應用，徹底依賴第三方服務，缺少調試，還有構建複雜等缺點。您認同這些觀點嗎？對於那些尚未涉足 Serverless 的人，您能夠幫助他們辨清這些概念嗎？

杜歡（風馳）：我以爲沒有什麼對錯。它只是提到了一些特徵，可是我也想從特徵的角度給你們鼓鼓勁。好比說今天 CNCF，就是雲原生在推的事情，核心就是 Serverless。Serverless 的核心特徵是什麼呢？第一，按量。也就是說，先不要站在技術的角度去看，站在業務角度，它是按量的，按量就意味着，對於業務而言，它是最好的資源使用方式，既不會帶來浪費，也不會不足。第二，計費方式。如今不少的方式是你買的多浪費，買的少就不夠，並且須要再補買，很難把它和你的應用擴容上去。Serverless 的計費方式是按量走的，用多少付多少。另外，它是平臺承載的，由於平臺的實時彈性，幫助了用戶實現按量訴求。

第二，關於技術實踐上的複雜，我以爲也只是一個階段性的現狀而已。今天整個行業尚未一個開箱即用，或者說比較成熟的研發框架或研發體系、研發平臺出來，你們都在一個摸索的階段，就包括咱們本身也是剛剛摸索實踐出來，而且也還不算是成熟，咱們也還遇到不少要去繼續推進解決的問題。因此我是這麼看，先從業務的角度去看，它必定是一個最佳的路徑。階段性的痛苦確定是有的，因此沒有什麼對錯。

Question：目前國內外 Serverless 實踐存在怎樣的差距？

杜歡（風馳）：相對來說，國外的整個開發生態就時間上要比國內領先一點，緣由在於國外的主流雲廠商對整個 IT 行業，對整個開發生態的佈道作了不少工做。國外的開發生態對雲原生，對 Serverless 的接受度和實踐比咱們要好不少，而且也早不少。對他們而言，這是一個先發優點。提供的早，就意味着實踐的多，而後你們對整個 Serverless 的通用性的東西，好比通用的研發環節可以去作一些沉澱和抽象，因此誕生了一些像 Serverless.com 這些 Serverless 的開發框架。他們更多地是站在一個第三方的公共框架的角度來看，你可能既能夠用這個雲廠商，也能夠用那個雲廠商，基於個人框架能夠快速地去作，基於個人框架，框架天然會有些約束，你跟着這個框架的要求去作一些動做，而後你能夠去實踐，真正實踐這個 Serverless 在業務裏面落地，這是一些現狀。

那咱們今天在作的也有點相似這個事情，可是咱們可能不只僅是一個開發框架，而是但願把整個開發平臺都開放出來。因此你們不只僅是說雲層面，函數層面能夠按照咱們提的建議去作，你甚至能夠直接在咱們上面去作，咱們但願是這樣。

Question：明年 Serverless 有哪些更細粒度的技術值得關注？

杜歡（風馳）：當 Serverless 整個研發模式大概成形以後，接下來就是實踐。在實踐的過程中，對渲染層、服務層、函數運行時、框架這幾層可能會有一個更深刻的實踐，產生更細節的一些需求。我理解從明年開始，可能就是很是 detail 的垂直分層演進了，可能會有更多的這類內容產生，好比服務編排是如何演進的，函數運行時是如何演進的，性能是怎樣提高的，穩定性是怎樣進一步保障好的，就是又會回到一個大的運維架構演進的階段。

Question：最後一個問題，您預測將來 5 年，前端行業會有什麼變化？您所在團隊目前有沒有針對這些技術判斷作出一些佈局？

杜歡（風馳）：今年阿里經濟體的其餘幾個大的方向，好比前端智能、搭建等，這些都有可能串聯起來，成爲影響整個前端行業發展趨勢的一些因素。但我今天講的更多的多是整個研發生態的變化，將來的研發模式使前端能夠供整個業務，具體到每個環節，好比前端可能經過 UI 的智能化，讓本身釋放出來，經過一些成熟的視覺物料、前端物料，以及服務的物料，經過 AI 的輔助，快速地把一些本來須要前端去開發的一些模式化頁面模塊，經過 AI 的方式自主生成。

運維這塊可能隨着雲原生能力的不斷加強，工程化能力的補充，將來有可能進入到 NoOps ，就是不須要運維，只須要關注好一些數據。由於整個彈性會跟這些數據運行的實時數據關聯起來，去作不一樣的變化。

因此總體而言，將來五年對前端而言是能力價值進一步放大的五年，雲上 Serverless 開發能力將成爲前端的「金手指」，企業願意去組建一個由雲端的應用用開發工程師構成的研發團隊，經過研發團隊結合整個雲的研發體系，快速地交付它的業務。同時在這個過程中，結合智能化進一步提升生產效率，多是這樣一個趨勢。

若是你對於 Serverless 和函數計算感興趣的話，歡迎釘釘掃碼進入交流羣。

做者介紹：
杜歡（風馳），阿里雲戰略 & 合做部 / 高級前端技術專家。目前在阿里雲"戰略 & 合做部"負責阿里雲開發者業務，阿里巴巴經濟體前端技術委員會委員，阿里巴巴經濟體前端 Serverless 研發升級項目負責人。此前就任於雅虎、思科等公司。

招聘

TL;DR

阿里雲 - 雲原生應用平臺 - 基礎軟件中臺團隊（原容器平臺基礎軟件團隊）誠邀 Kubernetes/容器/ Serverless/應用交付技術領域專家（ P6-P8 ）加盟。

工做年限：建議 P6-7 三年起，P8 五年起，具體看實際能力。
工做地點：

• 國內：北京，杭州，深圳；
• 海外：舊金山灣區、西雅圖

簡歷馬上回復，2~3 周出結果。節後入職。

工做內容

基礎產品事業部是阿里雲智能事業羣的核心研發部門，負責計算、存儲、網絡、安全、中間件、系統軟件等研發。而云原生應用平臺基礎軟件終態團隊致力於打造穩定、標準、先進的雲原生應用系統平臺，推進行業面向雲原生技術升級與革命。

在這裏，既有 CNCF TOC 和 SIG 聯席主席，也有 etcd 創始人、K8s Operator 創始人與 Kubernetes 核心維護成員組成的、國內最頂尖的 Kubernetes 技術團隊。

在這裏，你將同來自全球的雲原生技術領域專家們（如 Helm 項目的創始人、Istio 項目的創始人）密切合做，在獨一無二的場景與規模中從事 Kubernetes、Service Mesh、Serverless、Open Application Model （ OAM ）等雲計算生態核心技術的研發與落地工做，在業界標杆級的平臺上，既賦能阿里巴巴全球經濟體，更服務全世界的開發者用戶。

1. 以 Kubernetes 爲核心，推進並打造下一代 "以應用爲中心" 的基礎技術體系；在阿里經濟體場景中，研發和落地「以應用爲中心」的基礎設施架構和基於 Open Application Model （ OAM ）的下一代 NoOps 體系，讓 Kubernetes 與雲原生技術棧發揮出真正的價值和能量；

1. 研發多環境複雜應用交付核心技術；結合阿里與生態中的核心業務場景，打造多環境複雜應用交付的業界標準與核心依賴（對標 Google Cloud Anthos 和 Microsoft Azure Arc ）；

1. 雲原生應用平臺核心產品及後端架構設計與開發工做；在生態核心技術與前沿架構的加持下，在世界級雲廠商的平臺場景中，用技術打造持續的雲產品生命力與競爭力；

1. 持續推進阿里經濟體應用平臺架構演進，包括 Serverless 基礎設施、標準雲原生標準 PaaS 構建、新一代應用交付體系構建等核心技術工做。

技術要求：Go/Rust/Java/C++，Linux，分佈式系統

簡歷提交

lei.zhang AT alibaba-inc.com

「 阿里巴巴雲原生關注微服務、Serverless、容器、Service Mesh 等技術領域、聚焦雲原生流行技術趨勢、雲原生大規模的落地實踐，作最懂雲原生開發者的技術圈。」